CIS Kubernetes Benchmark v1.9.0

1.3.1 Ensure that the --terminated-pod-gc-threshold argument is set as appropriate (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Activate garbage collector on pod termination, as appropriate.
Rationale:
Garbage collection is important to ensure sufficient resource availability and avoiding degraded performance and availability. In the worst case, the system might crash or just be unusable for a long period of time. The current setting for garbage collection is 12,500 terminated pods which might be too high for your system to sustain. Based on your system resources and tests, choose an appropriate threshold value to activate garbage collection.
Impact:
None
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --terminated-pod-gc-threshold argument is set as appropriate.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and set the --terminated-pod-gcthreshold to an appropriate threshold, for example: 

--terminated-pod-gc-threshold=10 

Default Value:
By default, --terminated-pod-gc-threshold is set to 12500.

1.3.2 Ensure that the --profiling argument is set to false (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Disable profiling, if not needed.
Rationale:
Profiling allows for the identification of specific performance bottlenecks. It generates a significant amount of program data that could potentially be exploited to uncover system and program details. If you are not experiencing any bottlenecks and do not need the profiler for troubleshooting purposes, it is recommended to turn it off to reduce the potential attack surface.
Impact:
Profiling information would not be available.
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --profiling argument is set to false.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and set the below parameter. 

--profiling=false 

Default Value:
By default, profiling is enabled.

1.3.3 Ensure that the --use-service-account-credentials argument is set to true (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Use individual service account credentials for each controller.
Rationale:
The controller manager creates a service account per controller in the kube-system namespace, generates a credential for it, and builds a dedicated API client with that service account credential for each controller loop to use. Setting the --use-serviceaccount-credentials to true runs each control loop within the controller manager using a separate service account credential. When used in combination with RBAC, this ensures that the control loops run with the minimum permissions required to perform their intended tasks.
Impact:
Whatever authorizer is configured for the cluster, it must grant sufficient permissions to the service accounts to perform their intended tasks. When using the RBAC authorizer, those roles are created and bound to the appropriate service accounts in the kubesystem namespace automatically with default roles and rolebindings that are autoreconciled on startup.
If using other authorization methods (ABAC, Webhook, etc), the cluster deployer is responsible for granting appropriate permissions to the service accounts (the required permissions can be seen by inspecting the controller-roles.yaml and controllerrole-bindings.yaml files for the RBAC roles.
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --use-service-account-credentials argument is set to true.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node to set the below parameter.

--use-service-account-credentials=true 

Default Value:
By default, --use-service-account-credentials is set to false. 

1.3.4 Ensure that the --service-account-private-key-file argument is set as appropriate (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Explicitly set a service account private key file for service accounts on the controller manager.
Rationale:
To ensure that keys for service account tokens can be rotated as needed, a separate public/private key pair should be used for signing service account tokens. The private key should be specified to the controller manager with --service-account-privatekey-file as appropriate.
Impact:
You would need to securely maintain the key file and rotate the keys based on your organization's key rotation policy.
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --service-account-private-key-file argument is set as appropriate.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and set the --service-accountprivate-key-file parameter to the private key file for service accounts. 

--service-account-private-key-file= 

Default Value:
By default, --service-account-private-key-file it not set.

1.3.5 Ensure that the --root-ca-file argument is set as appropriate (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Allow pods to verify the API server's serving certificate before establishing connections.
Rationale:
Processes running within pods that need to contact the API server must verify the API server's serving certificate. Failing to do so could be a subject to man-in-the-middle attacks. Providing the root certificate for the API server's serving certificate to the controller manager with the --root-ca-file argument allows the controller manager to inject the trusted bundle into pods so that they can verify TLS connections to the API server.
Impact:
You need to setup and maintain root certificate authority file.
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --root-ca-file argument exists and is set to a certificate bundle file containing the root certificate for the API server's serving certificate.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and set the --root-ca-file parameter to the certificate bundle file`. 

--root-ca-file=<path/to/file>

Default Value:
By default, --root-ca-file is not set. 

1.3.6 Ensure that the RotateKubeletServerCertificate argument is set to true (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Enable kubelet server certificate rotation on controller-manager.
Rationale:
RotateKubeletServerCertificate causes the kubelet to both request a serving certificate after bootstrapping its client credentials and rotate the certificate as its existing credentials expire. This automated periodic rotation ensures that the there are no downtimes due to expired certificates and thus addressing availability in the CIA security triad.
Note: This recommendation only applies if you let kubelets get their certificates from the API server. In case your kubelet certificates come from an outside authority/tool (e.g. Vault) then you need to take care of rotation yourself.
Impact:
None
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that RotateKubeletServerCertificate argument exists and is set to true.
Remediation:
Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and set the --feature-gates parameter to include RotateKubeletServerCertificate=true. 

--feature-gates=RotateKubeletServerCertificate=true 

Default Value:
By default, RotateKubeletServerCertificate is set to "true" this recommendation verifies that it has not been disabled. 

1.3.7 Ensure that the --bind-address argument is set to 127.0.0.1 (Automated)
Profile Applicability:
Level 1 - Master Node
Description:
Do not bind the Controller Manager service to non-loopback insecure addresses.
Rationale:
The Controller Manager API service which runs on port 10252/TCP by default is used for health and metrics information and is available without authentication or encryption. As such it should only be bound to a localhost interface, to minimize the cluster's attack surface
Impact:
None
Audit:
Run the following command on the Control Plane node: 

ps -ef | grep kube-controller-manager 

Verify that the --bind-address argument is set to 127.0.0.1
Remediation:

Edit the Controller Manager pod specification file /etc/kubernetes/manifests/kubecontroller-manager.yaml on the Control Plane node and ensure the correct value for the --bind-address parameter

Default Value:
By default, the --bind-address parameter is set to 0.0.0.0.
Additional Information:
Although the current Kubernetes documentation site says that --address is deprecated in favour of --bind-address Kubeadm 1.11 still makes use of --address