Container and Kubernetes adoption continues to accelerate, but so do the attacks targeting them. Ninety percent of organizations reported Kubernetes security incidents in recent surveys, and vulnerability counts in the Kubernetes ecosystem grew 440% over two years. Kubernetes 1.32 (“Penelope”) introduced fine-grained Kubelet API authorization and advanced credential tracking, while eBPF-based security tools like Tetragon and Falco have matured from experimental to production-grade enforcement engines.
This guide covers security across the full container lifecycle, from image building to runtime protection, with practical implementation guidance.
Container Image Security
Building Secure Images
The container image is the foundation. Insecure images create vulnerabilities that no amount of runtime protection can fully mitigate.
When selecting base images, use minimal options like distroless (gcr.io/distroless), Alpine, or scratch. Avoid general-purpose OS images (ubuntu, centos) unless specific packages are required. Pin base image digests, not tags, because tags can be overwritten. Rebuild images regularly to incorporate base image security patches.
Here’s a Dockerfile following these practices:
# Use specific digest, not tag
FROM cgr.dev/chainguard/node:latest@sha256:abc123...
# Run as non-root
RUN addgroup -S app && adduser -S app -G app
USER app
# Use read-only filesystem
# (enforced at runtime via Pod Security)
# Multi-stage build — don't ship build tools
COPY --from=builder /app/dist /app
For image scanning, run scans in CI/CD before pushing to registry using tools like Trivy, Snyk Container, or Grype. Scan in registries continuously through ECR scanning, ACR Defender, or Artifact Registry scanning. Block deployment of images with critical/high vulnerabilities using admission controllers, and generate SBOMs for every image using Syft or Trivy.
Image Signing and Verification
To ensure only trusted images run in your clusters, sign images with cosign (Sigstore) using keyless signing via OIDC identity. Enforce signature verification at admission using Kyverno or Connaisseur. AWS users can leverage AWS Signer with CloudTrail audit integration. Azure AKS users can use Image Integrity with Ratify + Azure Policy + Gatekeeper. The Kubernetes release process itself uses cosign keyless signing for all binary artifacts.
Kubernetes Cluster Security
Authentication and Authorization
For API Server authentication, disable anonymous authentication except for health-check endpoints (the default in EKS 1.32). Use OIDC federation for user authentication and avoid client certificates and static tokens. Rotate service account tokens automatically using projected service account tokens, which are short-lived and audience-bound.
For RBAC, apply least privilege by starting with no access and grant specifically. Avoid cluster-admin bindings except for break-glass emergency access. Use namespace-scoped roles instead of cluster roles where possible. Audit RBAC regularly using kubectl auth can-i --list and tools like Kubescape or rbac-police. Remove default service account token mounts for pods that don’t need API access.
Pod Security Standards
Kubernetes Pod Security Standards (PSS) define three security profiles enforced by the Pod Security Admission controller:
| Profile | Use Case | Key Restrictions |
|---|---|---|
| Privileged | Infrastructure components (CNI, storage drivers) | No restrictions |
| Baseline | Most workloads | Blocks known privilege escalations, host namespaces, host ports |
| Restricted | Security-sensitive workloads | Non-root, read-only root filesystem, dropped capabilities, seccomp required |
To apply the restricted profile to a namespace:
apiVersion: v1
kind: Namespace
metadata:
name: production
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
Start with warn mode to identify violations, then progress to audit, then enforce.
Network Policies
By default, all pods can communicate with all other pods because Kubernetes has no network segmentation out of the box. Define NetworkPolicy resources to restrict pod-to-pod communication to documented flows. Start with a default-deny policy for each namespace, then allow specific traffic. Use labels consistently to group workloads for policy targeting. CNI plugins that support NetworkPolicy include Cilium, Calico, and Weave Net.
# Default deny all ingress in a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
Secrets Management
Kubernetes Secrets are base64-encoded, not encrypted, by default. Enable encryption at rest for etcd (EncryptionConfiguration with AES-CBC or KMS provider). Use external secrets operators to sync secrets from HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Avoid mounting secrets as environment variables and instead use volume mounts with specific file permissions. Rotate secrets automatically and audit secret access through API audit logs.
Runtime Security
eBPF-Based Security Tools
eBPF (extended Berkeley Packet Filter) enables kernel-level visibility and enforcement with minimal performance overhead (under 1% CPU for most workloads).
Falco (CNCF Graduated) provides runtime threat detection via an eBPF rule engine. It detects shell spawns in containers, unexpected network connections, file access violations, and privilege escalation attempts. It supports both kernel module and eBPF driver modes and integrates with SIEM/SOAR for alert routing.
Tetragon (Cilium/CNCF) handles kernel-level policy enforcement via LSM (Linux Security Module) hooks. It blocks malicious processes in real-time rather than just alerting, tracks process lifecycle with full ancestry chain, and runs at under 1% CPU overhead in production deployments.
A recommended stack uses Falco for detection (alert on suspicious behavior) and Tetragon for enforcement (block known-bad behavior). Combined with Trivy for scanning and Cilium for networking, this provides a comprehensive open-source security stack at 1-2.5% combined CPU overhead.
Runtime Best Practices
Run containers as non-root using runAsNonRoot: true and runAsUser in security context. Use read-only root filesystems with readOnlyRootFilesystem: true. Drop all Linux capabilities and add back only what’s needed with drop: ["ALL"]. Enable seccomp profiles at minimum using RuntimeDefault, or create custom profiles. Set resource limits (CPU, memory) to prevent denial-of-service from compromised containers. Use user namespaces (beta/on-by-default in Kubernetes 2025 releases) for workload isolation.
Service Mesh Security
Istio Ambient Mode
Istio ambient mode reached Stable in Istio 1.24, providing zero-trust networking without sidecar proxies.
The architecture includes Ztunnel (per-node), which handles L4 traffic for mTLS, identity, and basic authorization. Waypoint proxy (optional, per-service) handles L7 traffic for HTTP routing, advanced authorization, and observability.
Benefits include no sidecar containers (reducing resource overhead and deployment complexity), automatic mTLS between all pods in the mesh, per-service authorization policies without application changes, and multi-cluster support (alpha in Istio 1.27).
Use service mesh when you need mTLS between services without application changes, when you need fine-grained authorization policies (like “service A can call service B’s /api/v1/users endpoint with GET only”), when you need observability (request traces, latency metrics) without instrumenting application code, or when your threat model includes lateral movement between services.
Supply Chain Integrity
Image Provenance
Establish a trusted supply chain from source code to running container. At the source level, use signed commits, protected branches, and required reviews. For the build phase, use hermetic builds in isolated CI/CD environments with SLSA provenance generation. For artifacts, sign images with cosign and generate SBOMs and attestations. In the registry, use immutable tags, vulnerability scanning, and access controls. At deployment, use an admission controller verifying signatures and provenance before scheduling.
Admission Controllers
Use admission controllers as the enforcement point for supply chain policies.
Kyverno provides policy-as-code for Kubernetes in a YAML-native format requiring no programming. It can verify image signatures, enforce labels, and validate resource configurations. It can also generate and mutate resources automatically.
OPA Gatekeeper is a general-purpose policy engine using the Rego language. ConstraintTemplates define reusable policy patterns. It’s more flexible but has a steeper learning curve than Kyverno.
Monitoring and Incident Response
Kubernetes Audit Logging
Enable and monitor Kubernetes API audit logs since they record every API request to the cluster. Configure the audit policy to capture at minimum authentication events, RBAC changes, secret access, workload creation/deletion, and exec into pods. Forward audit logs to SIEM for correlation with other security telemetry. Alert on kubectl exec into production pods, RBAC binding changes, secret access from unexpected service accounts, and creation of privileged pods.
Container Forensics
When an incident occurs in a containerized environment, don’t delete the pod. Capture the container state first. Use kubectl debug to attach an ephemeral container for investigation. Capture the container filesystem using kubectl cp or volume snapshots. Export Falco/Tetragon alerts and audit logs for the time window. Image the node if the compromise may have escaped the container.
Getting Started
Begin by scanning images in CI/CD with Trivy or Grype, blocking critical vulnerabilities from reaching registries. Apply Pod Security Standards starting with warn mode on all namespaces, then move to enforce on production. Implement NetworkPolicies using default-deny per namespace, then allow specific documented flows. Deploy Falco for runtime detection starting with default rules, then tune for your environment. Sign images with cosign and enforce verification with Kyverno. Enable audit logging and forward to SIEM for correlation. Encrypt secrets at rest in etcd and migrate to an external secrets manager.