IaC Policy Controls
Introduction
When running a Github integration to check the compliance of a pull request during development, Sysdig will run the controls from the following policies:
CIS Kubernetes 1.5.1
Requirmenet Group | Group Description | Requirement | Requirement Description | Control | Control Description |
---|---|---|---|---|---|
5.1 - RBAC | Policies for Role Based Access Control and Service Accounts | ||||
5.1.5 - Default ServiceAccounts | The default service account should not be used to ensure that rights granted to applications can be more easily audited and reviewed. | ||||
Workload using “default” ServiceAccount | Pods must run with unique users using least privileges. This ensures accountability for actions, easier troubleshooting and makes sure the Pod will not perform unauthorized actions | ||||
5.1.6 - SA Tokens | Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. | ||||
Workload mounting ServiceAccount Token | Pods access to the API server should be minimized. When service account is not needed, auto mount of secrets can be avoided | ||||
5.2 - PSP | Policies for securing Pods | ||||
5.2.1-privileged containers | Do not generally permit containers to be run with the securityContext.privileged flag set to true. | ||||
Container running as privileged | Privileged containers are almost unrestricted and should not be used | ||||
5.2.2-Host PID | Do not generally permit containers to be run with the hostPID flag set to true | ||||
Workload sharing HostPID | Sharing the host’s PID reduces isolation and exposes host data to the running Pod, for example, environment variables | ||||
5.2.3 - Host IPC | Do not generally permit containers to be run with the hostIPC flag set to true. | ||||
Workload sharing HostIPC | Sharing the host’s IPC reduces isolation and allows the Pod to communicate with host processes eventually letting them perform tasks as if they were running on the host | ||||
5.2.4-Host Network | Do not generally permit containers to be run with the hostNetwork flag set to true. | ||||
Workload sharing HostNetworks | Sharing the host network exposes the Pod’s network to anyone with access to the Pod. In addition, it allows the Pod to communicate with processes bound to the host’s loopback | ||||
5.2.5 - Allow Privilege Escalation | Do not generally permit containers to be run with the allowPrivilegeEscalation flag set to true. | ||||
Container allowing privileged sub processes | A sub-process can gain more privileges than the parent process. | ||||
5.2.6 - Root containers | Do not generally permit containers to be run as the root user. | ||||
Container permitting root | The configuration enforces containers to run with ANY uid other than root. It is best practice to set this to make sure that even the image won’t override the configuration and run as root | ||||
Container running as root | Running containers as root can result in pod escape | ||||
Container uid is host range | It is recommended to run with uid>10000 to avoid conflicts with host user tables | ||||
Container with SYS_ADMIN capability | Assigns SYS_ADMIN capability that is equivalent to root access | ||||
5.2.7-NET_RAW | Do not generally permit containers with the potentially dangerous NET_RAW capability. | ||||
Container with NET_RAW capability | Assigns NET_RAW capability that allows binding to any address for transparent proxying any host address | ||||
5.2.8 - Added capabilities | Do not generally permit containers with capabilities assigned beyond the default set. | ||||
Container with ANY capability | Containers should not have any capabilities. | ||||
5.2.9 - No capabilities | Do not generally permit containers with capabilities | ||||
Container with ANY capability | Containers should not have any capabilities. | ||||
5.4 - Secrets | Secrets management | ||||
5.4.1 - Secrets Env Vars | Kubernetes supports mounting secrets as data volumes or as environment variables. Minimize the use of environment variable secrets. | ||||
Env variable exposing secret | Containers should avoid using secrets in environment variables as applications might print their content | ||||
5.4.2 - Ext secret storage | Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets. | ||||
Env variable exposing key from a secret | Containers should avoid using secrets in environment variables as applications might print their content | ||||
5.7 - General | General security policies | ||||
5.7.1 -Namespacing | Use namespaces to isolate your Kubernetes objects. | ||||
Workload defined in “default” namespace | Pods should be namespaced to promote isolation | ||||
5.7.2 - seccomp | Enable docker/default seccomp profile in your pod definitions. | ||||
Workload with docker.sock access | Pods mounting docker.sock can leak information about other container and result in container breakout | ||||
Seccomp profile docker/default | Containers in the workload should use secure computing mode (This is an alpha feature and ranked low) | ||||
5.7.4 - Default namespace | Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult. | ||||
Workload defined in “default” namespace | Pods should be namespaced to promote isolation |
Sysdig K8s Best Practices (IaC)
Requirmenet Group | Group Description | Requirement | Requirement Description | Control | Control Description |
---|---|---|---|---|---|
1 - Workload Security | Configurations relating directly to security configuration of the workload | ||||
1.1 - Workload Default SecurityContext | Defining the default security context in the workload is important to prevent misconfigurations and acts as another layer of protection. | ||||
Workload container default RunAsUser root | In case a container in the Pod did not define runAsUser this will set the user to root | ||||
Workload container default RunAsGroup root | In case a container in the Pod did not define runAsGroup this will set the group to root | ||||
Workload container default permits root | In case a container in the Pod did not define runAsNonRoot this will allow it define root as the user | ||||
1.2 - Immutable container filesystem | The container filesystem should be immutable. Tampering with the container root filesystem can be due to malware. | ||||
Container with writable root file system | A container with writable root filesystem is more exposed to attacks as it allows tampering with executables | ||||
1.3 - Immutable container volumes | The container volume mounts should be as immutable as possible. The more immutable = more secured. | ||||
Workload with writable volumes | Pods should mostly use read only volumes to make sure the workload is imutable | ||||
1.4 - Disable docker.sock volume | Mounting the docker.socket allows the workload to listen get information about other containers and can allow container breakout. | ||||
Workload with docker.sock access | Pods mounting docker.sock can leak information about other container and result in container breakout | ||||
1.5 - Exposing HostPort | HostPort is taking up a port from the physical node. Exposing services should be done using Services. | ||||
Container exposing HostPort | Host port usage may create constraints as to where the Pod can run | ||||
1.6 - Container root group access | The group id defines the group access level for the user running the container. It is best practice not to use the group “root”. | ||||
Container with root group access | Running with root group context allows access to all files owned by root group | ||||
2 - Workload-Operations | Configurations affecting the day to day operation of the workload | ||||
2.1 - Missing container requirements | Resource requirements help Kubernetes scheduler to better assign the workloads to nodes. | ||||
Workload missing CPU request | No resource request hurts the scheduler resource assignment for workloads | ||||
Workload missing memory request | No resource request hurts the scheduler resource assignment for workloads | ||||
2.2 - Missing container limits | Resource limits must be defined to avoid resource stravation by workloads with no limits. | ||||
Workload missing CPU limit | No limits configuration could cause process starvation | ||||
Workload missing memory limit | No limits configuration could cause process starvation | ||||
2.3 - Container image pull | Containers should pull images all time (best option) or if the image does not exist locally. | ||||
Container permanent image | Images that are not updated from the image repositories may result in tampered images | ||||
Container image update if not present only | Setting the pull policy to Always is recommended ensuring the container runs with the most up to date image | ||||
2.4 - Container image tag | Containers should always define the specific image needed for their proper function. | ||||
Container using latest image | Images running with “latest” or blank tag can break down the integrity of the system as update without a specific image | ||||
Container using image without digest | Image digest is immutable and guarantees all instances will run the same code always | ||||
2.5 - Container probes | Containers should have readniess and liveness probe configured to assure they only service requests when they are ready to with correct data. | ||||
Container without liveness probe | Containers should have liveness probe to expose their app status and maintain system integrity | ||||
Container without readiness probe | Containers should have readiness probe to expose their ability to service request and maintain system integrity | ||||
3 - Cluster & Workload Access | Configurations affecting the workload access and privileged users in the cluster | ||||
3.1 - NET_Admin capability | Network admin capability, allows manipulating the network interface, leak data from other workloads, proxy them and can result in cluster take over. | ||||
Container with NET_ADMIN capability | Assigns NET_ADMIN capability that allows binding to any address for transparent proxying any host address, managing interfaces, sniffing all host traffic and more | ||||
3.2 - Container overlap host UID Range | UID range of containers should avoid the host’s range to avoid collision. | ||||
Container uid is host range | It is recommended to run with uid>10000 to avoid conflicts with host user tables |
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.
Last modified May 20, 2022