The Kubernetes and Cloud Native Security Associate (KCSA) (KCSA)

The PodSecurity admission controller enforces Pod Security Standards (Baseline, Restricted, Privileged) based on namespace labels .

If a tenant has full CRUD on the namespace object, they can modify the namespace labels to remove or weaken the restriction (e.g., setting pod-security.kubernetes.io/enforce=privileged).

This allows privileged Pods to be admitted despite the security policy.

Incorrect options:

(A) is false — namespace-level access allows tampering.

(C) is invalid — PodSecurity admission is not namespace-deployed, it’s a cluster-wide admission controller.

(D) is unrelated — Secrets from other namespaces wouldn’t directly bypass PodSecurity enforcement.

Setting privileged: true grants a container elevated access to the host node , including access to host devices, kernel capabilities, and the ability to modify the host.

However, Secrets in Kubernetes are not automatically exposed to privileged containers. Secrets are mounted into Pods only if explicitly referenced.

Thus, being privileged does not grant additional access to Kubernetes Secrets compared to a non-privileged Pod.

The risk lies in node compromise: if a privileged container can take over the node, it could then indirectly gain access to Secrets (e.g., by reading kubelet credentials).

The 4C’s of Cloud Native Security (Cloud, Cluster, Container, Code) model starts with Cloud as the base layer.

If the Cloud (infrastructure layer) is compromised, every higher layer (Cluster, Container, Code) inherits that compromise.

Exact extract (Kubernetes Security Overview):

“ The 4C’s of Cloud Native security are Cloud, Clusters, Containers, and Code. You can think of the 4C’s as a layered approach. A Kubernetes cluster can only be as secure as the cloud infrastructure it is deployed on. ”

This means the cloud is part of the trusted computing base of a Kubernetes cluster.

The Node authorization mode is designed to specifically limit what kubelets can do when they connect to the Kubernetes API server.

It authorizes requests from kubelets based on the Pods scheduled to run on their nodes, ensuring kubelets cannot interact with resources beyond their scope.

Incorrect options:

(B) AlwaysAllow allows unrestricted access (insecure).

(C) No kubelet authorization mode exists.

(D) Webhook mode delegates authorization decisions to an external service, not specifically for kubelets.

In STRIDE, Tampering is the threat category for unauthorized modification of data or code/artifacts . A trojanized container image is, by definition, an attacker’s modification of the build output (the image) after compromising the CI/build system—i.e., tampering with the artifact in the software supply chain.

Why not the others?

Spoofing is about identity/authentication (e.g., pretending to be someone/something).

Repudiation is about denying having performed an action without sufficient audit evidence.

Denial of Service targets availability (exhausting resources or making a service unavailable). The scenario explicitly focuses on an altered image resulting from a compromised build server—this squarely maps to Tampering .

Authoritative references (for verification and deeper reading):

Kubernetes (official docs) – Supply Chain Security (discusses risks such as compromised CI/CD pipelines leading to modified/poisoned images and emphasizes verifying image integrity/signatures).

Kubernetes Docs ➜ Security ➜ Supply chain security and Securing a cluster (sections on image provenance, signing, and verifying artifacts).

CNCF TAG Security – Cloud Native Security Whitepaper (v2) – Threat modeling in cloud-native and software supply chain risks; describes attackers modifying build outputs (images/artifacts) via CI/CD compromise as a form of tampering and prescribes controls (signing, provenance, policy).

CNCF TAG Security – Software Supply Chain Security Best Practices – Explicitly covers CI/CD compromise leading to maliciously modified images and recommends SLSA, provenance attestation, and signature verification (policy enforcement via admission controls).

Microsoft STRIDE (canonical reference) – Defines Tampering as modifying data or code , which directly fits a trojanized image produced by a compromised build system.

Kubernetes supports workload-specific runtimes via RuntimeClass .

A mutating admission controller can enforce this automatically by:

Intercepting workload creation requests.

Modifying the Pod spec to set runtimeClassName based on labels or policies.

Incorrect options:

(A) Manual modification is not scalable or secure.

(B) kube-apiserver cannot enforce per-application runtime policies.

(C) A validating webhook can only reject , not modify, the runtime.

PCI DSS (Payment Card Industry Data Security Standard): applies to any entity that stores, processes, or transmits cardholder data .

Exact extract (PCI DSS official summary):

“ PCI DSS applies to all entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). ”

Therefore, merchants who process credit card payments must comply.

Why others are wrong:

A: No card payments, so no PCI scope.

B: This falls under FISMA / NIST 800-53 , not PCI DSS.

C: Non-profits may handle sensitive data, but PCI only applies if they process credit cards .

RBAC in Kubernetes is coarse-grained: it controls verbs (get, update, patch, delete) on resources (e.g., deployments), but not individual fields within a resource.

There is no /image subresource for deployments (there is one for pods but only for ephemeral containers).

Therefore, RBAC cannot restrict changes only to the image field .

Admission Webhooks (mutating/validating) can enforce fine-grained policies (e.g., deny updates that change anything other than spec.containers[*].image).

Exact extract (Kubernetes Docs – Admission Webhooks):

“ Admission webhooks can be used to enforce custom policies on objects being admitted. ”

Kubernetes RBAC uses RoleBinding to grant permissions defined in a Role to a subject (user, group, or service account) within a namespace. The official example shows binding user jane to Role pod-reader:

“A RoleBinding grants the permissions defined in a Role to a user or set of users….”

Example:

subjects:

- kind: User

name: jane

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: Role

name: pod-reader

apiGroup: rbac.authorization.k8s.io

— Kubernetes docs, RBAC: RoleBinding and ClusterRoleBinding

Option B matches this pattern exactly, with name: bob as the User subject and roleRef pointing to the Role named pod-reader.

A swaps the names (subject is pod-reader, role is bob) → incorrect.

C references a ClusterRole , not a Role (the question asks for Role).

D uses kind: Group even though we need the User bob.