Policy Templates for AKS
Azure Kubernetes Services (AKS)
The following Kubernetes policies apply to Azure Kubernetes Service (AKS).
Skyhigh CASB supports the CIS Kubernetes v1.23 Benchmark v1.0.0 - 02-04-2022 specification for auditing CSP managed clusters.
For instructions on how to find Policy templates that are new or updated due to changed recommendations, see Find New and Updated Policy Templates.
|
Policy Name |
Resource |
Benchmark
|
PCI DSS
|
HIPAA
|
NIST 800-53
|
Policy Description
|
|---|---|---|---|---|---|---|
| AKS: Do not admit containers wishing to share the host process ID namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | SC-4 | A container running in the host's PID namespace can inspect processes running outside the container. If the container also has access to ptrace capabilities this can be used to escalate privileges outside of the container. There should be at least one admission control policy defined which does not permit containers to share the host PID namespace. If you need to run containers which require hostPID, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Group container workloads onto hosts by sensitivity level | AKS | SC-3 | ||||
| AKS: Keeping containerized workloads isolated to container-specific hosts | AKS | SC-3 | ||||
| AKS: Argument AdvancedAuditing should not be set to false for API Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | AdvancedAuditing enables a much more general API auditing pipeline, which includes support for pluggable output backends and an audit policy specifying how different requests should be audited. Additionally, this enables auditing of failed authentication, authorization and login attempts which could prove crucial for protecting your production clusters. It is thus recommended not to disable advanced auditing |
| AKS: Admission control plugin AlwaysAdmit should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | CM-3 | Setting admission control plugin AlwaysAdmit allows all requests and do not filter any requests. | |
| Admission control plugin AlwaysPullImages should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to AlwaysPullImages forces every new pod to pull the required images every time. In a multi-tenant cluster users can be assured that their private images can only be used by those who have the credentials to pull them. Without this admission control policy, once an image has been pulled to a node, any pod from any user can use it simply by knowing the image’s name, without any authorization check against the image ownership. When this plug-in is enabled, images are always pulled prior to starting containers, which means valid credentials are required. | |
| AKS: Argument anonymous-auth should be set to false for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the API server. You should rely on authentication to authorize access and disallow anonymous requests. |
| AKS: Argument audit-log-maxage should be set to 30 or as appropriate for API Server | AKS | CIS Level 1 | 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Retaining logs for at least 30 days ensures that you can go back in time and investigate or correlate any events. Set your audit log retention period to 30 days or as per your business requirements. |
| AKS: Argument audit-log-maxbackup should be set to 10 or as appropriate for API Server | AKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. For example, if you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument audit-log-maxsize should be set to 100 or as appropriate for API Server | AKS | CIS Level 1 | 10.5.3 10.7 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument audit-log-path should be set as appropriate for API Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | Auditing the API Server provides a security-relevant chronological set of records documenting the sequence of activities that have affected system by individual users, administrators or other components of the system. Even though currently, Kubernetes provides only basic audit capabilities, it should be enabled. You can enable it by setting an appropriate audit log path. |
| AKS: Argument authorization-mode should not be set to AlwaysAllow for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The API Server, can be configured to allow all requests. This mode should not be used on any production cluster. |
| AKS: Argument authorization-mode should include Node for API Server | AKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The Node authorization mode only allows kubelets to read Secret, ConfigMap, PersistentVolume, and PersistentVolumeClaim objects associated with their nodes. |
| AKS: Argument authorization-mode should include RBAC for API Server | AKS | CIS Level 1 | 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Role Based Access Control (RBAC) allows fine-grained control over the operations that different entities can perform on different objects in the cluster. It is recommended to use the RBAC authorisation mode. |
| AKS: Argument basic-auth-file should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 | CM-3 | Basic authentication uses plaintext credentials for authentication. Currently, the basic authentication credentials last indefinitely, and the password cannot be changed without restarting API server. The basic authentication is currently supported for convenience. Hence, basic authentication should not be used. | |
| AKS: Argument client-ca-file should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | API server communication contains sensitive parameters that should remain encrypted in transit. Configure the API server to serve only HTTPS traffic. If --client-ca-file argument is set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
| AKS: Argument encryption-provider-config should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2 6.5.3 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | etcd is a highly available key-value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any disclosures. |
| AKS: Argument etcd-cafile should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a SSL Certificate Authority file. |
| AKS: Arguments etcd-certfile and etcd-keyfile should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.1 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | etcd is a highly-available key value store used by Kubernetes deployments for persistent storage of all of its REST API objects. These objects are sensitive in nature and should be protected by client authentication. This requires the API server to identify itself to the etcd server using a client certificate and key |
| AKS: Admission control plugin EventRateLimit should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | 164.312(a)(2)(iii) | CM-3 | Using EventRateLimit admission control enforces a limit on the number of events that the API Server will accept in a given time slice. A misbehaving workload could overwhelm and DoS the API Server, making it unavailable. This particularly applies to a multi-tenant cluster, where there might be a small percentage of misbehaving tenants which could have a significant impact on the performance of the cluster overall. Hence, it is recommended to limit the rate of events that the API server will accept. |
| AKS: Argument insecure-bind-address should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | If you bind the apiserver to an insecure address, basically anyone who could connect to it over the insecure port, would have unauthenticated and unencrypted access to your master node. The apiserver doesn't do any authentication checking for insecure binds and traffic to the Insecure API port is not encrpyted, allowing attackers to potentially read sensitive data in transit. |
| AKS: Argument insecure-port should be set to 0 for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 2.2.2 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Setting up the apiserver to serve on an insecure port would allow unauthenticated and unencrypted access to your master node. This would allow attackers who could access this port, to easily take control of the cluster. |
| AKS: Argument insecure-allow-any-token should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Accepting insecure tokens would allow any token without actually authenticating anything. User information is parsed from the token and connections are allowed. |
| AKS: Argument kubelet-certificate-authority should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| AKS: Arguments kubelet-client-certificate and kubelet-client-key should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 10.5 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The apiserver, by default, does not authenticate itself to the kubelet's HTTPS endpoints. The requests from the apiserver are treated anonymously. You should set up certificatebased kubelet authentication to ensure that the apiserver authenticates itself to kubelets when submitting requests. |
| AKS: Argument kubelet-https should be set to true for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Connections from apiserver to kubelets could potentially carry sensitive data such as secrets and keys. It is thus important to use in-transit encryption for any communication between the apiserver and kubelets. |
| AKS: Admission control plugin NamespaceLifecycle should be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | Setting admission control policy to NamespaceLifecycle ensures that objects cannot be created in non-existent namespaces, and that namespaces undergoing termination are not used for creating the new objects. This is recommended to enforce the integrity of the namespace termination process and also for the availability of the newer objects | |
| AKS: Admission control plugin NodeRestriction should be set for API Server | AKS | CIS Level 1 | 7.1 | CM-3 | Using the NodeRestriction plug-in ensures that the kubelet is restricted to the Node and Pod objects that it could modify as defined. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. | |
| AKS: Admission control plugin PodSecurityPolicy should be set for API Server | AKS | CIS Level 1 | 1.2 | CM-3 | A Pod Security Policy is a cluster-level resource that controls the actions that a pod can perform and what it has the ability to access. The PodSecurityPolicy objects define a set of conditions that a pod must run with in order to be accepted into the system. Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to and hence this must be used to control pod access permissions. | |
| AKS: Argument profiling should be set to false for API Server | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | 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. | |
| AKS: Argument repair-malformed-updates should be set to false for API Server | AKS | CIS Level 1 | 6.5.5 | CM-3 | The API Server will potentially attempt to fix the update requests to pass the validation even if the requests are malformed. Malformed requests are one of the potential ways to interact with a service without legitimate information. Such requests could potentially be used to sabotage API Server responses. | |
| AKS: Argument request-timeout should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Kubernetes automatically rotates the log files. Retaining old log files ensures that you would have sufficient log data available for carrying out any investigation or correlation. If you have set file size of 100 MB and the number of old log files to keep as 10, you would approximate have 1 GB of log data that you could potentially use for your analysis. |
| AKS: Argument secure-port should not be set to 0 for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | CM-3 | The secure port is used to serve https with authentication and authorization. If you disable it, no https traffic is served and all traffic is served unencrypted. | |
| AKS: Admission control plugin SecurityContextDeny should be set if PodSecurityPolicy is not used for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 | CM-3 | SecurityContextDeny can be used to provide a layer of security for clusters which do not have PodSecurityPolicies enabled. | |
| AKS: Argument service-account-key-file should be set as appropriate for API Server | AKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | By default, if no --service-account-key-file is specified to the apiserver, it uses the private key from the TLS serving certificate to verify service account tokens. To ensure that the keys for service account tokens could be rotated as needed, a separate public/private key pair should be used for signing service account tokens. Hence, the public key should be specified to the apiserver with --service-account-key-file. | |
| AKS: Argument service-account-lookup should be set to true for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.10 | CM-3 | If --service-account-lookup is not enabled, the apiserver only verifies that the authentication token is valid, and does not validate that the service account token mentioned in the request is actually present in etcd. This allows using a service account token even after the corresponding service account is deleted. This is an example of time of check to time of use security issue | |
| AKS: Admission control plugin ServiceAccount should be set for API Server | AKS | CIS Level 1 | 2.1 | CM-3 | When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. You should create your own service account and let the API server manage its security tokens. | |
| AKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. |
| AKS: API Server should only use Strong Cryptographic Ciphers | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| AKS: Argument token-auth-file should not be set for API Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.3 8.2.1 | CM-3 | The token-based authentication utilizes static tokens to authenticate requests to the apiserver. The tokens are stored in clear-text in a file on the apiserver, and cannot be revoked or rotated without restarting the apiserver. Hence, do not use static token-based authentication. | |
| AKS: Argument address should be set to 127.0.0.1 for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | 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 | |
| AKS: Argument profiling should be set to false for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | 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. | |
| AKS: Argument root-ca-file should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | 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. |
| AKS: Argument RotateKubeletServerCertificate should be set to true for Controller Manager | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | 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. |
| AKS: Argument use-service-account-credentials should be set to true for Controller Manager | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | 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-service-accountcredentials 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. | |
| AKS: Argument service-account-private-key-file should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 8.2.2 8.5 | CM-3 | 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-private-key-file as appropriate. | |
| AKS: Argument terminated-pod-gc-threshold should be set as appropriate for Controller Manager | AKS | CIS Level 1 | 6.5.2 | 164.312(a)(2)(iii) | CM-3 | 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. |
| AKS: Argument address should be set to 127.0.0.1 for Scheduler | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | The Scheduler API service which runs on port 10251/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 | |
| AKS: Argument profiling should be set to false for Scheduler | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | 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. | |
| AKS: Argument anonymous-auth should be set to false for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 7.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | When enabled, requests that are not rejected by other configured authentication methods are treated as anonymous requests. These requests are then served by the Kubelet server. You should rely on authentication to authorize access and disallow anonymous requests. |
| AKS: Argument client-ca-file should be set as appropriate for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The connections from the apiserver to the kubelet are used for fetching logs for pods, attaching (through kubectl) to running pods, and using the kubelet’s port-forwarding functionality. These connections terminate at the kubelet’s HTTPS endpoint. By default, the apiserver does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks, and unsafe to run over untrusted and/or public networks. Enabling Kubelet certificate authentication ensures that the apiserver could authenticate the Kubelet before submitting any requests. |
| AKS: Argument event-qps should be set to 0 or a level which ensures appropriate event capture for Kubelet Server | AKS | CIS Level 1 | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | 164.308(a)(5)(ii)(C), 164.312(b), 164.312(c)(2), 164.312(e)(2)(i), 164.308(a)(1)(ii)(D) | CM-3 | It is important to capture all events and not restrict event creation. Events are an important source of security information and analytics that ensure that your environment is consistently monitored using the event data. |
| AKS: Argument make-iptables-util-chains should be set to true for Kubelet Server | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | CM-3 | Kubelets can automatically manage the required changes to iptables based on how you choose your networking options for the pods. It is recommended to let kubelets manage the changes to iptables. This ensures that the iptables configuration remains in sync with pods networking configuration. Manually configuring iptables with dynamic pod network configuration changes might hamper the communication between pods/containers and to the outside world. You might have iptables rules too restrictive or too open. | |
| AKS: Argument protect-kernel-defaults should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 | CM-3 | Kernel parameters are usually tuned and hardened by the system administrators before putting the systems into production. These parameters protect the kernel and the system. Your kubelet kernel defaults that rely on such parameters should be appropriately set to match the desired secured system state. Ignoring this could potentially lead to running pods with undesired kernel behavior | |
| AKS: Argument rotate-certificates should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The --rotate-certificates setting causes the kubelet to rotate its client certificates by creating new CSRs 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. 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 |
| AKS: Argument RotateKubeletServerCertificate should be set to true for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 8.2.4 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | 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. 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. |
| AKS: Argument streaming-connection-idle-timeout should not be set to 0 for Kubelet Server | AKS | CIS Level 1 | 8.1.8 | 164.312(a)(2)(iii) | CM-3 | Setting idle timeouts ensures that you are protected against Denial-of-Service attacks, inactive connections and running out of ephemeral ports. By default, --streaming-connection-idle-timeout is set to 4 hours which might be too high for your environment. Setting this as appropriate would additionally ensure that such streaming connections are timed out after serving legitimate use cases. |
| AKS: Arguments tls-cert-file and tls-private-key-file should be set as appropriate for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.4 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | Kubelet communication contains sensitive parameters that should remain encrypted in transit. Configure the Kubelets to serve only HTTPS traffic. |
| AKS: Kubelet should only use strong Cryptographic Ciphers | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 | 164.312(e)(2)(ii),164.312(e)(1),164.312(c)(1), 164.312(a)(2)(iv) | CM-3 | TLS ciphers have had a number of known vulnerabilities and weaknesses, which can reduce the protection provided by them. By default Kubernetes supports a number of TLS ciphersuites including some that have security concerns, weakening the protection provided. |
| AKS: Do not admit containers with allowPrivilegeEscalation in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running with the allowPrivilegeEscalation flag set to true may have processes that can gain more privileges than their parent. There should be at least one admission control policy defined which does not permit containers to allow privilege escalation. The option exists (and is defaulted to true) to permit set uid binaries to run. If you have need to run containers which use set uid binaries or require privilege escalation, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not admit containers wishing to share the host IPC namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | CM-3 | A container running in the host's IPC namespace can use IPC to interact with processes outside the container. There should be at least one admission control policy defined which does not permit containers to share the host IPC namespace. If you need to run containers which require hostIPC, this should be definited in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |
| AKS: Do not admit containers wishing to share the host network namespace in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | A container running in the host's network namespace could access the local loopback device, and could access network traffic to and from other pods. There should be at least one admission control policy defined which does not permit containers to share the host network namespace. If you need to run containers which require access to the host's network namesapces, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not admit privileged containers in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Privileged containers have access to all Linux Kernel capabilities and devices. A container running with full privileges can do almost everything that the host can do. This flag exists to allow special use-cases, like manipulating the network stack and accessing devices. There should be at least one admission control policy defined which does not permit privileged containers. If you need to run privileged containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Do not generally permit containers to be run as the root user in Pod Security Policies | AKS | CIS Level 2 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | Containers may run as any Linux user. Containers which run as the root user, whilst constrained by Container Runtime security features still have a escalated likelihood of container breakout. Ideally, all containers should run as a defined non-UID 0 user. There should be at least one admission control policy defined which does not permit root containers. If you need to run root containers, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |
| AKS: Enable control plane logging during AKS cluster creation | AKS | 10.1 10.2.2, 10.2.4, 10.2.5, 10.2.7 10.3.1, 10.3.2, 10.3.3, 10.3.4, 10.3.5, 10.3.6 | CM-3 | |||
| AKS: Argument authorization-mode should not be set to AlwaysAllow for Kubelet Server | AKS | CIS Level 1 | 2.2, 2.2.3, 2.2.4, 2.3 6.5.8 2.2.2 6.4.2 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM_3 | Kubelets, by default, allow all authenticated requests (even anonymous ones) without needing explicit authorization checks from the apiserver. You should restrict this behavior and only allow explicitly authorized requests. |
| AKS: Cluster Node Permissions should be monitored | AKS | |||||
| AKS: Dedicated security group for each control plane (one per cluster) | AKS | |||||
| AKS: Minimum inbound traffic to control plane security groups | AKS | |||||
| AKS: End point public access should be disabled or monitored correctly | AKS | |||||
| AKS: Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters | AKS | |||||
| AKS: Do not generally permit containers with capabilities assigned beyond the default set in Pod Security Policies | AKS | CIS Level 1 | Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities outside this set can be added to containers which could expose them to risks of container breakout attacks. There should be at least one policy defined which prevents containers with capabilities beyond the default set from launching. If you need to run containers with additional capabilities, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. | |||
| AKS: Argument DenyServiceExternalIPs should not be set for API Server | AKS | CIS Level 1 | This admission controller rejects all net-new usage of the Service field externalIPs. This feature is very powerful (allows network traffic interception) and not well controlled by policy. When enabled, users of the cluster may not create new Services which use externalIPs and may not add new values to externalIPs on existing Service objects. Existing uses of externalIPs are not affected, and users may remove values from externalIPs on existing Service objects.\nMost users do not need this feature at all, and cluster admins should consider disabling it. Clusters that do need to use this feature should consider using some custom policy to manage usage of it. |
Deprecated Policies
| Policy Name | Resource | Benchmark | PCI DSS | HIPAA | NIST 800-53 | Policy Description |
|---|---|---|---|---|---|---|
| AKS: Argument read-only-port should be set to 0 for Kubelet Server | AKS | CIS Level 1 | 7.1 7.2, 7.2.1, 7.2.2, 7.2.3 | 164.312(a)(1),164.308(a)(3)(i),164.308(b)(1), 164.312(c)(1), 164.312(e)(1) | CM-3 | The Kubelet process provides a read-only API in addition to the main Kubelet API. Unauthenticated access is provided to this read-only API which could possibly retrieve potentially sensitive information about the cluster. |
| AKS: Do not admit containers with NET_RAW capabilities in Pod Security Policies | AKS | CIS Level 1 | 1.2 2.2, 2.2.3, 2.2.4, 2.3 PCI_SSC_Cloud_guidelines_v3 E.7 | CM-3 | Containers run with a default set of capabilities as assigned by the Container Runtime. By default this can include potentially dangerous capabilities. With Docker as the container runtime the NET_RAW capability is enabled which may be misused by malicious containers. Ideally, all containers should drop this capability. There should be at least one admission control policy defined which does not permit containers with the NET_RAW capability. If you need to run containers with this capability, this should be defined in a separate policy and you should carefully check to ensure that only limited service accounts and users are given permission to use that policy. |