Which THREE of the following are required to implement a secure software supply chain using Kubernetes native features?
Trap 1: Disable admission controllers to reduce latency in pod creation.
Admission controllers are a mandatory phase of the Kubernetes API request lifecycle that intercept requests to the API server after authentication and authorization but before object persistence. Disabling them, for example by removing the corresponding plugins from the API server's --enable-admission-plugins flag, would bypass built-in security controls such as PodSecurity admission, LimitRanger, ResourceQuota, and custom validating or mutating webhooks. These plugins enforce crucial restrictions like disallowing privileged containers, requiring security contexts, and validating resource usage; eliminating them to reduce latency would leave the cluster exposed to misconfigured or malicious pods, while providing negligible performance benefit because the checks are simple in-memory evaluations.
Trap 2: Run all containers as root inside the pod to avoid permission…
Running all containers as root is a direct violation of the principle of least privilege and dramatically increases the impact of a container compromise. Even within a container, the root user shares the same kernel user ID (UID 0) as the host's root, and if the container is able to exploit a kernel vulnerability, a container breakout could grant root access to the host node. Kubernetes provides securityContext fields like runAsNonRoot, runAsUser, and allowPrivilegeEscalation to force workloads to run with unprivileged UIDs and drop dangerous capabilities; forcing root defeats these protections and makes the entire cluster highly fragile.
- A
Use vulnerability scanning tools like Trivy or Grype in the CI/CD pipeline.
Running vulnerability scanners such as Trivy or Grype inside the CI/CD pipeline integrates security analysis directly into the build and release lifecycle. These tools compare the image's installed packages and application dependencies against public and private CVE databases, and can be configured to fail the pipeline when critical or high-severity vulnerabilities are present. This prevents container images with known, exploitable weaknesses from ever reaching a registry or being deployed, enforcing a shift-left security model that catches issues before runtime rather than after an attack.
- B
Disable admission controllers to reduce latency in pod creation.
Why it fails: Admission controllers are a mandatory phase of the Kubernetes API request lifecycle that intercept requests to the API server after authentication and authorization but before object persistence. Disabling them, for example by removing the corresponding plugins from the API server's --enable-admission-plugins flag, would bypass built-in security controls such as PodSecurity admission, LimitRanger, ResourceQuota, and custom validating or mutating webhooks. These plugins enforce crucial restrictions like disallowing privileged containers, requiring security contexts, and validating resource usage; eliminating them to reduce latency would leave the cluster exposed to misconfigured or malicious pods, while providing negligible performance benefit because the checks are simple in-memory evaluations.
- C
Integrate image signature verification into the admission webhook (e.g., using cosign and Kyverno).
Integrating image signature verification into an admission webhook using tools like cosign and Kyverno adds a cryptographic trust check directly at the moment a Pod is created or updated. When an image is pushed, a signature is generated using a private key, typically within a Sigstore-based workflow; at admission time, the webhook verifies that the image's signature matches a trusted public key, proving the image was signed by an authorized party and has not been tampered with since signing. This is distinct from simply scanning for vulnerabilities, because it authenticates the provenance and integrity of the artifact itself, preventing an attacker from substituting a malicious but equally vulnerable image under the same name from a compromised or untrusted source.
- D
Run all containers as root inside the pod to avoid permission issues.
Why it fails: Running all containers as root is a direct violation of the principle of least privilege and dramatically increases the impact of a container compromise. Even within a container, the root user shares the same kernel user ID (UID 0) as the host's root, and if the container is able to exploit a kernel vulnerability, a container breakout could grant root access to the host node. Kubernetes provides securityContext fields like runAsNonRoot, runAsUser, and allowPrivilegeEscalation to force workloads to run with unprivileged UIDs and drop dangerous capabilities; forcing root defeats these protections and makes the entire cluster highly fragile.
- E
Enforce policies using OPA Gatekeeper or Kyverno to restrict allowed registries and image constraints.
Enforcing policies with OPA Gatekeeper or Kyverno allows cluster administrators to define and automatically enforce image-related constraints as code, such as allowing images only from approved registries, requiring images to have immutable digest references, or blocking tags like 'latest' that introduce non-reproducible deployments. These tools act as validating or mutating admission webhooks that evaluate each Pod spec against policy rules derived from Kubernetes objects like ConstraintTemplates and ClusterPolicies, rejecting non-compliant requests before they are persisted. This provides centralized, audit-friendly governance that ensures development teams cannot accidentally or intentionally use untrusted image sources, even if such images have passed the CI/CD pipeline.