Containers Rules Checklist
This is the master checklist - 25 enforceable rules spanning image builds, Kubernetes workloads, security, and delivery.
//
Search across all documentation pages
This is the master checklist - 25 enforceable rules spanning image builds, Kubernetes workloads, security, and delivery.
Treat each item as a gate you can wire into a linter, CI job, or admission policy. The dedicated Dockerfile and Kubernetes pages expand the reasoning; this page is the fast, reviewable list.
Run it as a pre-merge and pre-deploy gate. Left-shift the cheap checks into linting and CI, and enforce the non-negotiable ones with a policy engine in the cluster.
Copy the boxes into your pull request template so every service change is reviewed against the same bar.
The four groups map to where each rule is best enforced: build rules in the image pipeline, workload and security rules at admission, and delivery rules in your GitOps controller. None of these rules assume Docker runs your pods - containerd executes them via the CRI on nodes.
FROM node:22.14-slim@sha256:... prevents silent, unreproducible base changes.USER 10001 so the process never starts as UID 0.--mount=type=secret; layers are cached and shippable..dockerignore - exclude .git, node_modules, and local env files from the build context.HEALTHCHECK or rely on K8s probes - do not ship an image with no liveness signal at all.:latest to a cluster.replicas >= 2 and a PodDisruptionBudget - survive node drains and voluntary disruptions.app.kubernetes.io/name, part-of, version, and managed-by.topologySpreadConstraints for real availability.restricted - label namespaces pod-security.kubernetes.io/enforce: restricted.runAsNonRoot, allowPrivilegeEscalation: false, and readOnlyRootFilesystem - harden every container's securityContext.capabilities.drop: ["ALL"], add back only what is proven necessary.Do all 25 rules apply to every service? Almost. A batch job may skip readiness probes and PodDisruptionBudgets, but the security and build rules are universal.
Which rules must be enforced in-cluster versus in CI? Enforce security-critical rules (non-root, PSS restricted, no privilege escalation) at admission. Cheaper hygiene rules can live in CI and linters.
Why digest pinning instead of semantic tags? Tags are mutable; a digest is content-addressed and immutable, so a deploy is exactly reproducible and cannot drift under you.
Is :latest ever acceptable?
Only in throwaway local experiments. In any shared or production cluster it makes rollbacks and audits impossible.
How do I roll these out without blocking every team on day one? Start policies in audit mode, publish the violations, fix the golden-path templates, then switch to enforce.
Where do memory limits matter most? Always set a memory limit to prevent noisy-neighbor OOM cascades. Be cautious with CPU limits, which throttle rather than kill.
How does this relate to the Dockerfile and manifest rule pages? This page is the master index; the Dockerfile and Kubernetes manifest pages expand the reasoning, code, and edge cases behind each grouped item here.
Should image signing block deploys from day one? Verify signatures in audit mode first, onboard your pipelines to cosign, then flip verification to enforce once coverage is high enough to avoid blocking legitimate releases.
Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).
Reviewed by Chris St. John·Last updated Jul 16, 2026