CIS Kubernetes Benchmark v1.9.0

5.2.1 Ensure that the cluster has at least one active policy control mechanism in place (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Every Kubernetes cluster should have at least one policy control mechanism in place to enforce the other requirements in this section. This could be the in-built Pod Security Admission controller, or a third party policy control system.
Rationale:
Without an active policy control mechanism, it is not possible to limit the use of containers with access to underlying cluster nodes, via mechanisms like privileged containers, or the use of hostPath volume mounts.
Impact:
Where policy control systems are in place, there is a risk that workloads required for the operation of the cluster may be stopped from running. Care is required when implementing admission control policies to ensure that this does not occur.
Audit:
Review the workloads deployed to the cluster to understand if Pod Security Admission or external admission control systems are in place.
Remediation:
Ensure that either Pod Security Admission or an external policy control system is in place for every namespace which contains user workloads.
Default Value:
By default, Pod Security Admission is enabled but no policies are in place. 

5.2.2 Minimize the admission of privileged containers (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers to be run with the securityContext.privileged flag set to true.
Rationale:
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.
Impact:
Pods defined with spec.containers[].securityContext.privileged: true, spec.initContainers[].securityContext.privileged: true and spec.ephemeralContainers[].securityContext.privileged: true will not be permitted.
Audit: 

Run the following command: get pods -A -o=jsonpath=$'{range .items[*]}{@.metadata.name}: 
{@..securityContext}\n{end}' 

It will produce an inventory of all the privileged use on the cluster, if any (please, refer to a sample below). Further grepping can be done to automate each specific violation detection.
calico-kube-controllers-57b57c56f-jtmk4: {} << No Elevated Privileges calico-nodec4xv4: {} {"privileged":true} {"privileged":true} {"privileged":true} {"privileged":true} << Violates 5.2.2 dashboard-metrics-scraper-7bc864c59-2m2xw:
{"seccompProfile":{"type":"RuntimeDefault"}}
{"allowPrivilegeEscalation":false,"readOnlyRootFilesystem":true,"runAsGroup":2001,"ru nAsUser":1001}
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of privileged containers.
Default Value:
By default, there are no restrictions on the creation of privileged containers.

5.2.3 Minimize the admission of containers wishing to share the host process ID namespace (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers to be run with the hostPID flag set to true.
Rationale:
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.
Impact:
Pods defined with spec.hostPID: true will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of hostPID containers
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of hostPID containers.
Default Value:
By default, there are no restrictions on the creation of hostPID containers 

5.2.4 Minimize the admission of containers wishing to share the host IPC namespace (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers to be run with the hostIPC flag set to true.
Rationale:
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.
Impact:
Pods defined with spec.hostIPC: true will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of hostIPC containers
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of hostIPC containers.
Default Value:
By default, there are no restrictions on the creation of hostIPC containers.

5.2.5 Minimize the admission of containers wishing to share the host network namespace (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers to be run with the hostNetwork flag set to true.
Rationale:
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.
Impact:
Pods defined with spec.hostNetwork: true will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of hostNetwork containers
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of hostNetwork containers.
Default Value:
By default, there are no restrictions on the creation of hostNetwork containers.

5.2.6 Minimize the admission of containers with allowPrivilegeEscalation (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers to be run with the allowPrivilegeEscalation flag set to true. Allowing this right can lead to a process running a container getting more rights than it started with.
It's important to note that these rights are still constrained by the overall container sandbox, and this setting does not relate to the use of privileged containers.
Rationale:
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 setuid binaries to run.
If you have need to run containers which use setuid 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.
Impact:
Pods defined with spec.allowPrivilegeEscalation: true will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of containers which allow privilege escalation.
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of conatiners with .spec.allowPrivilegeEscalation set to true.
Default Value:
By default, there are no restrictions on contained process ability to escalate privileges, within the context of the container.

5.2.7 Minimize the admission of root containers (Manual)
Profile Applicability:
Level 2 - Master Node
Description:
Do not generally permit containers to be run as the root user.
Rationale:
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.
Impact:
Pods with containers which run as the root user will not be permitted.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy restricts the use of root containers by setting MustRunAsNonRoot or MustRunAs with the range of UIDs not including 0.
Remediation:
Create a policy for each namespace in the cluster, ensuring that either MustRunAsNonRoot or MustRunAs with the range of UIDs not including 0, is set.
Default Value:
By default, there are no restrictions on the use of root containers and if a User is not specified in the image, the container will run as root.

5.2.8 Minimize the admission of containers with the NET_RAW capability (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers with the potentially dangerous NET_RAW capability.
Rationale:
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.
Impact:
Pods with containers which run with the NET_RAW capability will not be permitted.
Audit:
List the policies in use for each namespace in the cluster, ensure that at least one policy disallows the admission of containers with the NET_RAW capability.
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers with the NET_RAW capability.
Default Value:
By default, there are no restrictions on the creation of containers with the NET_RAW capability.

5.2.9 Minimize the admission of containers with added capabilities (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers with capabilities assigned beyond the default set.
Rationale:
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.
Impact:
Pods with containers which require capabilities outwith the default set will not be permitted.
Audit:
List the policies in use for each namespace in the cluster, ensure that policies are present which prevent allowedCapabilities to be set to anything other than an empty array.
Remediation:
Ensure that allowedCapabilities is not present in policies for the cluster unless it is set to an empty array.
Default Value:
By default, there are no restrictions on adding capabilities to containers.

5.2.10 Minimize the admission of containers with capabilities assigned (Manual)
Profile Applicability:
Level 2 - Master Node
Description:
Do not generally permit containers with capabilities
Rationale:
Containers run with a default set of capabilities as assigned by the Container Runtime. Capabilities are parts of the rights generally granted on a Linux system to the root user.
In many cases applications running in containers do not require any capabilities to operate, so from the perspective of the principal of least privilege use of capabilities should be minimized.
Impact:
Pods with containers require capabilities to operate will not be permitted.
Audit:
List the policies in use for each namespace in the cluster, ensure that at least one policy requires that capabilities are dropped by all containers.
Remediation:
Review the use of capabilities in applications running on your cluster. Where a namespace contains applications which do not require any Linux capabilities to operate consider adding a policy which forbids the admission of containers which do not drop all capabilities.
Default Value:
By default, there are no restrictions on the creation of containers with additional capabilities

5.2.11 Minimize the admission of Windows HostProcess Containers (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit Windows containers to be run with the hostProcess flag set to true.
Rationale:
A Windows container making use of the hostProcess flag can interact with the underlying Windows cluster node. As per the Kubernetes documentation, this provides "privileged access" to the Windows node.
Where Windows containers are used inside a Kubernetes cluster, there should be at least one admission control policy which does not permit hostProcess Windows containers.
If you need to run Windows containers which require hostProcess, 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.
Impact:
Pods defined with securityContext.windowsOptions.hostProcess: true will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of hostProcess containers
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of hostProcess containers.
Default Value:
By default, there are no restrictions on the creation of hostProcess containers.

5.2.12 Minimize the admission of HostPath volumes (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally admit containers which make use of hostPath volumes.
Rationale:
A container which mounts a hostPath volume as part of its specification will have access to the filesystem of the underlying cluster node. The use of hostPath volumes may allow containers access to privileged areas of the node filesystem.
There should be at least one admission control policy defined which does not permit containers to mount hostPath volumes.
If you need to run containers which require hostPath volumes, 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.
Impact:
Pods defined which make use of hostPath volumes will not be permitted unless they are run under a spefific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of containers with hostPath volumes.
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers which use hostPath volumes.
Default Value:
By default, there are no restrictions on the creation of hostPath volumes.

5.2.13 Minimize the admission of containers which use HostPorts (Manual)
Profile Applicability:
Level 1 - Master Node
Description:
Do not generally permit containers which require the use of HostPorts.
Rationale:
Host ports connect containers directly to the host's network. This can bypass controls such as network policy.
There should be at least one admission control policy defined which does not permit containers which require the use of HostPorts.
If you need to run containers which require HostPorts, 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.
Impact:
Pods defined with hostPort settings in either the container, initContainer or ephemeralContainer sections will not be permitted unless they are run under a specific policy.
Audit:
List the policies in use for each namespace in the cluster, ensure that each policy disallows the admission of containers which have hostPort sections.
Remediation:
Add policies to each namespace in the cluster which has user workloads to restrict the admission of containers which use hostPort sections.
Default Value:
By default, there are no restrictions on the use of HostPorts.