Container Security

The principle that container images and their runtime configurations should be immutable—never modified after deployment. This eliminates configuration drift and ensures a known, secure state.

• Build once, deploy anywhere: A single, versioned image is promoted through environments.
• No SSH or runtime patching: Vulnerabilities are fixed by rebuilding the image, not by logging into a running container.
• Declarative configuration: Desired state (e.g., via Kubernetes manifests) is version-controlled and applied, preventing manual, error-prone changes.

Containers and the processes within them should run with the minimum necessary privileges to function, drastically reducing the attack surface.

• Non-root users: Containers should not run as the root user (USER directive in Dockerfile).
• Linux Capabilities: Drop all capabilities (--cap-drop=ALL) and add back only specific ones required (e.g., NET_BIND_SERVICE).
• Read-only root filesystems: Mount the container's root filesystem as read-only (readOnlyRootFilesystem: true in Kubernetes) to prevent malicious writes.
• Seccomp/AppArmor profiles: Apply mandatory access control profiles to restrict system calls.

Isolating container traffic using fine-grained network policies to control east-west communication between workloads, preventing lateral movement by an attacker.

• Network Policies: Kubernetes Network Policies define which pods can communicate with each other and on which ports (e.g., ingress/egress rules).
• Service Mesh: Tools like Istio or Linkerd implement mTLS for service-to-service encryption and enforce L7 traffic rules.
• Default deny: The starting posture should be to deny all inter-pod traffic, with rules explicitly allowing necessary communication.

The continuous process of identifying, prioritizing, and remediating vulnerabilities within container images and their dependencies before and during runtime.

• SBOM Generation: Creating a Software Bill of Materials for every image to inventory all components.
• Image Scanning: Integrating static vulnerability scanning (e.g., Trivy, Grype) into the CI/CD pipeline to block images with critical CVEs.
• Signature & Attestation: Signing images with Cosign and generating in-toto attestations to prove the image was built by a trusted process.
• Use of minimal base images: Starting from distroless or Alpine-based images to reduce the attack surface.

Continuously monitoring container behavior during execution to detect and respond to malicious activity that bypasses static defenses.

• Anomaly Detection: Using tools like Falco or Tracee to define rules (e.g., "spawn shell in container," "unexpected network connection") and detect violations.
• File Integrity Monitoring (FIM): Alerting on changes to critical files within a container, even if the filesystem is writable.
• Process & System Call Monitoring: Auditing process execution and kernel-level activity for suspicious patterns.
• Integration with SIEM: Sending runtime security events to a central Security Information and Event Management system for correlation.

Securely storing, managing, and injecting sensitive data (API keys, tokens, passwords) into containers without hardcoding them in images or environment variables.

• External Secret Stores: Using dedicated services like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault.
• Kubernetes Native Secrets: With limitations; often used in conjunction with sidecar injectors (e.g., Vault Agent) or CSI drivers.
• Short-lived, dynamic secrets: Secrets are generated on-demand with short TTLs, reducing the impact of exposure.
• Least-privilege access: Secrets are scoped so a container only has access to the credentials it specifically needs.

A foundational security mechanism for runtime isolation. Sandboxing restricts an application's access to system resources like the filesystem, network, and other processes, creating a constrained environment to limit the impact of a breach.

• Key Mechanism: Uses kernel-level features like seccomp (secure computing mode) to filter system calls.
• Application: Essential for running untrusted code, such as user-submitted plugins or AI-generated tool execution, within a container or alongside a host OS.

The core security tenet that any user, process, or container should operate with the minimum levels of access necessary to perform its function.

• Container Implementation: Applied via Linux capabilities (e.g., dropping NET_RAW), non-root users, and read-only filesystems.
• Impact: Dramatically reduces the attack surface. A compromised container with least privilege cannot mount the host filesystem or manipulate network interfaces.

A kernel framework that enables mandatory access control (MAC) policies, enforcing system-wide security rules beyond standard Linux permissions.

• SELinux: Labels all processes and files, enforcing rules based on type enforcement and role-based access control.
• AppArmor: Uses path-based profiles to define permitted capabilities, file access, and network rules for specific applications.
• Container Role: LSMs provide a critical layer of defense, preventing container breakout even if an attacker gains root inside the container.

A modular, capability-based system interface for WebAssembly (Wasm), providing a sandboxed API for secure access to OS features.

• Design Philosophy: Programs must be explicitly granted capabilities (handles) to resources like files or sockets.
• Security Model: Offers a lighter-weight, language-neutral alternative to full OS containers for isolating single functions or AI tools, with a smaller trusted computing base (TCB).

Extended Berkeley Packet Filter is a technology that allows sandboxed programs to run in the Linux kernel to observe and manipulate system behavior safely.

• Security Observability: Used for runtime security monitoring (e.g., Falco) to detect anomalous container behavior like unexpected process execution or system calls.
• Enforcement: Can be used to implement network security policies and block malicious activity at the kernel level, providing deep visibility into containerized workloads.

A security model that eliminates implicit trust. It assumes the network is hostile and verifies every request as though it originates from an open network.

• Container Application: Treats each container/workload as an untrusted entity. Access to other services, the network, or secrets requires continuous authentication and authorization.
• Key Components: Includes service mesh (e.g., Istio) for mTLS, identity-aware proxies, and dynamic policy engines that enforce access based on workload identity, not just IP address.