Containers and orchestration

A container shares the host's kernel, so its runtime settings decide how far one hole in the app can reach. These rules cover how containers run, on one host with Docker, Podman or Compose, or on an orchestrator such as Kubernetes. How images are built and scanned is in the containers chapter of the operations playbook.

Required

• Run containers as a user without root

  INF-73

  Switch to a user without root with USER before the app starts. Give that user write access only to the folders the app writes.

• Never give a container control of the host

  INF-74

  Never run an app container with --privileged, the host's network or process namespace, or the container engine's socket mounted inside.

• Publish only the ports visitors use

  INF-76

  Expose a container port beyond its host or cluster only when visitors must reach it. Bind every other published port to 127.0.0.1, or keep it inside the cluster.

• Probe every Kubernetes workload for readiness and liveness

  INF-78

  Give every container that serves traffic a readiness probe on the app's ready check and a liveness probe on its trivial alive check. Add a startup probe when start takes longer than 10 seconds.

• Set resource requests and a memory limit on every container

  INF-79

  Give every container a CPU and memory request from measured use, and a memory limit. Set a default in each namespace, so a container without them is refused or gets one.

• Deny pod traffic by default with network policies

  INF-81

  Start every namespace with a policy that denies all incoming and outgoing pod traffic. Then allow each path the service needs, by label and port.

• Enforce the restricted pod security standard

  INF-82

  Label every application namespace to enforce the Kubernetes restricted pod security standard. Keep privileged only for named system namespaces.

Recommended

• Make the container file system read-only

  INF-75

  Run containers with a read-only root file system. Mount a volume for data and a tmpfs for scratch files.

• Put each container only on the networks it needs

  INF-77

  Split containers into networks by who must talk to whom. Put the database on an internal network that only the app joins.

• Keep enough copies running through planned disruptions

  INF-80

  Give every workload with two or more copies a PodDisruptionBudget, so node upgrades and drains never take all its copies at once. Spread the copies across nodes and zones.

• Deploy only signed images from tags that cannot move

  INF-83

  Make image tags in the registry immutable, sign each image in CI, and let the cluster or host start only images whose signature checks out.

• Rescan the images that are running every day

  INF-84

  Every day, scan each image that runs in production against the latest vulnerability data. Open a ticket for every new critical or high finding with a fix, and redeploy a fixed image within 7 days.