Container & Kubernetes Security - Complete Guide

Secure containers and Kubernetes: image scanning, registry hygiene, admission control, RBAC, network policies, and runtime threat detection.

Containers compress trust boundaries by sharing kernel resources while providing process isolation, creating unique security challenges requiring defense-in-depth from image build through runtime execution. Security engineers design Kubernetes platform guardrails that make insecure workloads un-schedulable and risky runtime actions immediately observable. Effective container security treats containers as untrusted workloads requiring isolation, least privilege, and comprehensive monitoring.

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. Google 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—a critical DevSecOps pipeline security practice.

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. Docker Hub, Amazon ECR, Azure Container Registry, and Google Artifact Registry provide managed registry options with security features.

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. This infrastructure hardening prevents common container escape techniques.

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—implementing least privilege at the container level.

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—aligning with cloud compliance and governance requirements.

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. Network segmentation principles apply—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 per secrets management, 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 solutions like Istio or Linkerd provide mutual TLS 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 like Tetragon, or commercial solutions monitors container behavior for suspicious activities. Detection rules identify unexpected process execution, suspicious network connections, and file system modifications—complementing SIEM and log management for container environments.

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. Threat hunting in container environments leverages runtime telemetry.

Software Bill of Materials

Software Bill of Materials (SBOM) generation using tools like Syft, CycloneDX, or SPDX 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—a core DevSecOps pipeline security practice.

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—aligning with zero trust architecture best practices.

etcd encryption at rest protects secrets and sensitive configuration data. Encryption keys should be rotated regularly and stored securely using key management practices.

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 using tools like cert-manager, 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—part of comprehensive incident response planning.

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.

Related Articles

• Container Security in DevOps - CI/CD container security integration
• Software Supply Chain Security - Image signing and supply chain integrity
• Infrastructure as Code Security - IaC for Kubernetes manifests
• Network Security Fundamentals - Network policies and segmentation
• Secrets Management - Kubernetes secrets and external vaults
• Security Architecture Patterns - Service mesh and sidecar patterns
• DevSecOps Pipeline Security - Securing container build pipelines

References

• NSA/CISA Kubernetes Hardening Guide — Federal guidance for securing Kubernetes
• Kubernetes Pod Security Standards — Official pod security policies
• Sigstore Cosign — Container image signing and verification
• SLSA Framework — Supply chain security levels and requirements
• CNCF Cloud Native Security Whitepaper — Comprehensive cloud native security guidance
• Falco — Cloud native runtime security