Container security is seven layers: image (scan, sign, pin), runtime (Falco, seccomp, AppArmor), network (NetworkPolicy, mTLS, service mesh), secrets (Vault, External Secrets Operator), RBAC (Kubernetes roles, service accounts), supply chain (SLSA, SBOM, attestations), and compliance (CIS benchmarks, audit logs). The team that addresses all seven has defense in depth. The team that addresses one or two has gaps an attacker will find.
Table of contents
- Layer 1: image security
- Layer 2: runtime security
- Layer 3: network security
- Layer 4: secrets management
- Layer 5: RBAC
- Layer 6: supply chain security
- Layer 7: compliance
- Putting it together: a secure cluster checklist
- How this fits the rest of the stack
- FAQ
Layer 1: image security
Scan, sign, pin, non-root. Covered in detail in the container image security post. The team that does this has a clean image baseline; the team that does not has a stream of known CVEs deployed to production.
Layer 2: runtime security
Seccomp - restrict the syscalls a container can make. The default seccomp profile in Kubernetes blocks ~50-100 dangerous syscalls (reboot, mount, kexec_load, etc.). The team that uses the default is fine; the team that uses unconfined accepts all syscalls.
AppArmor / SELinux - mandatory access control. AppArmor profiles are easier to write; SELinux is more thorough but harder. The team on Ubuntu uses AppArmor; the team on RHEL uses SELinux.
Falco - runtime anomaly detection. Hooks into the kernel, watches syscalls, fires on suspicious behavior. The team that has Falco running catches the things that image scanning missed.
Layer 3: network security
NetworkPolicy - Kubernetes-native firewall. Default-deny all ingress and egress, then allow specific traffic. The team that has a default-deny NetworkPolicy and explicit allow rules has the right pattern.
mTLS - mutual TLS between services. Istio, Linkerd, or Cilium. The team that runs a service mesh has mTLS by default; the team without a mesh can use cert-manager + SPIFFE for app-level mTLS.
Service mesh - Istio, Linkerd, Consul Connect. Adds mTLS, traffic management, observability. The team that has 10+ microservices benefits; the team with 3 services does not need it yet.
Layer 4: secrets management
Kubernetes Secrets are base64-encoded, not encrypted. The team that uses them as-is is exposing them in etcd, in kubectl describe, in logs.
Better options:
-
HashiCorp Vault - the gold standard. Dynamic secrets, audit logs, rotation.
-
External Secrets Operator - syncs secrets from AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, Vault into Kubernetes Secrets.
-
Sealed Secrets - encrypted secrets that can be safely committed to git. Bitnami’s project.
The team that has any production secret (database password, API key, TLS cert) uses one of these. The team that checks secrets into git is the team that gets pwned on the next leak.
Layer 5: RBAC
Kubernetes RBAC - Role, ClusterRole, RoleBinding, ClusterRoleBinding. Default in K8s 1.8+. The team that uses the default cluster-admin for everything accepts the risk; the team that uses per-service ServiceAccounts with minimal roles has the right pattern.
Common patterns:
-
CI/CD uses a dedicated ServiceAccount with
create,get,liston Deployments, not*on*. -
Developers have namespace-scoped roles, not cluster-wide.
-
Read-only roles for monitoring, debugging, and on-call access.
The team that uses kubectl create clusterrolebinding --clusterrole=cluster-admin --user=everyone is the team that gets compromised.
Layer 6: supply chain security
SBOM (Software Bill of Materials) - the list of every package in the image. Required by EO 14028 for federal contractors. Tools: Syft, Trivy, Snyk.
SLSA (Supply-chain Levels for Software Artifacts) - a framework for supply chain integrity. Levels 1-3; the team that ships to government or finance targets Level 2 or 3.
Attestations - signed metadata about the build: “this image was built from this commit, by this CI run, on this date”. Tools: in-toto, sigstore.
The team that ships images without an SBOM is the team that finds out about a CVE 3 weeks after the rest of the industry.
Layer 7: compliance
CIS Benchmarks - the Center for Internet Security publishes hardening guides for Kubernetes, Docker, Linux. kube-bench (for K8s) and docker-bench (for Docker) check the configuration against the benchmark.
Audit logs - Kubernetes audit logs record every API call. Cloud providers (EKS, GKE, AKS) have managed audit log integration. The team that does not have audit logs cannot investigate a compromise.
Policy as code - OPA, Kyverno. Enforce rules: “all images must be from the approved registry”, “all pods must have resource limits”, “all deployments must have at least 2 replicas”. The team that uses policy as code has the rules checked at deploy time, not after the fact.
Putting it together: a secure cluster checklist
-
Images scanned in CI, signed, pinned by digest, run as non-root.
-
Seccomp + AppArmor/SELinux enabled. Falco running for runtime detection.
-
Default-deny NetworkPolicy with explicit allows. mTLS for service-to-service.
-
Secrets in Vault or External Secrets Operator. No secrets in env vars or git.
-
RBAC scoped per service. Developers have namespace-scoped roles. CI has minimal roles.
-
SBOM generated on every build. SLSA Level 2+ attestation for production images.
-
CIS benchmark checks in CI. Audit logs flowing to a SIEM. Policy as code enforced.
The team that ticks all 7 boxes has a container security posture that meets most compliance frameworks (SOC 2, ISO 27001, PCI-DSS, HIPAA).
FAQ
Which layer is most important?
All seven. The team that prioritizes one over the others is wrong - an attacker goes through the weakest layer. The team that addresses all seven in proportion (more rigor on layers with the most exposure) has the right model.
Is Falco enough for runtime security?
Falco is the detection layer. The prevention layers (seccomp, AppArmor, NetworkPolicy) are equally important. The team that has only Falco detects attacks but does not prevent them.
Do I need a service mesh for mTLS?
Not necessarily. cert-manager + SPIFFE can do app-level mTLS without a service mesh. The team that has 3 services does not need Istio; the team that has 30 services benefits from a service mesh’s traffic management on top of mTLS.
What is the difference between Seccomp and AppArmor?
Seccomp filters syscalls. AppArmor (and SELinux) filter file access, network access, capabilities. The team that uses both has defense in depth at both the syscall and the resource level.
How do I start with container security?
Pick the lowest-effort, highest-impact layer for your stack. For most teams, that is image scanning in CI (Trivy, 30 minutes to set up). Then add the next layer: NetworkPolicy, then secrets, then runtime. The team that tries to do all 7 layers in one sprint ships none of them well.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: