KCSA Kubernetes Threat Model Practice Test 3 — 15 Questions

Question 1

What is the primary risk associated with running containers as the `root` user (`runAsUser: 0` or omitting the user directive)?

Accepted Answer

If a container escape vulnerability occurs, the attacker immediately obtains root privileges on the underlying host.. Running a container as root (UID 0) means that if an attacker exploits a container escape vulnerability, they gain root privileges on the host node because the container process runs as root in the host's user namespace (unless user namespaces are enabled). This violates the principle of least privilege and significantly increases the blast radius of a compromise. The other options are unrelated to user ID configuration.

Answer

It prevents the kubelet from restarting the container upon failure.

Answer

It disables the container runtime engine's ability to pull images from private registries.

Answer

It forces the CNI plugin to drop network packets destined for external IPs.

Question 2

A security engineer identifies that an enterprise Kubernetes cluster has several cluster-admin bindings granted to user accounts that have left the company. Which Kubernetes security principle has been violated?

Accepted Answer

Principle of Least Privilege and proper identity/access lifecycle management. The presence of cluster-admin bindings for departed users violates the Principle of Least Privilege and proper identity/access lifecycle management. Least Privilege dictates that users should have only the permissions necessary for their role, and lifecycle management ensures access is revoked when users leave. Cluster-admin is the most powerful role and should be tightly controlled and audited.

Answer

NetworkPolicy ingress traffic isolation

Answer

Pod Security Standards baseline enforcement

Answer

Container image vulnerability scanning policies

Question 3

An attacker gains execution in a container and attempts to perform a denial of service attack on other workloads sharing the same Kubernetes node by consuming all available CPU and memory resources. What Kubernetes feature prevents this cross-workload resource exhaustion?

Accepted Answer

Container Resource Requests and Limits (CPU and memory). Container Resource Requests and Limits (CPU and memory) allow you to specify the minimum resources a container needs (requests) and the maximum it can consume (limits). By setting limits, you prevent a single container from monopolizing node resources, thus protecting other workloads from resource exhaustion and denial of service.

Answer

ValidatingWebhookConfiguration rejecting pod creations

Answer

NetworkPolicy egress blocking rules

Answer

ClusterRoleBindings restricting RBAC permissions

Question 4

An auditor is evaluating the security posture of an on-premises Kubernetes cluster. The team notices that the etcd data directory is stored without encryption at rest. What is the primary threat this exposes the cluster to?

Accepted Answer

Direct exposure of all Kubernetes Secrets in plain text to anyone with read access to etcd storage. Without encryption at rest, etcd stores all Kubernetes objects—including Secrets—in plaintext on disk. Anyone with read access to the etcd data directory (e.g., via filesystem access, stolen disk, or backup) can directly read sensitive data like service account tokens, database passwords, and TLS keys. This is the primary threat because etcd is the single source of truth for cluster state, and encryption at rest is a defense-in-depth measure specifically designed to protect this data if the storage medium is compromised.

Answer

Inability of worker nodes to perform TLS handshakes with the API server

Answer

Immediate failure of HorizontalPodAutoscaler metric polling loops

Answer

Automatic elevation of all ServiceAccounts to cluster-admin privileges

Question 5

Which of the following is a key component of the Kubernetes threat model concerning the compromise of node kubelets via insecure configuration?

Accepted Answer

Leaving the Kubelet read-only port (10255) enabled and accessible. The Kubelet read-only port 10255 exposes unauthenticated, unencrypted access to pod and node information (and in some configurations, more). Leaving it enabled and reachable is a well-known Kubernetes threat model item because an attacker on the network can query it to enumerate workloads, extract metadata, and potentially pivot. Hardening guidance (CIS Kubernetes Benchmark) explicitly requires disabling it via --read-only-port=0.

Answer

Enforcing Pod Security Admission in restricted mode

Answer

Using secure HTTPS client certificates for API server communication

Answer

Enabling RBAC authorization mode across the control plane

Question 6

An organization is building a secure software supply chain for Kubernetes. They want to ensure that containers running in the cluster were built from verified source code and passed automated security gates. Which tool combination supports this attestation and verification pipeline?

Accepted Answer

Cosign for cryptographic image signing, SBOM generation, and admission controllers for policy enforcement. Cosign provides cryptographic signing and verification of container images, and can attach SBOMs and attestations (e.g., SLSA provenance) to images in OCI registries. Admission controllers such as Kyverno, OPA Gatekeeper, or Sigstore's policy-controller then enforce at admission time that only images with valid signatures/attestations are admitted to the cluster. Together they form the attestation-and-verification pipeline the question describes.

Answer

HorizontalPodAutoscaler and Metrics Server integration

Answer

kube-proxy for CNI routing and CoreDNS for internal name resolution

Answer

etcd snapshots and kubeadm control plane bootstrapping scripts

Question 7

An attacker compromises a cluster node and attempts to inspect container communication. By default, how is pod-to-pod network traffic handled across different nodes in a standard Kubernetes cluster without a service mesh or CNI encryption enabled?

Accepted Answer

Transmitted in plain text across the network fabric, making it vulnerable to sniffing. In a standard Kubernetes cluster, pod-to-pod traffic across nodes is not encrypted by default. The CNI plugin (e.g., Calico, Flannel, Cilium) is responsible for routing packets between nodes, but unless a feature like WireGuard, IPsec, or a service mesh (e.g., Istio with mTLS) is explicitly enabled, the packets are sent in plain text over the network fabric. This means an attacker who has compromised a node and can sniff network traffic can potentially capture sensitive data exchanged between pods.

Answer

Encrypted automatically using mandatory 256-bit AES transport layer security

Answer

Blocked entirely by default unless a LoadBalancer service is declared

Answer

Routed exclusively through the etcd secure TLS database tunnel

Question 8

An organization is performing a STRIDE-based threat model on their Kubernetes deployment. Which TWO of the following threats map directly to the 'Tampering' category in a Kubernetes environment?

Accepted Answer

An attacker altering container image layers stored in an insecure registry. Option A is correct because Tampering in STRIDE covers unauthorized modification of data, and altering container image layers in an insecure registry is a direct integrity attack on stored artifacts that Kubernetes nodes later pull and run. Option B is correct because modifying Kubernetes API objects—whether at rest in etcd or in transit to the API server using compromised credentials—is unauthorized alteration of cluster configuration and state, which is the canonical Tampering threat in Kubernetes. Option C is not Tampering but Denial of Service, since flooding the API server to exhaust control plane memory targets availability rather than integrity. Option D is Information Disclosure (sniffing unencrypted pod-to-pod traffic), not Tampering, because it involves reading data rather than modifying it. Option E is Repudiation, as it concerns an administrator denying an action due to missing logs, which maps to the non-repudiation property rather than integrity.

Answer

An attacker flooding the API server with requests to exhaust control plane memory

Answer

An attacker sniffing unencrypted pod-to-pod network traffic across the CNI bridge

Answer

An administrator denying that they executed a cluster deletion command due to missing logs

Question 9

What is the security risk of configuring `privileged: true` in a container's SecurityContext?

Accepted Answer

It disables container isolation, granting full access to host devices and kernel capabilities. Setting `privileged: true` in a container's SecurityContext gives the container all Linux capabilities available to the host and disables the default isolation mechanisms (namespaces, cgroups restrictions, seccomp/AppArmor defaults). The container can then access host devices like /dev, mount filesystems, load kernel modules, and effectively act as root on the node. This is why privileged containers are considered a critical security risk in Kubernetes.

Answer

It restricts the container from writing to any attached volume.

Answer

It forces the API server to reject all incoming TLS client requests.

Answer

It prevents the application from reading its own environment variables.

Question 10

An administrator wishes to defend against supply chain attacks involving malicious third-party Kubernetes operators installed from public catalogs. What security practice is most effective before installing such operators?

Accepted Answer

Reviewing requested RBAC permissions, operator manifests, and verifying image provenance. Before installing third-party operators, the most effective practice is to review the requested RBAC permissions, inspect the operator manifests for suspicious resources, and verify image provenance (e.g., signatures, trusted registries). This due diligence helps detect malicious intent, such as excessive privileges or backdoors, before the operator is deployed.

Answer

Enabling Horizontal Pod Autoscaling for CoreDNS replicas

Answer

Disabling the Kubernetes Dashboard service deployment

Answer

Configuring liveness probes on all worker nodes to check kubelet responsiveness

Question 11

Which THREE of the following configurations or features represent critical attack vectors or misconfigurations in a Kubernetes cluster threat model?

Accepted Answer

Mounting the host Docker socket (`/var/run/docker.sock`) into application pods. Option A is correct because mounting /var/run/docker.sock into a pod gives the container direct control over the host's Docker daemon, allowing an attacker to create privileged containers, mount host filesystems, or escape to the node. Option B is correct because the Kubelet read-only port 10255 serves unauthenticated and unencrypted API data, exposing pod specs, environment variables, and cluster details to anyone who can reach the node. Option D is correct because securityContext.privileged: true disables container isolation, granting all Linux capabilities and host device access, which makes node compromise and container escape trivial. Option C is not a vector because Pod Security Admission in restricted mode is a hardening control that enforces least-privilege pod settings. Option E is not a vector because etcd encryption at rest with a Secret encryption provider protects sensitive data in etcd rather than exposing it.

Answer

Enabling Pod Security Admission in restricted mode across all namespaces

Answer

Configuring etcd encryption at rest with a Secret encryption provider

Question 12

Which THREE of the following mechanisms are essential for securing the Kubernetes control plane against unauthorized access and privilege escalation?

Accepted Answer

Enforcing robust Role-Based Access Control (RBAC) with least privilege principles. Option A is correct because robust RBAC with least-privilege principles ensures that users, service accounts, and controllers only receive the exact permissions they need, preventing unauthorized access and privilege escalation within the cluster. Option B is correct because requiring mutual TLS (mTLS) for all internal API server and component communications authenticates both ends of every connection, protecting against man-in-the-middle attacks, spoofing, and unauthorized components joining the control plane. Option D is correct because enabling encryption at rest for sensitive data stored in etcd protects secrets, tokens, and configuration from being read directly from the backing datastore if it is compromised. Option C is incorrect because mutable `:latest` image tags make deployments non-deterministic and can silently pull vulnerable or malicious images, weakening rather than strengthening control plane security. Option E is incorrect because setting `allowPrivilegeEscalation: true` explicitly permits containers to gain more privileges than their parent process, which directly enables privilege escalation and should be set to false.

Answer

Using mutable `:latest` image tags for all control plane system components

Answer

Setting `allowPrivilegeEscalation: true` across all default container security contexts

Question 13

An auditor evaluates network security controls in a Kubernetes cluster. Which TWO configurations help mitigate lateral movement and network-based attacks between pods?

Accepted Answer

Implementing a service mesh (such as Istio or Linkerd) with strict mTLS enforcement. Option B is correct because a service mesh such as Istio or Linkerd with strict mTLS enforcement authenticates and encrypts all service-to-service traffic, so a compromised pod cannot impersonate another workload or sniff plaintext traffic, directly limiting lateral movement. Option E is correct because Kubernetes NetworkPolicies implement pod-level, label-selector-based ingress and egress filtering enforced by the CNI, allowing only explicitly permitted pod-to-pod flows and blocking unauthorized east-west connections. Option A is wrong because disabling CNI plugins and using plain bridge mode removes policy enforcement and segmentation, increasing exposure rather than mitigating it. Option C is wrong because NodePort services expose internal microservices on every worker node's IP and port range, widening the attack surface instead of containing it. Option D is wrong because hostNetwork: true places pods in the node's network namespace, letting them see node traffic and bypass pod network isolation, which enables rather than prevents lateral movement.

Answer

Disabling CNI network plugins to run pods in bridge mode

Answer

Exposing all internal microservices via NodePort services on worker nodes

Answer

Mounting the host network namespace (`hostNetwork: true`) on all application pods

Question 14

Which THREE of the following capabilities or runtime configurations pose extreme risks of container escape when granted to an untrusted workload?

Accepted Answer

`hostPID: true` sharing the host process namespace. Option A (`hostPID: true`) is correct because sharing the host PID namespace lets the container see and signal host processes, enabling attacks such as ptrace-based injection into host daemons or killing host security agents, which is a classic container-escape vector. Option C (`securityContext.privileged: true`) is correct because a privileged container disables most isolation: it gets all Linux capabilities, access to all host devices, and relaxed seccomp/AppArmor confinement, so it can mount the host filesystem or load kernel modules to break out. Option D (granting `CAP_SYS_ADMIN`) is correct because this capability permits mount operations, namespace manipulation, and other kernel-level actions that allow escaping the container boundary even without full privileged mode. Option B (`automountServiceAccountToken: false`) is not a risk — it reduces exposure by preventing the pod from receiving a Kubernetes API token. Option E (`readOnlyRootFilesystem: true`) is a hardening measure that makes the container's root filesystem immutable and does not enable escape.

Answer

Setting `automountServiceAccountToken: false` on the service account

Answer

Setting `readOnlyRootFilesystem: true` in the container specification

Question 15

Which THREE of the following supply chain vulnerabilities or risks can impact Kubernetes application deployments during the build or deployment phase?

Accepted Answer

Using outdated container base images containing known remote code execution CVEs. Option B is correct because outdated base images carry known RCE CVEs that are inherited by every image built FROM them, so the vulnerability is baked into the artifact during the build phase and shipped to the cluster at deployment. Option C is correct because typosquatting attacks publish malicious packages with names resembling legitimate ones on npm/PyPI, so a mistyped dependency in a Dockerfile or build script executes attacker code during image build. Option D is correct because third-party Helm charts can embed backdoored templates (e.g., privileged pods, hostPath mounts, or extra initContainers) that are rendered and applied at deployment time, compromising the workload. Option A is not a vulnerability but a hardening control that restricts pod privileges, and Option E is a detection/auditing control using webhook sinks, so neither introduces a build- or deployment-phase supply chain risk.

Answer

Enforcing Pod Security Standards in baseline mode in production namespaces

Answer

Enabling Kubernetes audit logging with webhook sinks