Checks

An immutable root file system prevents applications from writing to their local disk. This can limit intrusions, as attackers will not be able to tamper with the file system or write foreign executables to disk.

When containers have resource requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention.

When containers have memory requests specified, the scheduler can make better decisions about which nodes to place pods on, and how to deal with resource contention.

Privileged containers share namespaces with the host system and do not offer any security. They should be used exclusively for system containers that require high privileges.

Enforcing memory limits prevents DoS via resource exhaustion.

Force the container to run with user ID > 10000 to avoid conflicts with the host’s user table.

Force the container to run with group ID > 10000 to avoid conflicts with the host’s user table.

According to pod security standard 'Capabilities', capabilities beyond the default set must not be added.

According to pod security standard 'HostPath Volumes', HostPath volumes must be forbidden.

According to pod security standard 'Host Ports', hostPorts should be disallowed, or at minimum restricted to a known list.

According to pod security standard 'SElinux', setting custom SELinux options should be disallowed.

Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed 'safe' subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.

According to pod security standard '/proc Mount Type', the default /proc masks are set up to reduce attack surface, and should be required.

According to pod security standard 'Volume types', non-core volume types must not be used.

According to pod security standard 'Seccomp', the RuntimeDefault seccomp profile must be required, or allow specific additional profiles.

ensure that Pod specifications disable the secret token being mounted by setting automountServiceAccountToken: false

ensure that user resources are not placed in kube-system namespace

ensure that network policies selectors are applied to pods or namespaces to restricted ingress and egress traffic within the pod network

Ensure that a LimitRange policy is configured to limit resource usage for namespaces or nodes

Ensure that a ResourceQuota policy is configured to limit aggregate resource usage within a namespace

Viewing secrets at the cluster-scope is akin to cluster-admin in most clusters as there are typically at least one service accounts (their token stored in a secret) bound to cluster-admin directly or a role/clusterrole that gives similar permissions.

Used to cover attacker’s tracks, but most clusters ship logs quickly off-cluster.

Check whether role permits impersonating privileged groups

Check whether role permits wildcard verb on wildcard resource