Container and Kubernetes Application Security

Container and Kubernetes application security covers the technical controls, threat models, regulatory obligations, and operational structures that govern workloads running inside Linux containers and orchestrated by Kubernetes. The attack surface of a containerized application spans the container image, runtime, orchestration API, cluster network, secrets management, and supply chain — each layer capable of independent compromise. This reference describes the service sector, professional roles, standards frameworks, and structural tradeoffs that practitioners and organizations navigate when securing container-native infrastructure at scale.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix
• References

Definition and scope

Container security is the discipline of protecting software packaged as OCI-compliant images and executed by a container runtime (such as containerd or CRI-O) against unauthorized access, privilege escalation, host breakout, and supply chain compromise. Kubernetes security extends this scope to the orchestration control plane — including the API server, etcd, scheduler, kubelet, and admission controllers — as well as to the network policies, RBAC configurations, and secrets stores that govern cluster operations.

The formal scope is structured by the NIST Special Publication 800-190, Application Container Security Guide, published by the National Institute of Standards and Technology. SP 800-190 defines five primary risk areas for container environments: image vulnerabilities, image configuration defects, build pipeline vulnerabilities, container runtime threats, and Kubernetes orchestrator weaknesses. The Center for Internet Security (CIS) publishes separate benchmarks for both Docker and Kubernetes, each with scored and unscored recommendations mapped to specific configuration items.

For regulated industries, the scope extends to compliance frameworks. The Payment Card Industry Data Security Standard (PCI DSS v4.0, published by the PCI Security Standards Council) explicitly addresses container environments in Requirement 6 (secure software development) and Requirement 11 (testing security). HIPAA-covered entities under HHS must apply container controls wherever protected health information transits or resides in containerized workloads. The NSA and CISA jointly published Kubernetes Hardening Guidance (first released August 2021, updated April 2022) provides a 66-page technical reference specifically for government and critical infrastructure operators, covering pod security, network separation, audit logging, and supply chain integrity.

This sector is further addressed in the application security providers that catalog professional service providers operating in this space.

Core mechanics or structure

Container and Kubernetes security operates across four distinct structural layers, each requiring independent controls.

Image Layer: A container image is a read-only filesystem assembled from stacked layers defined in a Dockerfile or equivalent build manifest. Vulnerabilities in base images propagate to every derived container. Static image scanning tools evaluate images against CVE databases (the National Vulnerability Database, maintained by NIST, is the canonical public source) before images reach a registry. Signed images using Sigstore's Cosign toolchain or Notary v2 establish cryptographic provenance attestations.

Runtime Layer: The container runtime isolates workloads from the host kernel using Linux namespaces and cgroups. seccomp profiles restrict the syscall surface available to a container; AppArmor and SELinux policies enforce mandatory access controls on the host. Runtime security tools (implementing eBPF-based kernel instrumentation or kernel module hooks) detect behavioral anomalies such as unexpected process spawning, filesystem writes to sensitive paths, or network connections to unexpected endpoints.

Orchestration Control Plane: The Kubernetes API server is the single administrative interface for an entire cluster. Misconfigured RBAC bindings — particularly ClusterRoleBindings granting cluster-admin to service accounts — represent the most prevalent privilege escalation vector documented in public incident reports. Admission controllers (OPA Gatekeeper, Kyverno) enforce policy at the point of resource creation. The etcd datastore contains all cluster state, including Kubernetes Secrets, and requires encryption at rest and mutual TLS between API server and etcd nodes.

Supply Chain Layer: Software supply chain integrity in container environments covers the full chain from source code through build pipeline, base image selection, dependency management, and registry storage to deployment. The SLSA framework (Supply Chain Levels for Software Artifacts), developed under the OpenSSF, defines four provenance levels that formalize build integrity requirements.

Causal relationships or drivers

The expansion of container and Kubernetes security as a distinct professional discipline traces to three converging forces: the architectural shift toward microservices, the regulatory broadening of software supply chain requirements, and the documented exploitation of Kubernetes misconfigurations in production environments.

The 2020 SolarWinds and 2021 Log4Shell incidents, documented by CISA in multiple advisories (AA20-352A and AA21-356A), accelerated the Executive Order 14028 on Improving the Nation's Cybersecurity (signed May 2021), which mandates software bill of materials (SBOM) requirements and supply chain security practices directly applicable to containerized federal software.

The Aqua Security 2023 Cloud Native Threat Report identified that 90% of scanned container images contained at least one known critical or high-severity vulnerability — a structural consequence of base image inheritance rather than individual developer negligence. The Kubernetes API server, when exposed without authentication due to misconfiguration, has been exploited in documented cryptomining and data exfiltration campaigns cataloged in CISA advisories, including those targeting unauthenticated kubelet ports (TCP 10250).

Classification boundaries

Container and Kubernetes security spans four professional service categories, each with distinct technical scope:

Image and Registry Security focuses exclusively on the pre-deployment artifact pipeline — scanning, signing, provenance attestation, and registry access controls. It does not extend into runtime behavior.

Runtime Security addresses behavior of running containers using kernel-level instrumentation. It is distinct from image scanning in that it observes actual execution rather than static analysis of the image filesystem.

Cluster Hardening and Configuration Audit applies structured benchmarks (CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guidance) to control plane components, node configurations, RBAC policies, and network policies. This is a distinct discipline from runtime monitoring.

Cloud-Native Network Security covers Kubernetes Network Policies, service mesh mTLS configurations (Istio, Linkerd), and egress filtering. It is classified separately from host-based network security because Kubernetes overlay networking (CNI plugins: Calico, Cilium, Flannel) operates above the host kernel network stack and requires distinct policy languages.

The describes how these professional categories appear in structured service providers.

Tradeoffs and tensions

Image minimalism vs. operational tooling: Distroless or scratch-based images reduce CVE exposure by eliminating package managers, shells, and debugging utilities. The tradeoff is that incident response and live debugging inside a running container become structurally infeasible without ephemeral debug containers (a Kubernetes feature available since v1.23). Organizations must choose between a smaller attack surface and operational observability.

Admission control policy strictness vs. deployment velocity: OPA Gatekeeper and Kyverno policies that reject pods running as root, require read-only root filesystems, or mandate resource limits reduce blast radius but also block workloads that have not been updated to meet those constraints. Enforcing strict admission policies in a production cluster without a prior audit-only mode pass routinely causes deployment failures for legacy workloads.

RBAC least-privilege vs. developer autonomy: Kubernetes RBAC scoped to namespace-level permissions satisfies the least-privilege principle but creates friction for platform engineering teams that need cross-namespace visibility. The tension between security segmentation and operational convenience frequently drives organizations toward overly permissive role bindings — the precise configuration flaw most often cited in cluster compromise post-mortems.

Immutable infrastructure vs. patch urgency: Immutable deployment patterns (containers are never patched in place; new images are built and redeployed) align with supply chain integrity requirements. When a critical CVE is disclosed, however, the rebuild-and-redeploy cycle may introduce a window of hours or days during which production workloads run vulnerable images.

Common misconceptions

Misconception: Containers provide security isolation equivalent to virtual machines. Containers share the host kernel. A kernel privilege escalation exploit (such as CVE-2022-0492, a Linux cgroup escape documented by Palo Alto Networks Unit 42) can allow a container to gain root access on the host. VM-level isolation requires gVisor, Kata Containers, or hardware-isolated runtimes.

Misconception: Kubernetes RBAC, once configured, remains correct over time. RBAC bindings in active clusters accumulate over the lifecycle of deployed workloads and operator access grants. Without continuous audit, stale ClusterRoleBindings and default service account tokens with excessive permissions accumulate. The NSA/CISA Kubernetes Hardening Guidance specifically calls out default service account token automounting as a misconfiguration requiring explicit remediation across all namespaces.

Misconception: Image scanning at build time is sufficient for container security. Static scanning detects known CVEs present at build time. New CVEs are published continuously — the NVD added over 25,000 new CVE entries in 2022 (NVD Statistics). Images that passed scanning at build time may contain unpatched critical vulnerabilities within weeks of deployment without a continuous re-scan and re-deploy mechanism.

Misconception: Kubernetes Secrets are encrypted. By default, Kubernetes Secrets are base64-encoded and stored in plain text in etcd. Encryption at rest requires explicit configuration of an EncryptionConfiguration resource pointing to a KMS provider or a static key. This is documented in the Kubernetes official documentation on Encrypting Secret Data at Rest.

Checklist or steps (non-advisory)

The following sequence reflects the control implementation phases documented in NIST SP 800-190 and the NSA/CISA Kubernetes Hardening Guidance:

1. Image baseline: Establish a curated set of approved base images. Enable automated CVE scanning (against NVD) in the CI pipeline. Reject images with Critical-severity findings before registry push.
2. Image signing: Implement cryptographic signing using Cosign (Sigstore) or Notary v2. Configure registry to reject unsigned images. Generate and attach SBOM to each image build.
3. Registry access control: Restrict registry push and pull permissions using repository-scoped tokens. Enable vulnerability scanning on push within the registry.
4. Cluster hardening: Apply CIS Kubernetes Benchmark Level 1 controls to all cluster components. Disable anonymous API server authentication. Enable audit logging to an external log store.
5. RBAC audit: Enumerate all ClusterRoleBindings and RoleBindings. Remove cluster-admin grants to service accounts. Disable automatic service account token mounting where not required.
6. Admission control policy enforcement: Deploy OPA Gatekeeper or Kyverno in audit mode. Enumerate policy violations. Move to enforcement mode after remediation. Require non-root UID, read-only root filesystem, and no privileged containers.
7. Runtime policy definition: Define seccomp profiles for workload categories. Apply AppArmor or SELinux profiles to nodes. Deploy runtime threat detection instrumentation.
8. Network segmentation: Implement Kubernetes NetworkPolicy objects to restrict pod-to-pod traffic to declared paths. Enable mTLS between services using a service mesh where east-west encryption is required.
9. Secrets management: Enable etcd encryption at rest. Migrate secrets to an external KMS (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Audit secret access via audit logs.
10. Continuous re-scan: Establish scheduled re-scanning of all images in the registry. Define SLA for rebuild and redeploy on Critical CVE disclosure (CVSS ≥ 9.0).

The how-to-use-this-application-security-resource page describes how service categories aligned to these phases are organized within this reference.

Reference table or matrix