# Container and Kubernetes Security
Container security encompasses the controls that protect containerized applications throughout their lifecycle: from image creation through registry storage, deployment, runtime operation, and decommissioning. Kubernetes security extends this to the orchestration layer that manages containerized workloads at scale: cluster configuration, network policies, role-based access control, secrets management, and runtime monitoring.
Containers (Docker, containerd, CRI-O) package applications and their dependencies into isolated units that run consistently across environments. Kubernetes (K8s) orchestrates those containers: scheduling them across nodes, scaling them based on demand, managing their networking, and restarting them when they fail. Together, containers and Kubernetes form the infrastructure layer for cloud-native applications, microservices architectures, and modern CI/CD pipelines.
The security challenge: containers are ephemeral (they may exist for minutes), numerous (a single application may comprise dozens of containers), and abstract (layers of orchestration between the container and the underlying infrastructure create visibility gaps). Traditional security tools designed for persistent servers with static IP addresses and long lifecycles do not map cleanly to container environments where workloads appear, scale, and disappear continuously.
The container image is the package from which containers are instantiated. Image security is the first and most impactful control point because a vulnerable image produces vulnerable containers at every deployment.
Base image selection. Every container image is built on a base image (an OS layer: Ubuntu, Alpine, Red Hat UBI, or a distro-less/scratch image). The base image's vulnerability count directly affects every image built on it. Alpine and distro-less images contain fewer packages and therefore fewer vulnerabilities than full OS images. Selecting minimal base images reduces the attack surface before the application code is even added.
Image scanning. Container image scanners (Trivy, Snyk Container, Aqua, Anchore, Sysdig) analyze images for known vulnerabilities in OS packages, application dependencies, and configuration issues. Scanning should occur at three points: during the CI/CD build pipeline (blocking images that exceed the vulnerability threshold from being pushed to the registry), in the container registry (scanning stored images on a recurring schedule to catch newly disclosed vulnerabilities), and at deployment admission (Kubernetes admission controllers reject pods that reference images with critical unpatched vulnerabilities).
Image signing and verification. Signing container images with cryptographic signatures (using Cosign/Sigstore or Notary) and verifying signatures at deployment ensures that only images from trusted sources are deployed. Without image signing, an attacker who compromises the container registry can replace a legitimate image with a malicious one. Signature verification detects the tampering.
Hardened images. CIS Benchmarks for Docker provide configuration guidelines for container images: run as non-root user, do not include unnecessary packages, do not store secrets in images, set read-only file systems where possible, and define health checks. Hardened images reduce the attacker's options if the container is compromised.
Kubernetes introduces its own attack surface through the cluster's control plane, API server, networking, and role-based access control:
API server hardening. The Kubernetes API server is the control plane's primary interface. Every kubectl command, every pod scheduling decision, and every configuration change goes through the API server. Securing it requires: enabling authentication (no anonymous access), enforcing authorization (RBAC, not ABAC), enabling admission controllers (Pod Security Standards, OPA Gatekeeper), encrypting API server communication (TLS), and restricting network access to the API server (not exposed to the internet unless absolutely necessary, and then behind authentication and IP restriction).
RBAC (Role-Based Access Control). Kubernetes RBAC controls who can perform what actions on which resources within the cluster. Over-permissive RBAC is the Kubernetes equivalent of standing domain admin accounts: a service account with cluster-admin privileges that is compromised provides complete control over every workload in the cluster.
RBAC design follows least privilege: developers receive access to their namespaces, not to the entire cluster. CI/CD service accounts receive deployment permissions in target namespaces, not cluster-wide. Monitoring tools receive read-only access. No human user should have persistent cluster-admin. Just-in-time elevation through tools like Teleport or kubectl plugins provides temporary cluster-admin access when needed.
Network policies. By default, all pods in a Kubernetes cluster can communicate with all other pods. This is the equivalent of a flat network. Kubernetes Network Policies (enforced by CNI plugins like Calico, Cilium, or Antrea) restrict pod-to-pod communication to explicitly authorized paths. A web frontend pod can communicate with the API backend pod. The API backend can communicate with the database pod. The web frontend cannot communicate directly with the database. Network policies are micro-segmentation for containers.
Secrets management. Kubernetes stores secrets (API keys, database credentials, TLS certificates) as base64-encoded objects that are not encrypted by default in etcd (the cluster's data store). Enabling encryption at rest for Kubernetes secrets (using a KMS provider) and integrating with external secrets managers (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) through the Secrets Store CSI Driver prevents credential exposure from etcd compromise.
Pod Security Standards. Kubernetes Pod Security Standards (Baseline, Restricted) define security profiles that restrict pod capabilities: no privileged containers, no host namespace access, no root execution, restricted volume types, and required security contexts. Admission controllers enforce these standards at pod creation, rejecting pods that violate the profile. Running containers as root with host namespace access is the Kubernetes equivalent of running services as local admin on Windows: it works, and it is a critical security failure.
Container runtime security monitors container behavior during execution for indicators of compromise:
Behavioral monitoring. Runtime security tools (Falco, Sysdig Secure, Aqua Runtime, Prisma Cloud Compute) define expected container behavior (which processes should run, which files should be accessed, which network connections should be made) and alert on deviations. A web server container that spawns a shell process, reads /etc/shadow, or establishes an outbound connection to an IP in a threat intelligence blocklist is exhibiting behavior inconsistent with its expected profile.
Drift detection. Containers should be immutable: the running container should match the image it was deployed from. Drift detection identifies modifications to the container's filesystem at runtime (new binaries written, configuration files modified, additional packages installed), which may indicate compromise or unauthorized modification.
Forensic capture. When a container exhibits suspicious behavior, runtime security tools can capture the container's state (filesystem, network connections, process tree) before the container is terminated. Because containers are ephemeral, traditional forensic approaches (image the disk, analyze offline) do not work. Runtime forensic capture preserves evidence that would otherwise be lost when the container is recycled.
Containers and Kubernetes are the default infrastructure for cloud-native applications. Over 90% of organizations use containers in some capacity. Kubernetes is the dominant orchestration platform. Every major cloud provider offers managed Kubernetes (EKS, AKS, GKE). The security of containerized workloads is not a niche concern. It is a mainstream infrastructure security requirement.
Container images pull from public registries (Docker Hub, GitHub Container Registry, Quay.io) that contain millions of images, many unmaintained and many containing known vulnerabilities. A developer who pulls a base image from Docker Hub without scanning it imports every vulnerability in that image into the organization's production environment. Container supply chain security (image scanning, signature verification, approved registry policies) addresses this vector.
The xz utils backdoor (March 2024) demonstrated that even widely-used, trusted open-source components can be compromised through patient social engineering. Container images that depend on these components inherit the compromise. SCA and image scanning are the detection layers.
Kubernetes misconfiguration is the primary container security risk, paralleling cloud misconfiguration for IaaS. The NSA/CISA Kubernetes Hardening Guide (2022) identifies the most common misconfigurations: running containers as root, not using network policies, over-permissive RBAC, exposed dashboards, and unencrypted secrets. Each misconfiguration provides an attack path that a correctly configured cluster would block.
Aqua Security's 2024 Cloud Native Threat Report found that over 50% of container environments have at least one critical misconfiguration. The Kubernetes attack surface is well-documented (MITRE ATT&CK includes a Containers matrix), and automated tools exist to detect misconfigurations. The gap is operational: applying the fixes and maintaining the configuration over time.
Container and Kubernetes security sits at the intersection of VSD (Vulnerability and Surface Defense) and SPH (Security Posture and Hygiene) in the Planetary Defense Model. VSD owns the vulnerability dimension: image scanning, supply chain risk, and vulnerability management for containerized components. SPH owns the posture dimension: cluster configuration, runtime monitoring, and drift detection.
CDA's Continuous Surface Reduction (CSR) methodology applies to containers: every package in the image that is not operationally necessary is an exposed surface that CSR eliminates. Minimal base images, multi-stage builds that exclude build dependencies from runtime images, and hardened configurations reduce the container attack surface before deployment.
CDA's Autonomous Posture Command (APC) monitors container posture continuously. Image vulnerability density, cluster configuration compliance (against CIS Benchmarks or NSA/CISA Hardening Guide), network policy coverage, RBAC compliance, and runtime anomaly rates are posture metrics tracked in the SPH and VSD domain scores.
Two TOP missions connect to container security:
CDA approaches container security with one emphasis: admission control is the highest-leverage control point. A Kubernetes admission controller that rejects pods with critical vulnerabilities, privileged containers, or root execution prevents insecure workloads from reaching production regardless of whether the development team followed secure practices. Admission control is the gate. Everything that runs in the cluster passes through it. Making the gate strict makes the cluster secure by default rather than by discipline.
Word count: 1,942