Container runtime configuration

In Kubernetes, containers run inside pods, one of several Kubernetes Objects, and each Pod’s runtime configuration can be set and enforced using a combination of security context in the Pod specification, Pod Security Policies (PSPs), or an admission controller like the Open Policy Agent (OPA) Gatekeeper.

Security Context is defined in the deployment manifest and allows you to define the exact requirement for each workload. It can be configured for a Pod or Container. Pod Security Policies are a cluster-level Kubernetes resource that control the security context Pods can run with. If PSPs are enabled for a cluster, any attempt to create a Pod which does not adhere to its associated PSP will be rejected by the PSP admission controller.

Limit container runtime privileges:

  • Do not run application processes as root. Set runAsUser to MustRunAsNonRoot
  • Do not allow privilege escalation. Set allowPrivilegeEscalation to false
  • Use a read-only root filesystem. Set readOnlyRootFilesystem to true
  • Use the default (masked) /proc filesystem mount
  • Do not use the host network or process space. Set hostPID, hostNetwork, and hostIPC to false
  • Drop unused Linux capabilities and do not add optional capabilities that your application does not absolutely require.
  • Use SELinux options for more fine-grained process controls.
  • Give each application its own Kubernetes Service Account.
  • Do not mount the service account credentials in a container if it does not need to access the Kubernetes API.

Use Kubernetes namespaces

Kubernetes namespaces provide scoping for cluster objects, allowing fine-grained cluster object management. Containers/Pods, services, and deployments within a namespace can be isolated using controls like Kubernetes network policies or have their access restricted using Kubernetes Role-Based Access Control (RBAC).

Plan out how you want to assign namespaces before you start deploying workloads to your clusters. Having one namespace per application provides the best opportunity for control, although it does incur additional management overhead when assigning RBAC role privileges and default network policies. If you do decide to group more than one application into a namespace, the main criteria should be whether those applications have common RBAC requirements and whether it would be safe to grant those privileges to the service accounts and users which need Kubernetes API access in that namespace.

Last updated: Jun-2-2020