9.3 Container, Workload & Runtime Security

Container, Workload & Runtime Security

Containers have revolutionized enterprise software deployment by packaging applications with their operational dependencies into lightweight, portable runtime units. However, because containers share the underlying host operating system kernel rather than running on isolated Type 1 hypervisors, a security vulnerability in a single container can potentially compromise the entire physical or virtual host node.

For the CompTIA Cloud+ (CV0-004) exam, cloud engineers must understand how to secure the complete container supply chain—shifting security left during container builds, generating Software Bills of Materials (SBOM), cryptographically signing container images with Sigstore/Cosign, enforcing policies via Kubernetes Admission Controllers, and applying strict Linux kernel runtime hardening.

---

1. Container Image Security & Vulnerability Scanning

Securing containerized workloads begins in the CI/CD build pipeline before an image is pushed to a container registry or deployed to an orchestration cluster.

+-----------------------------------------------------------------------------------------+
|                        CONTAINER SECURE SUPPLY CHAIN PIPELINE                           |
|                                                                                         |
|   1. BUILD (Multi-Stage)   2. SCAN & SBOM          3. SIGN (Cosign)   4. ADMIT & RUN    |
|   +--------------------+   +-------------------+   +---------------+  +---------------+ |
|   | Multi-Stage Docker |-->| Static CVE Scan   |-->| Sign Image    |->| K8s Admission | |
|   | Minimal Distroless |   | (Trivy/Clair/Grype|   | Hash with     |  | Controller    | |
|   | Base Images        |   | Generate SBOM     |   | Cosign/Rekor  |  | (OPA/Kyverno) | |
|   +--------------------+   +-------------------+   +---------------+  +---------------+ |
+-----------------------------------------------------------------------------------------+

Multi-Stage Docker Builds & Minimal Base Images

Traditional monolithic Dockerfiles package build tools, compilers (e.g., GCC, Maven, npm), shell utilities (bash, curl, netcat), and debuggers directly into the production container image, unnecessarily inflating the attack surface.

• Multi-Stage Builds: Separate the build environment from the final execution runtime. Artifacts compiled in an initial builder stage are copied into a lean, minimal production stage, leaving all build dependencies behind.
• Distroless & Scratch Images: Production images should use Distroless (containing only the application binary and minimal runtime dependencies without a Linux shell or package manager) or Scratch (completely empty base image) to eliminate package management binaries (apt, apk, yum) that attackers leverage post-exploitation.

Static Vulnerability Scanning & SBOM Generation

Container registries (e.g., Amazon ECR, Azure Container Registry - ACR, Google Artifact Registry) and CI tools incorporate static vulnerability scanners (e.g., Trivy, Clair, Grype) that inspect package manifests against the NVD CVE database.

• Software Bill of Materials (SBOM): An authoritative, machine-readable inventory of all software components, third-party libraries, binaries, and nested dependencies contained within a container image. Standardized formats include SPDX (Software Package Data Exchange) and CycloneDX.
• Operational Importance: When a zero-day vulnerability is announced in an open-source library (e.g., Log4j / Apache Commons), security teams query their centralized SBOM repository to instantly locate every deployed container image containing the vulnerable library version without rescanning running clusters.

---

2. Container Image Signing, Provenance & Kubernetes Admission Controllers

Preventing supply chain attacks—such as image tampering, base image poisoning, or unauthorized registry pushes—requires cryptographic image signing and policy-driven deployment validation.

+-----------------------------------------------------------------------------------------+
|                     IMAGE SIGNING & ADMISSION CONTROLLER FLOW                           |
|                                                                                         |
|   CI/CD Pipeline                                                                        |
|   [ Build & Scan ] ===> [ Sign with Cosign / Sigstore (OIDC Keyless) ]                  |
|                                     |                                                   |
|                                     v Pushes Signed Image & Signature                   |
|   [ Enterprise Container Registry (Amazon ECR / ACR / Artifact Registry) ]              |
|                                     |                                                   |
|                                     v kubectl apply -f deployment.yaml                  |
|   +---------------------------------------------------------------------------------+   |
|   | KUBERNETES CONTROL PLANE (kube-apiserver)                                       |   |
|   |                                                                                 |
|   |   Mutating Webhook ===> Validating Admission Webhook (OPA Gatekeeper / Kyverno)  |
|   |                                     |                                           |
|   |                 +-------------------+-------------------+                       |
|   |                 | Verify: Image Signed by Trusted Org?  |                       |
|   |                 | Verify: No High/Critical CVEs?        |                       |
|   |                 | Verify: Registry is Approved?         |                       |
|   |                 | Verify: No `:latest` Tag Used?        |                       |
|   |                 +-------------------+-------------------+                       |
|   |                                     |                                           |
|   |                     +---------------+---------------+                           |
|   |                     |                               |                           |
|   |                  [ PASS ]                        [ FAIL ]                       |
|   |                     |                               |                           |
|   |                     v                               v                           |
|   |          Instantiate Pod on Node          REJECT Deployment Request             |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

Sigstore & Cosign Image Signing

Sigstore is an open-source project providing a standard for signing, verifying, and protecting software artifacts:

• Cosign: Command-line tool used to sign container images, store cryptographic signatures directly in OCI-compliant registries alongside the image, and verify signatures prior to deployment.
• Keyless Signing (Fulcio & Rekor): Instead of managing long-lived private signing keys, Cosign integrates with OpenID Connect (OIDC) identity tokens (from GitHub Actions, GitLab CI) to obtain short-lived X.509 certificates from the Fulcio Certificate Authority, recording cryptographic signatures in the Rekor public transparency log.

Kubernetes Dynamic Admission Controllers

Kubernetes Admission Controllers intercept API requests to the kube-apiserver prior to object persistence in etcd, evaluating requests against governance policies:

• Validating Admission Webhooks: Query external policy engines such as Open Policy Agent (OPA) Gatekeeper (using Rego declarative logic) or Kyverno (using native Kubernetes YAML manifests).
• Enforcement Rules: Block any deployment attempting to pull an image without a valid Cosign cryptographic signature, reject images utilizing the mutable :latest tag, and block containers requesting root execution.

---

3. Container Runtime Hardening & Linux Kernel Defense

Because containers share the host Linux kernel, runtime security must enforce strict boundaries to prevent container breakout—an attack where malicious code escapes container isolation and gains access to the host operating system.

+-----------------------------------------------------------------------------------------+
|                        LINUX KERNEL RUNTIME DEFENSE LAYERS                              |
|                                                                                         |
|   Layer / Mechanism        Configuration Setting               Security Effect          |
|   +----------------------+-----------------------------------+------------------------+ |
|   | Non-Root Execution   | runAsNonRoot: true                | Blocks execution as    | |
|   |                      | runAsUser: 10001                  | UID 0 (root user)      | |
|   |                      |                                   |                        | |
|   | Read-Only Root FS    | readOnlyRootFilesystem: true      | Prevents modifying     | |
|   |                      |                                   | binaries or downloading| |
|   |                      |                                   | malicious scripts      | |
|   |                      |                                   |                        | |
|   | Linux Capabilities   | capabilities: drop: [ALL]         | Strips elevated kernel | |
|   |                      | (Never grant CAP_SYS_ADMIN)       | administration privileges|
|   |                      |                                   |                        | |
|   | Seccomp Filtering    | seccompProfile: RuntimeDefault    | Restricts dangerous    | |
|   |                      |                                   | system calls (syscalls)| |
|   |                      |                                   |                        | |
|   | AppArmor / SELinux   | apparmor.security.beta...         | Enforces Mandatory     | |
|   |                      |                                   | Access Control (MAC)   | |
|   +----------------------+-----------------------------------+------------------------+ |
+-----------------------------------------------------------------------------------------+

Linux Capabilities

Linux divides root privileges into distinct units called capabilities. By default, Docker and Kubernetes grant containers a subset of capabilities that may allow privilege escalation.

• Best Practice: Explicitly drop all capabilities (drop: ['ALL']) and selectively add back only the specific single capability strictly required for operation (e.g., add: ['NET_BIND_SERVICE'] to bind to port 80/443).
• Dangerous Capabilities: Never grant CAP_SYS_ADMIN (equivalent to full root host compromise), CAP_NET_RAW (allows packet sniffing and IP spoofing), or CAP_SYS_PTRACE (allows debugging host processes).

Read-Only Root Filesystem & Non-Root Execution

• readOnlyRootFilesystem: true: Locks the container root file system into read-only mode. If an attacker discovers a remote code execution vulnerability, they cannot write malicious scripts, modify system binaries, or download malware payloads. Ephemeral temporary data must be written to explicit, non-executable emptyDir memory mounts (/tmp).
• Non-Root Execution: Attackers who compromise a container running as root (UID 0) can exploit kernel vulnerabilities to gain root on the host node. Hardened pods enforce runAsNonRoot: true and specify a dedicated unprivileged UID/GID (e.g., 10001).

Seccomp (Secure Computing Mode) & AppArmor

• Seccomp: Filters the Linux system calls (syscalls) a process can execute. The Linux kernel contains over 300 syscalls; a typical web microservice requires fewer than 50. Seccomp blocks dangerous syscalls like ptrace, sys_chroot, and kexec_load.
• AppArmor / SELinux: Enforces Mandatory Access Control (MAC) profiles restricting file paths, network operations, and socket interactions regardless of user permissions.

---

4. Pod Security Standards & Microservices Network Segmentation

Kubernetes Pod Security Standards (PSS)

Replacing legacy PodSecurityPolicies (PSP), Kubernetes implements Pod Security Standards across three distinct compliance profiles:

1. Privileged: Unrestricted profile granting full host access and all capabilities. Reserved exclusively for system-level infrastructure agents (CNI plugins, storage CSI drivers).
2. Baseline: Default minimally restrictive profile. Prevents known privilege escalations while allowing standard default container configurations.
3. Restricted: Heavily hardened profile enforcing modern best practices. Requires pods to run as non-root, drop all capabilities, mount a read-only root filesystem, and enforce seccomp profiles.

Microservices Network Micro-Segmentation

By default, Kubernetes networking is flat: any pod in any namespace can initiate network connections to any other pod. To enforce zero-trust architecture, cloud engineers implement Kubernetes NetworkPolicies and eBPF service meshes (e.g., Cilium, Calico).

• Default-Deny Ingress & Egress: Every namespace should declare a baseline policy dropping all inbound and outbound traffic by default.
• Explicit Label Selectors: Ingress and egress rules must explicitly whitelist communication only between authorized microservices (e.g., only frontend pods labeled role: web may communicate with backend pods labeled role: api on TCP port 8080).

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-ingress-allow-web-only
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: order-api
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web-frontend
    ports:
    - protocol: TCP
      port: 8080

CompTIA Cloud+ Exam Traps & Real-World Gotchas

1. Containers vs. Hypervisors: Containers do NOT provide the same hardware-level hardware virtualization boundary as Type 1 hypervisor virtual machines. Multiple containers on a node share a single Linux kernel. Hardening the securityContext is mandatory to mitigate host kernel compromise.
2. The :latest Tag Trap: Deploying container images with the tag image:latest introduces severe operational and security risks because the image digest changes unpredictably over time, bypassing immutable version tracking. Deployments must reference immutable tags or SHA-256 digests (image@sha256:...).
3. NetworkPolicies Require CNI Support: Applying a Kubernetes NetworkPolicy YAML manifest does nothing if the underlying cluster CNI plugin (e.g., basic Flannel) does not support network policy enforcement. The cluster must use an enforcement-capable CNI (e.g., Calico, Cilium, AWS VPC CNI with network policy enabled).