This chapter covers container and Kubernetes security, a critical topic for the Security+ SY0-701 exam under Domain 3.0 Security Architecture, Objective 3.6: Given a scenario, implement and maintain security controls for containerization and orchestration. As organizations adopt microservices and cloud-native architectures, understanding how to secure containers and Kubernetes clusters is essential. This chapter will explain the core concepts, attack vectors, defense mechanisms, and exam-specific tricks to help you ace related questions.
Jump to a section
Imagine a massive cargo ship carrying thousands of standardized shipping containers. Each container is sealed and isolated from the others, containing goods from different companies. The ship's crew (the host OS) manages the containers, but they cannot see inside them without authorization. In this analogy, the container's seal and lock represent the isolation provided by cgroups and namespaces. A vulnerability in a container (e.g., a weak lock) could allow an attacker to break into that container, but they would still be trapped inside unless they can breach the container's walls (escape the namespace). Kubernetes acts as the port authority, orchestrating where containers are placed, how they communicate, and who can access them. It uses network policies (like customs rules) to control traffic between containers, and role-based access control (RBAC) to decide which crew members can move containers. If an attacker compromises a container, they might try to escape to the host (like breaking out of a container onto the ship) or move laterally to other containers (like sneaking into another container's cargo). Security measures include keeping containers minimal (no unnecessary tools), running them as non-root users (no captain privileges), and using read-only filesystems (sealed cargo manifest). Kubernetes secrets are like locked safes inside containers, but if the safe key is exposed in environment variables, it's as bad as leaving the safe open.
What Are Containers and Kubernetes?
Containers are lightweight, portable execution environments that package an application with its dependencies. Unlike virtual machines, containers share the host OS kernel, making them more efficient but also introducing unique security challenges. Docker is the most common container runtime, but others like containerd and CRI-O are also used. Kubernetes (K8s) is an orchestration platform that automates deployment, scaling, and management of containerized applications.
Container Isolation Mechanisms
Containers achieve isolation through two Linux kernel features: - Namespaces: Provide process-level isolation. Each container gets its own view of the system (e.g., PID, network, mount, user namespaces). This prevents a process in one container from seeing processes in another. - Control Groups (cgroups): Limit and account for resource usage (CPU, memory, disk I/O). This prevents a container from consuming all host resources (denial of service).
However, containers share the kernel, so a kernel vulnerability can allow container escape. For example, CVE-2019-5736 (runC vulnerability) allowed a malicious container to overwrite the host runC binary and gain root access.
Kubernetes Architecture and Security Boundaries
A Kubernetes cluster consists of: - Control Plane: API server, etcd (key-value store), scheduler, controller manager. - Nodes: Worker machines running pods (groups of containers).
Security boundaries: - Pod-to-Pod: Network policies control traffic. - Pod-to-Host: Container escape is the main threat. - User-to-API Server: Authentication, authorization (RBAC), and admission control. - API Server to etcd: etcd stores all cluster data (secrets, configs). If compromised, attacker gets everything.
Attack Vectors
Container Escape: Exploit a kernel vulnerability to break out of the container and gain host access.
Insecure Container Images: Images with vulnerabilities, backdoors, or unnecessary tools (e.g., compilers, shells).
Privileged Containers: Running with --privileged flag grants almost all capabilities, making escape trivial.
Secrets Exposure: Storing secrets in environment variables or in images (hardcoded).
Kubernetes Misconfigurations: Overly permissive RBAC, default service accounts, exposed dashboards, etc.
Supply Chain Attacks: Compromised base images or dependencies.
Defense Mechanisms
Image Scanning: Use tools like Trivy, Clair, or Anchore to scan images for vulnerabilities before deployment.
Least Privilege: Run containers as non-root user, drop unnecessary capabilities (e.g., --cap-drop=ALL), and use read-only root filesystem.
Pod Security Standards (PSS): Kubernetes defines three policies: Privileged, Baseline, Restricted. Restricted is the most secure, disallowing privileged containers, host networking, etc.
Network Policies: Define ingress/egress rules for pods. By default, all pods can communicate; network policies restrict this.
Secrets Management: Use Kubernetes Secrets (encrypted at rest in etcd) or external vaults (HashiCorp Vault). Mount secrets as volumes, not environment variables.
Runtime Security: Use tools like Falco to detect anomalous behavior (e.g., shell spawned in a container).
Admission Controllers: Enforce policies at pod creation (e.g., PodSecurity admission, OPA/Gatekeeper).
Immutable Infrastructure: Rebuild containers from known good images rather than patching running ones.
Secure Configuration Example
A secure pod spec may look like:
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsUser: 1000
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
readOnlyRootFilesystem: true
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}Monitoring and Auditing
Kubernetes Audit Logs: Enable audit logging to record API requests.
Falco: A CNCF project that monitors system calls and container behavior.
kube-bench: Runs CIS benchmarks against the cluster.
kube-hunter: Penetration testing tool for Kubernetes.
Scan Images for Vulnerabilities
Before deploying any container image, scan it using a tool like Trivy. Run: `trivy image myapp:latest`. The tool checks the image layers against known vulnerability databases (e.g., CVE). If critical vulnerabilities are found, the image should be rebuilt with patched dependencies. For example, an image containing a vulnerable version of OpenSSL (CVE-2022-0778) would be flagged. In a CI/CD pipeline, this scan should block deployment if the severity exceeds a threshold. Common mistake: scanning only the base image but not the application layer dependencies.
Enforce Pod Security Standards
Apply the 'Restricted' Pod Security Standard via an admission controller. This can be done by enabling the PodSecurity admission plugin in Kubernetes 1.23+. For example, label a namespace: `kubectl label ns my-namespace pod-security.kubernetes.io/enforce=restricted`. This prevents pods from running as root, using privileged containers, or mounting host paths. If a developer tries to deploy a privileged pod, it will be rejected. Logs: the API server will return an admission error. Common mistake: using 'Privileged' policy (which allows everything) or forgetting to enforce policies on all namespaces.
Implement Network Policies
By default, all pods can communicate. Create a NetworkPolicy to restrict traffic. Example: allow only frontend pods to talk to backend pods on port 8080. Apply with: `kubectl apply -f network-policy.yaml`. The policy uses labels to select pods. If no policy is applied, the default is allow all. To deny all ingress by default, create a policy that selects all pods but has no ingress rules. Tools like Calico or Cilium can enforce these policies. Common mistake: assuming network policies work without a CNI plugin that supports them (e.g., Flannel does not enforce network policies by default).
Configure RBAC for Least Privilege
Create a Role and RoleBinding for a service account that only has get and list permissions on pods. Example: `kubectl create role pod-reader --verb=get,list --resource=pods`. Then bind it to a service account. Avoid using cluster-admin roles for applications. For human users, use groups and map them to roles. Audit logs will show unauthorized access attempts. Common mistake: using default service accounts or granting wildcard permissions (`*`).
Enable Audit Logging and Monitor
Configure Kubernetes audit logging to capture all API requests. Edit the API server manifest to include an audit policy file. Example: `--audit-policy-file=/etc/kubernetes/audit-policy.yaml`. The policy can log all requests to sensitive resources (secrets, configmaps). Send logs to a SIEM (e.g., Splunk, ELK). Use Falco to monitor runtime behavior. For instance, Falco rule: 'Spawned process with shell in container' triggers an alert. Common mistake: not enabling audit logging or not reviewing logs regularly.
Scenario 1: Container Escape via runC Vulnerability
A SOC analyst notices an alert from Falco: 'Unexpected write to /host/bin/runc' from a container. The analyst checks the container image and finds it was pulled from a public registry. The container is running as root with --privileged. The attacker exploited CVE-2019-5736 to overwrite the host runC binary. Correct response: immediately isolate the node (cordon), terminate the container, and patch the host. Common mistake: ignoring the alert thinking it's a false positive.
Scenario 2: Exposed Kubernetes Dashboard An engineer discovers that the Kubernetes dashboard is accessible on the internet without authentication. The dashboard is running with a cluster-admin service account. An attacker could gain full control. Correct response: disable the dashboard or restrict access via network policies and authentication (e.g., OIDC). Common mistake: relying on IP whitelisting only, which can be bypassed if the attacker is on the same network.
Scenario 3: Secrets in Environment Variables
A developer deploys a pod that reads database credentials from environment variables. An attacker who gains access to the pod (e.g., via RCE) can run env and see the secrets. Correct response: mount secrets as volumes or use a secrets manager like Vault. Common mistake: thinking that Kubernetes Secrets are encrypted by default — they are only base64-encoded unless encryption at rest is configured.
SY0-701 Tests Specific Sub-Objectives Under 3.6: - Container security: image scanning, least privilege, immutable infrastructure. - Kubernetes security: role-based access control (RBAC), secrets management, network policies, admission control. - Secure orchestration: pod security standards, service account hardening, etcd encryption.
Most Common Wrong Answers and WHY: 1. 'Use a firewall to block container traffic' — Firewalls operate at the network level, but container traffic within a host may not traverse a firewall. Kubernetes network policies are the correct answer. 2. 'Encrypt all container images' — Images are typically stored in a registry; encryption at rest is for the registry, but the question usually asks about runtime security. Focus on scanning and signing. 3. 'Disable the container runtime' — That would stop all containers. The correct approach is to use runtime security tools like Falco. 4. 'Use a hypervisor for each container' — That defeats the purpose of containers; VMs are heavier. The question expects container-specific controls.
Terms That Appear Verbatim:
- cgroups, namespaces, seccomp, AppArmor, SELinux (Linux security modules).
- PodSecurityPolicy (deprecated but may appear as legacy), PodSecurity Standards (current).
- kube-bench, kube-hunter, Falco, Trivy.
- RBAC, ServiceAccount, ClusterRole, RoleBinding.
- etcd encryption, TLS for API server.
Trick Questions:
- 'What is the best way to secure container images?' The answer is scanning and using minimal base images, not encrypting them.
- 'What is the purpose of a namespace in Kubernetes?' It provides isolation, but the exam may confuse it with Linux namespaces. Kubernetes namespaces are for organizing resources; Linux namespaces isolate processes.
- 'How to prevent a container from accessing the host network?' Use hostNetwork: false (default) and drop NET_RAW capability.
Decision Rule: For scenario questions, identify the primary threat: if it's about image vulnerabilities, pick scanning; if about pod-to-pod traffic, pick network policies; if about user access, pick RBAC; if about runtime attacks, pick Falco or seccomp.
Containers use Linux namespaces for isolation and cgroups for resource limits.
Container escape exploits kernel vulnerabilities; use seccomp, AppArmor, and non-root users to mitigate.
Kubernetes RBAC controls access to API resources; avoid using cluster-admin for applications.
Pod Security Standards (Privileged, Baseline, Restricted) enforce pod security at the namespace level.
Network policies are not enabled by default; they require a CNI plugin that supports them.
Kubernetes Secrets are not encrypted by default; enable encryption at rest for etcd.
Tools: Trivy (image scanning), Falco (runtime security), kube-bench (CIS benchmarks), kube-hunter (pen testing).
Immutable infrastructure: rebuild containers from patched images instead of patching running containers.
These come up on the exam all the time. Here's how to tell them apart.
Virtual Machines (VMs)
Each VM has its own OS kernel (strong isolation)
Slower startup (minutes)
Larger footprint (GBs)
Isolation via hypervisor
Snapshots and live migration easier
Containers
Containers share host kernel (weaker isolation)
Fast startup (seconds)
Small footprint (MBs)
Isolation via namespaces and cgroups
Portable across environments
Mistake
Containers provide the same security isolation as virtual machines.
Correct
Containers share the host kernel, so a kernel vulnerability can lead to container escape. VMs have a hypervisor that provides stronger isolation.
Mistake
Kubernetes Secrets are encrypted by default.
Correct
Secrets are only base64-encoded, not encrypted. Encryption at rest must be enabled in etcd.
Mistake
Running containers as root is safe if the container is not privileged.
Correct
Even without `--privileged`, root inside the container has some capabilities that can be exploited for escape. Always run as non-root.
Mistake
Network policies in Kubernetes are enforced by default.
Correct
By default, all pods can communicate. Network policies must be explicitly created to restrict traffic.
Mistake
Image scanning guarantees a container is secure.
Correct
Scanning only finds known vulnerabilities; zero-days and misconfigurations (e.g., hardcoded secrets) are not detected.
Containers share the host OS kernel and are isolated using namespaces and cgroups, making them lightweight and fast. Virtual machines each have their own OS kernel, running on a hypervisor, providing stronger isolation but with more overhead. For Security+, remember that containers are less isolated than VMs, so additional security controls are needed.
Run containers as non-root, drop all capabilities (--cap-drop=ALL), use a read-only root filesystem, and enable seccomp and AppArmor/SELinux profiles. Also, avoid using --privileged and host mounts. Regularly scan for kernel vulnerabilities and apply patches.
Pod Security Standards (PSS) are predefined policies that control pod security configurations. There are three levels: Privileged (unrestricted), Baseline (minimally restrictive), and Restricted (most secure). They are enforced via admission controllers (e.g., PodSecurity admission). For the exam, know that Restricted disallows privileged containers and requires non-root users.
Enable encryption at rest for etcd, use RBAC to limit access to secrets, mount secrets as volumes instead of environment variables, and consider using external secrets management like HashiCorp Vault. Never hardcode secrets in images or config files.
Network policies control traffic flow between pods and namespaces. They are used to implement micro-segmentation. By default, all pod-to-pod traffic is allowed. A network policy can restrict ingress and egress based on labels, IP blocks, and ports. It requires a CNI plugin that supports network policies (e.g., Calico, Cilium).
Common tools include Trivy (open-source, fast), Clair (CoreOS), Anchore, and Docker Scout. They scan container images for known vulnerabilities (CVEs) in OS packages and application dependencies. For Security+, know that image scanning should be part of the CI/CD pipeline.
A Role grants permissions within a specific namespace. A ClusterRole grants permissions cluster-wide (across all namespaces) or for non-namespaced resources (e.g., nodes). For security, use Roles with namespace-scoped resources and avoid granting ClusterRole to service accounts unless necessary.
You've just covered Container and Kubernetes Security — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?