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 GroupGroup DescriptionRequirementRequirement DescriptionControlControl Description
5.1 - RBACPolicies for Role Based Access Control and Service Accounts
5.1.5 - Default ServiceAccountsThe default service account should not be used to ensure that rights granted to applications can be more easily audited and reviewed.
Workload using “default” ServiceAccountPods 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 TokensService 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 TokenPods access to the API server should be minimized. When service account is not needed, auto mount of secrets can be avoided
5.2 - PSPPolicies for securing Pods
5.2.1-privileged containersDo not generally permit containers to be run with the securityContext.privileged flag set to true.
Container running as privilegedPrivileged containers are almost unrestricted and should not be used
5.2.2-Host PIDDo not generally permit containers to be run with the hostPID flag set to true
Workload sharing HostPIDSharing the host’s PID reduces isolation and exposes host data to the running Pod, for example, environment variables
5.2.3 - Host IPCDo not generally permit containers to be run with the hostIPC flag set to true.
Workload sharing HostIPCSharing 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 NetworkDo not generally permit containers to be run with the hostNetwork flag set to true.
Workload sharing HostNetworksSharing 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 EscalationDo not generally permit containers to be run with the allowPrivilegeEscalation flag set to true.
Container allowing privileged sub processesA sub-process can gain more privileges than the parent process.
5.2.6 - Root containersDo not generally permit containers to be run as the root user.
Container permitting rootThe 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 rootRunning containers as root can result in pod escape
Container uid is host rangeIt is recommended to run with uid>10000 to avoid conflicts with host user tables
Container with SYS_ADMIN capabilityAssigns SYS_ADMIN capability that is equivalent to root access
5.2.7-NET_RAWDo not generally permit containers with the potentially dangerous NET_RAW capability.
Container with NET_RAW capabilityAssigns NET_RAW capability that allows binding to any address for transparent proxying any host address
5.2.8 - Added capabilitiesDo not generally permit containers with capabilities assigned beyond the default set.
Container with ANY capabilityContainers should not have any capabilities.
5.2.9 - No capabilitiesDo not generally permit containers with capabilities
Container with ANY capabilityContainers should not have any capabilities.
5.4 - SecretsSecrets management
5.4.1 - Secrets Env VarsKubernetes supports mounting secrets as data volumes or as environment variables. Minimize the use of environment variable secrets.
Env variable exposing secretContainers should avoid using secrets in environment variables as applications might print their content
5.4.2 - Ext secret storageConsider 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 secretContainers should avoid using secrets in environment variables as applications might print their content
5.7 - GeneralGeneral security policies
5.7.1 -NamespacingUse namespaces to isolate your Kubernetes objects.
Workload defined in “default” namespacePods should be namespaced to promote isolation
5.7.2 - seccompEnable docker/default seccomp profile in your pod definitions.
Workload with docker.sock accessPods mounting docker.sock can leak information about other container and result in container breakout
Seccomp profile docker/defaultContainers in the workload should use secure computing mode (This is an alpha feature and ranked low)
5.7.4 - Default namespaceKubernetes 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” namespacePods should be namespaced to promote isolation

Sysdig K8s Best Practices (IaC)

Requirmenet GroupGroup DescriptionRequirementRequirement DescriptionControlControl Description
1 - Workload SecurityConfigurations relating directly to security configuration of the workload
1.1 - Workload Default SecurityContextDefining the default security context in the workload is important to prevent misconfigurations and acts as another layer of protection.
Workload container default RunAsUser rootIn case a container in the Pod did not define runAsUser this will set the user to root
Workload container default RunAsGroup rootIn case a container in the Pod did not define runAsGroup this will set the group to root
Workload container default permits rootIn case a container in the Pod did not define runAsNonRoot this will allow it define root as the user
1.2 - Immutable container filesystemThe container filesystem should be immutable. Tampering with the container root filesystem can be due to malware.
Container with writable root file systemA container with writable root filesystem is more exposed to attacks as it allows tampering with executables
1.3 - Immutable container volumesThe container volume mounts should be as immutable as possible. The more immutable = more secured.
Workload with writable volumesPods should mostly use read only volumes to make sure the workload is imutable
1.4 - Disable docker.sock volumeMounting the docker.socket allows the workload to listen get information about other containers and can allow container breakout.
Workload with docker.sock accessPods mounting docker.sock can leak information about other container and result in container breakout
1.5 - Exposing HostPortHostPort is taking up a port from the physical node. Exposing services should be done using Services.
Container exposing HostPortHost port usage may create constraints as to where the Pod can run
1.6 - Container root group accessThe 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 accessRunning with root group context allows access to all files owned by root group
2 - Workload-OperationsConfigurations affecting the day to day operation of the workload
2.1 - Missing container requirementsResource requirements help Kubernetes scheduler to better assign the workloads to nodes.
Workload missing CPU requestNo resource request hurts the scheduler resource assignment for workloads
Workload missing memory requestNo resource request hurts the scheduler resource assignment for workloads
2.2 - Missing container limitsResource limits must be defined to avoid resource stravation by workloads with no limits.
Workload missing CPU limitNo limits configuration could cause process starvation
Workload missing memory limitNo limits configuration could cause process starvation
2.3 - Container image pullContainers should pull images all time (best option) or if the image does not exist locally.
Container permanent imageImages that are not updated from the image repositories may result in tampered images
Container image update if not present onlySetting the pull policy to Always is recommended ensuring the container runs with the most up to date image
2.4 - Container image tagContainers should always define the specific image needed for their proper function.
Container using latest imageImages running with “latest” or blank tag can break down the integrity of the system as update without a specific image
Container using image without digestImage digest is immutable and guarantees all instances will run the same code always
2.5 - Container probesContainers should have readniess and liveness probe configured to assure they only service requests when they are ready to with correct data.
Container without liveness probeContainers should have liveness probe to expose their app status and maintain system integrity
Container without readiness probeContainers should have readiness probe to expose their ability to service request and maintain system integrity
3 - Cluster & Workload AccessConfigurations affecting the workload access and privileged users in the cluster
3.1 - NET_Admin capabilityNetwork 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 capabilityAssigns 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 RangeUID range of containers should avoid the host’s range to avoid collision.
Container uid is host rangeIt is recommended to run with uid>10000 to avoid conflicts with host user tables