Study guide
9.3 Container, Workload & Runtime Security
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
9.3 Container, Workload & Runtime Security
Key Takeaways Explain This Topic AI
Container security requires defense-in-depth spanning static image vulnerability scanning in CI/CD registries, Software Bill of Materials (SBOM) tracking, image cryptographic signing, admission controller validation, and runtime kernel isolation.
A Software Bill of Materials (SBOM) generated in standardized formats (SPDX, CycloneDX) creates a complete inventory of open-source packages, libraries, and nested dependencies to facilitate rapid zero-day remediation.
Cryptographic image signing with Sigstore/Cosign establishes provenance and integrity, allowing Kubernetes Admission Controllers (OPA Gatekeeper, Kyverno) to block unsigned or unverified images before deployment.
Hardening container runtime security entails enforcing non-root user execution (USER 10001), mounting read-only root filesystems, dropping dangerous Linux capabilities (CAP_SYS_ADMIN, CAP_NET_RAW), and applying seccomp and AppArmor profiles.
Kubernetes Pod Security Standards (Privileged, Baseline, Restricted) and eBPF-based network policies (Cilium, Calico) eliminate flat cluster networking by enforcing zero-trust default-deny micro-segmentation.
Last updated: August 2026
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:
Privileged: Unrestricted profile granting full host access and all capabilities. Reserved exclusively for system-level infrastructure agents (CNI plugins, storage CSI drivers).
Baseline: Default minimally restrictive profile. Prevents known privilege escalations while allowing standard default container configurations.
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
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.
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:... ).
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).