Container Image and Registry Security
Minimal Base Images Container images should use minimal base images containing only required dependencies, reducing attack surface and vulnerability exposure. Distroless images eliminate package managers, shells, and other utilities unnecessary for application runtime. Minimal images reduce vulnerability counts, simplify security scanning, and prevent attackers from using built-in tools for post-compromise activities. Alpine Linux and distroless images provide good starting points for minimal containers. Image size reduction through multi-stage builds separates build-time dependencies from runtime images, further reducing attack surface. Image Digest Pinning Container image tags are mutable and can be overwritten, creating supply chain risks. Image digest pinning using SHA256 hashes ensures that deployed images match exactly what was tested and approved. Digest pinning prevents tag confusion attacks where attackers overwrite tags with malicious images. Automated image update processes should update digests after validation rather than using floating tags. Private Registry Hygiene Private container registries with allowlists restrict which images can be deployed, preventing deployment of untrusted images. Registry access control ensures that only authorized users and CI/CD systems can push images. Registry vulnerability scanning detects known vulnerabilities in stored images, with policies preventing deployment of images with critical vulnerabilities. Continuous scanning detects newly disclosed vulnerabilities in existing images. Image Signing and Verification Cryptographic image signing with Sigstore Cosign provides provenance verification, ensuring images were built by authorized systems. Signature verification in admission controllers prevents deployment of unsigned or tampered images. Keyless signing with OIDC identity eliminates long-lived signing keys while providing cryptographic proof of image provenance. Signature policies can require specific signers or attestations before allowing deployment.Admission Control and Policy Enforcement
Pod Security Admission Pod Security Admission enforces Pod Security Standards at namespace level, preventing insecure pod configurations. Baseline standard provides essential security restrictions, while restricted standard enforces hardened configurations. Privileged containers, host namespace access (hostPID, hostIPC, hostNetwork), and root user execution should be disallowed except for specific system workloads with documented exceptions. Pod Security Admission operates at admission time, preventing insecure pods from being scheduled rather than detecting them after deployment. Linux Security Modules Seccomp profiles restrict system calls available to containers, preventing exploitation of kernel vulnerabilities through unusual system calls. Default seccomp profiles block dangerous system calls while allowing common application operations. AppArmor and SELinux provide mandatory access control, restricting file system access, network operations, and inter-process communication. Security profiles should be tested with applications to ensure compatibility. Capability Dropping Linux capabilities provide fine-grained privilege control beyond simple root/non-root distinction. Containers should drop all capabilities by default, adding back only required capabilities. Common dangerous capabilities including CAP_SYS_ADMIN, CAP_NET_ADMIN, and CAP_SYS_PTRACE should be avoided except for specific system workloads. Capability requirements should be documented and reviewed. Filesystem and User Controls Read-only root filesystems prevent container filesystem modification, limiting attacker ability to install tools or modify application code. Applications requiring writable storage should use volume mounts for specific directories. Non-root user execution prevents many privilege escalation attacks and limits damage from container escape vulnerabilities. User namespaces provide additional isolation by mapping container root to unprivileged host users. fsGroup controls ensure that volume permissions are set appropriately for application users, preventing permission-related security issues. Policy-as-Code Open Policy Agent (OPA) Gatekeeper, Kyverno, and similar tools provide policy-as-code for Kubernetes admission control. Policies can enforce organizational standards beyond Pod Security Standards. Policy-as-code enables version control, testing, and automated deployment of security policies. Policies should be tested in audit mode before enforcement to identify impacts. Time-bounded exceptions with expiration dates enable necessary policy violations while ensuring periodic review.RBAC and Multi-Tenancy
Namespace Isolation Kubernetes namespaces provide logical isolation for multi-tenant clusters, with separate RBAC policies, resource quotas, and network policies per namespace. Namespace isolation prevents tenants from accessing each other’s resources. Resource quotas prevent resource exhaustion attacks where one tenant consumes all cluster resources. Limit ranges enforce minimum and maximum resource requests and limits. Least Privilege Service Accounts Service accounts should follow least privilege principles, with permissions scoped to specific resources and operations. Default service account tokens should not be automatically mounted unless required. Service account token projection with audience and expiration provides short-lived tokens reducing credential theft risks. Token rotation and revocation capabilities enable rapid response to compromise. Network Isolation NetworkPolicy default deny blocks all pod-to-pod communication, with explicit allowlists for required connections. Network policies should be scoped to specific namespaces and pods. Service mesh mutual TLS provides encrypted communication with cryptographic service identity. Mesh authorization policies enforce fine-grained access control at Layer 7. Egress policies via proxies or network policies restrict outbound connections, preventing data exfiltration and command-and-control communication.Runtime Security and Supply Chain
Runtime Threat Detection Runtime detection using Falco, eBPF-based tools, or commercial solutions monitors container behavior for suspicious activities. Detection rules identify unexpected process execution, suspicious network connections, and file system modifications. Syscall monitoring captures low-level container behavior, detecting container escape attempts, privilege escalation, and kernel exploitation. Behavioral baselines reduce false positives by identifying deviations from normal application behavior. Runtime detection complements admission control by detecting threats that emerge during execution, including compromised applications and zero-day exploits. Software Bill of Materials Software Bill of Materials (SBOM) generation using tools like Syft documents all dependencies in container images, enabling vulnerability tracking and license compliance. SBOMs should be generated during build and stored with images. SBOM verification at deployment ensures that deployed images contain only approved dependencies. Continuous SBOM analysis detects newly disclosed vulnerabilities in deployed images. Supply Chain Security SLSA (Supply chain Levels for Software Artifacts) provenance attestations document build process details including source repository, commit hash, and build platform. Provenance verification ensures images were built through approved processes. Hermetic builds produce reproducible artifacts by eliminating non-deterministic build inputs. Reproducibility enables independent verification that published images match source code. Build attestations verified at deployment time prevent deployment of images built through unapproved processes or from unknown sources.Cluster and Control Plane Security
API Server and etcd Hardening Kubernetes API server should use strong authentication, with client certificates or OIDC integration. Anonymous authentication should be disabled, and authorization should use RBAC. etcd encryption at rest protects secrets and sensitive configuration data. Encryption keys should be rotated regularly and stored securely. API server audit logging captures all API requests, enabling detection of suspicious activities and compliance reporting. Audit logs should be shipped to centralized logging for retention and analysis. Certificate Management Kubernetes uses certificates extensively for component authentication. Certificate rotation should be automated, with monitoring for approaching expiration. Certificate authorities should be protected with appropriate access controls and backup procedures. Compromised CAs require complete cluster rebuild. Control Plane Isolation Control plane components should run on dedicated nodes isolated from workload nodes. Network segmentation prevents workload compromise from affecting control plane. Control plane access should be restricted to authorized administrators through bastion hosts or VPN. Direct internet access to API servers should be avoided. Backup and Disaster Recovery etcd backups enable cluster recovery from data loss or corruption. Backups should be automated, encrypted, and stored securely with regular restore testing. Disaster recovery drills validate backup and restore procedures, ensuring rapid recovery capabilities. Recovery time objectives should be documented and tested.Conclusion
Container and Kubernetes security requires defense-in-depth across image supply chain, admission control, runtime detection, and cluster hardening. Security engineers design platform guardrails that prevent insecure configurations while enabling developer productivity. Success requires treating container security as platform capability rather than application responsibility, with centralized policies and monitoring that apply consistently across all workloads. Organizations that invest in container security fundamentals build secure platforms that resist attacks while maintaining operational agility.References
- NSA/CISA Kubernetes Hardening Guide
- Kubernetes Pod Security Standards
- Sigstore and Cosign Documentation
- SLSA Supply Chain Security Framework
- CNCF Cloud Native Security Whitepaper