Skip to main content

lacework-global-351

4.6.2 Apply Security Context to Your Pods and Containers (Manual)​

Profile Applicability​

• Level 2

Description​

Apply Security Context to Your Pods and Containers

Rationale​

A security context defines the operating system security settings (uid, gid, capabilities, SELinux role, etc..) applied to a container. When designing your containers and pods, make sure that you configure the security context for your pods, containers, and volumes. A security context is a property defined in the deployment yaml. It controls the security parameters that will be assigned to the pod/container/volume. There are two levels of security context: pod level security context, and container level security context.

Impact​

If you incorrectly apply security contexts, you may have trouble running the pods.

Audit​

Review the pod definitions in your cluster and verify that you have security contexts defined as appropriate.

Remediation​

Best practices recommend that you scope the binding for privileged pods to service accounts within a particular namespace, for example kube-system, and limiting access to that namespace. For all other serviceaccounts/namespaces, best practice recommends implementing a more restrictive policy such as this:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
 name: restricted
 annotations:
 seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
 apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
 seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
 apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
 privileged: false
 # Required to prevent escalations to root.
 allowPrivilegeEscalation: false
 # This is redundant with non-root + disallow privilege escalation,
 # included here for defense in depth.
 requiredDropCapabilities:
 - ALL
 # Allow core volume types.
 volumes:
 - 'configMap'
 - 'emptyDir'
 - 'projected'
 - 'secret'
 - 'downwardAPI'
 # Assume that persistentVolumes set up by the cluster administrator are safe to use.
 - 'persistentVolumeClaim'
 hostNetwork: false
 hostIPC: false
 hostPID: false
 runAsUser:
 # Require the container to run without root privileges.
 rule: 'MustRunAsNonRoot'
 seLinux:
 # This policy assumes the nodes are using AppArmor rather than SELinux.
 rule: 'RunAsAny'
 supplementalGroups:
 rule: 'MustRunAs'
 ranges:
 # Forbid adding the root group.
 - min: 1
 max: 65535
 fsGroup:
 rule: 'MustRunAs'
 ranges:
 # Forbid adding the root group.
 - min: 1
 max: 65535
 readOnlyRootFilesystem: false

This policy prevents pods from running as privileged or escalating privileges. It also restricts the types of volumes you can mount and the root supplemental groups you can add.

Another, albeit similar, approach is to start with policy that locks everything down and incrementally add exceptions for applications that need looser restrictions such as logging agents which need the ability to mount a host path.

References​

https://kubernetes.io/docs/concepts/policy/security-context/
https://learn.cisecurity.org/benchmarks
https://aws.github.io/aws-eks-best-practices/pods/#restrict-the-containers-that-can-run-as-privileged

Last updated on