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

Feedback

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.