CCNA Cks Supply Chain Questions

Pod Security Admission with the 'restricted' profile is a native Kubernetes admission controller that enforces the most stringent Pod Security Standard. It requires each container to set `securityContext.runAsNonRoot: true`, and it also fails pods if the image is configured to run as UID 0 unless an explicit non-root user is set. Because it is built into the kube-apiserver, it requires no extra components and can be enforced per-namespace via labels, making it a reliable and straightforward approach to prevent root execution.

Changing the image to alpine@sha256:... provides a content-addressable reference that uniquely pins the image manifest to its cryptographic digest. This mutability is eliminated: even if the original tag is moved, the deployment will always pull the exact verified image, and this format precisely satisfies the immutable-reference policy.

A validate rule that checks the image registry is the correct enforcement mechanism in Kyverno. Such a rule can use a pattern, a deny condition, or CEL expression to inspect the image field and reject any container whose registry is not in an allowed list. When the rule evaluates to deny, Kubernetes admission control fails, and the pod or workload is not created. This directly matches the requirement to enforce that all images come from approved registries.

Kyverno acts as a validating admission controller that evaluates the pod manifest against the configured policy. If a rule is violated, the API server receives a denial response and reports an admission error to the client, preventing the pod from being created. The request is rejected pre-persist, so the pod never runs.

Using a Kyverno validate rule with a deny condition allows you to enforce policy by rejecting any Pod that does not meet the specified criteria, such as pulling images from unauthorized registries. The deny condition is evaluated against the resource; if the condition is true, admission is blocked with a clear message. This is the canonical way to express negative constraints in Kyverno, as it directly validates the existing image field without altering it.

cosign is part of the Sigstore project and natively supports signing container images and verifying those signatures, including keyless signing via Fulcio and transparency logs (Rekor). It stores signatures as separate OCI artifacts, typically tagged like 'sha256-<digest>.sig', and can enforce that only verified images are admitted. Because it directly addresses the requirement to ensure images are signed, it is the only correct choice here.

Trivy is a container security scanner that also generates SBOMs in multiple formats, including CycloneDX and SPDX. Using subcommands like `trivy image --format cyclonedx` or `trivy sbom`, it extracts package information from the image's layers and package databases (e.g., dpkg, RPM, and ERS). This dual functionality makes Trivy a go-to tool for both vulnerability scanning and SBOM production.

Syft is an SBOM generation tool that inspects container image layers and outputs a package inventory in SPDX or CycloneDX formats. It directly satisfies the supply chain audit requirement to produce a Software Bill of Materials, unlike scanners such as Trivy or Grype, which report vulnerabilities rather than catalogue components.

cosign sign is the exact command that generates a digital signature for a container image, producing a signature payload stored in an OCI registry (typically as an image tag suffixed with `-sig`). It signs the image digest using a key pair, and the resulting signature can later be verified with `cosign verify`. This command is the core mechanism for asserting the identity of the signer and ensuring the image's content has not been tampered with.

Trivy is a versatile security scanner that can also generate SBOMs through its built-in subcommands such as `trivy image --format cyclonedx` and `trivy fs --format spdx`. It enumerates installed packages and libraries from image layers and filesystems using multiple package managers and language ecosystems, then serializes the discovered components into an SBOM document. While Trivy is commonly known for vulnerability scanning, its ability to produce SBOMs in standard formats makes it a correct answer for this question.

Trivy's trivy fs command scans a filesystem directory, such as a Docker build context, for known vulnerabilities by inspecting OS package manager files and language-specific lock files. It matches installed versions against comprehensive vulnerability databases (e.g., NVD, GHSA) and produces a report without requiring a built image. This makes it ideal for shifting security left in CI/CD pipelines, catching vulnerable dependencies before they are baked into a container image.

Scanning every container image for known vulnerabilities before deployment is essential because it maps the image's package and dependency versions against public CVE databases such as NVD and identifies exploitable flaws before they reach runtime. This proactive step lets you choose a patched base image, add remediation layers, or reject the image entirely, thereby minimizing the attack surface. Automated scanners like Trivy, Clair, or Grype inserted into the CI/CD pipeline provide continuous assurance and make security part of the deployment workflow rather than an afterthought.

Distroless images ship only the application and its runtime dependencies, omitting package managers, shells and utilities. This directly shrinks the attack surface by removing binaries an attacker could exploit after gaining a foothold, satisfying the stem's requirement for minimal container images.

Scanning container images for known vulnerabilities with tools like Trivy, Clair, or Grype is a critical proactive security control. It identifies CVEs in base images and application dependencies before deployment, allowing teams to patch or choose alternative images. Integrating scanning into a CI/CD pipeline ensures that only trusted images reach the cluster, reducing the risk of exploiting known weaknesses.

Pinning images to content-addressable digests (e.g., sha256:...) makes the container runtime pull the exact manifest that was vetted at admission time, because tags are mutable references that can be overwritten in a registry. A tag like :latest may be shifted to a compromised build, whereas a digest is a hash of the image manifest, and any change to the image content alters that hash. This prevents tag-based mutation, typo-squatting, and stale cached pulls, and it is the foundation for verifying image signatures and provenance attestations.

Scanning images in the pipeline catches known CVEs in base layers and dependencies before deployment, satisfying the stem's requirement to secure the build stage. This shifts vulnerability detection left, so flawed artefacts never reach the registry or cluster.

`trivy image <image-name>` targets the container image artefact directly, pulling and unpacking its layers to inspect OS packages and language dependencies for known CVEs. This satisfies the stem's requirement to scan an image, unlike filesystem or repository scans, which analyse different targets.

This is the correct command because it targets the container image (`trivy image`), restricts results to only critical-severity vulnerabilities with `--severity CRITICAL`, and outputs machine-readable JSON via `--output json`. The JSON format is ideally suited for CI/CD automation, allowing the pipeline to parse vulnerability data programmatically (e.g., with jq) and enforce policy based on exact vulnerability IDs. It directly matches the requirement to scan the built image and flag critical issues.

The ImagePolicyWebhook admission controller allows an external webhook to make admission decisions based on image policies. By implementing a webhook that uses cosign verify to check signatures, the cluster can enforce that only signed images are admitted. This is a valid and flexible approach, though it requires deploying and maintaining the webhook service.

The constraint is built with a regex pattern (or a glob converted to regex) that defines exactly which image registry paths are allowed, and Gatekeeper uses this pattern to match against the full image reference. If the image reference omits a required path segment, uses a different registry host, or otherwise fails to satisfy the regex anchors, the constraint fails and blocks the image. So the denial happens because the image string does not match the precise pattern that the constraint's `allowedPattern` (or similar field) enforces.

Notary is an open-source project that implements The Update Framework (TUF), providing a secure mechanism for publishing and verifying signed collections of content, including container images. It uses signed metadata files that list the cryptographic digests of image manifests and layers, enabling clients to confirm that the image came from the expected publisher and has not been altered. This makes Notary a valid, standards-based approach to image integrity and authenticity verification.

Distroless images ship only the application and its runtime dependencies, omitting package managers, shells and utilities. This shrinks the attack surface and removes tooling attackers commonly abuse after exploiting a container, strengthening supply chain security.

cosign verify validates a container image's signature against the specified public key or keyless identity, confirming the image was signed by a trusted party and has not been tampered with. This is the standard Sigstore command for signature verification in supply-chain security workflows.

This admission controller intercepts Pod creation requests and sends the image reference to an external webhook endpoint that performs signature verification (e.g., using sigstore/cosign) before returning an admission response. If the webhook rejects the image as unsigned, the API server refuses to admit the Pod, enforcing the policy cluster-wide at admission time. Because the check happens automatically during the API request lifecycle, it cannot be skipped by operators or developers.

Scanning after the image is built but before it is pushed to the registry is the earliest and most effective security gate because the image has been fully assembled into its final layered form. This stage lets you catch vulnerabilities in the base OS packages, application dependencies, and any added binaries before the image is stored in a trusted registry and made available for deployment. By blocking the push of non-compliant images, you keep vulnerable artifacts out of the supply chain entirely, ensuring that only vetted images reach Kubernetes clusters or runtime environments.

The --format table flag explicitly selects the default human-readable output format for Trivy. It prints a tabular view with columns such as Library, Vulnerability, Severity, and Installed Version, making it ideal for terminal inspection but unsuitable for automated parsing. Using this flag is redundant if no format is specified, but it is valid and often used for clarity in scripts.

ENV is the correct answer because it explicitly bakes environment variables into the image layer, and any secret placed there becomes visible in `docker history`, `docker inspect`, and persists for all containers started from that image. Hardcoded secrets in ENV are a classic anti-pattern because they are exposed to anyone who can pull the image, contrary to using BuildKit's `RUN --mount=type=secret` or secret-build hooks to keep credentials out of the final image.

Rebuilding the image from a patched base image directly eliminates the vulnerable package from the image filesystem, ensuring that the vulnerability is no longer present in the artifact itself. Integrating vulnerability scanning into the CI pipeline shifts security left, allowing teams to detect and block vulnerable images before they are pushed to a registry or deployed. This approach is sustainable and reproducible, as every build is validated and known vulnerabilities trigger a pipeline failure, forcing developers to update dependencies promptly. It addresses the source of the issue rather than applying after-the-fact controls.

This is correct because it creates a non-root user (myuser) without a password (using the -D flag for Alpine Linux) and then switches the active user to that account. All subsequent RUN, CMD, and ENTRYPOINT instructions execute as myuser, limiting the container to the least privileges needed for the application. This follows the security best practice of avoiding root inside containers, reducing the risk of privilege escalation if the application is compromised.

A validate rule is the correct Kyverno mechanism because it asserts that the incoming resource matches a required pattern and rejects it otherwise. The pattern `spec.containers[*].image: "*@sha256:*"` enforces that every container image reference includes the immutable digest identifier, since a valid digest always appears as the `@sha256:` suffix. This directly implements the security policy at admission time, ensuring only images with explicit digests are deployed.

Trivy's detection depends on its local vulnerability database. If that database is stale, newly published CVEs affecting the image's packages are absent from results, while a tool with a current feed flags them. Updating the database resolves the discrepancy.

A MutatingAdmissionWebhook can modify the Pod spec before it is persisted, so even a simple nginx image could end up with an altered command, injected sidecar, or changed entrypoint. Once admitted, kubelet runs the mutated container, and if the mutation causes the main process to exit (e.g., a sidecar and no nginx, or an invalid argument), the resulting restart loop appears as CrashLoopBackOff. This explains why a mutation, not an outright rejection, matches the symptom.

Distroless images are purpose-built to contain only the libraries, system files, and configuration needed to run a specific runtime (such as glibc, CA certificates, and timezone data), with no shell, package manager, or debugging tools. This strips out utilities an attacker could leverage and keeps the filesystem small, while still supporting dynamically linked applications — unlike scratch, which requires you to provide every dependency yourself.

Kubesec is a static analysis tool that directly inspects Kubernetes resource manifests (YAML/JSON) without requiring a live cluster. It applies security best-practice rules—such as disallowing privileged containers, ensuring runAsNonRoot is set, and checking for dangerous capabilities—and produces a weighted risk score from 0 to 10. This validates exactly the kind of declarative security posture that the question asks about.

When the webhook cannot be reached, the API server rejects the request. Setting failurePolicy: Ignore allows pods to be admitted even if the webhook is unavailable, but this is a temporary fix. The root cause might be network connectivity to the webhook service.

Control-plane nodes in kubeadm clusters carry the taint `node-role.kubernetes.io/control-plane:NoSchedule`, so a pod must include a matching toleration such as `tolerations: - key: node-role.kubernetes.io/control-plane, operator: Exists, effect: NoSchedule` before the scheduler will consider that node. Adding this toleration to the pod's YAML makes it explicitly accept the taint, allowing the pod to be placed on the control-plane node. This is the targeted, least-invasive solution because it only affects the workload that needs to run there, without altering node-level security settings.

A validate policy with failureAction: enforce configures Kyverno to actively reject any resource that does not match the required pattern. When the validation rule fails, the admission webhook returns a denial to the API server, preventing the resource from being created or updated. This is the correct way to make a 'require' policy block non-compliant resources.

Switching to a distroless base image (e.g., gcr.io/distroless) removes package managers, shells, and unused utilities, leaving only the minimal OS libraries required to run the application, which dramatically reduces the number of installable components where CVEs can live. Pinning the image by SHA-256 digest instead of a mutable tag ensures that the exact same immutable image is used every time, preventing a future 'latest' tag update from silently introducing known vulnerabilities or malicious code.

Correct: In Kyverno's wildcard matching, this pattern requires an image reference that has '@sha256:' followed by any sequence of characters. That means the immutable part of the reference is a SHA256 digest with the standard 'algorithm:digest' format; the leading '*' accounts for the registry/repository/name, and the trailing '*' consumes the 64-character hex digest. This precisely ensures images are pinned to a SHA256 digest and not to a mutable tag.

Scanning the built image against known vulnerability databases detects outdated packages and CVEs before the image reaches a registry or runtime. This catches known flaws at the earliest pipeline stage, whereas signing, linting or runtime monitoring do not identify known vulnerabilities in image contents.

The trivy image subcommand targets a container image reference directly, pulling and scanning its layers against vulnerability databases to report CVEs. Other Trivy subcommands scan filesystems, repositories, or configuration files, so only this form satisfies the image-scanning requirement.

Cosign image signing, backed by Sigstore, creates a cryptographic signature bound to the image digest and the signer's identity (such as an OIDC email). Verifying that signature before deployment confirms both that the image content is unmodified and that it came from an approved publisher, making it a true provenance and tamper-evidence check. Without this step, an attacker who compromises a registry can swap a signed-looking tag for a malicious image and the cluster would have no way to detect the substitution.

MutatingAdmissionWebhook is a built-in admission controller that intercepts API requests after authentication and authorisation, invoking external webhooks to modify objects before persistence. It satisfies the stem's requirement for a valid admission controller, operating in the mutating phase alongside validating webhooks. Kubernetes enables it by default in the recommended admission plugin set.

Cosigned's admission webhook evaluates both the image reference and the signature's identity. Because the keyless certificate presented for this image has an issuer or subject that does not appear in the policy's `identities` array, the admission request is denied. This is the expected behavior when identity matching is enforced, so the pod cannot be admitted.

Switching to a distroless base image removes unnecessary components like shells, package managers, and other utilities, leaving only the runtime dependencies required to run the application. This significantly reduces the number of installed packages that could contain known vulnerabilities, directly shrinking the attack surface and the scanner's vulnerability count. Distroless images are an established best practice for minimizing software footprint, making this the correct remediation.

The kubesec CLI returns a score of -1 when it cannot complete a scan, typically because the input is invalid YAML, the file cannot be read, or the manifest is missing required fields. This is explicitly defined as a scan failure, not a security score. In practice, you should verify the deployment YAML with a YAML linter or run kubesec with verbose output to see the underlying parse error before concluding anything about the security posture.

Piping the manifest via cat to kubesec scan with /dev/stdin works because kubesec accepts a file path argument, and /dev/stdin is a valid readable path on Linux. This satisfies the requirement to supply the manifest through standard input rather than a named file.

Each Dockerfile instruction creates a layer, so combining related commands with && and cleaning caches in the same RUN reduces layer count. Fewer layers shrink the final image and reduce the attack surface, satisfying the best-practise goal of lean, minimal container images.

ImagePolicyWebhook is a dedicated Kubernetes admission controller that intercepts Pod creation and update requests, extracts the image references, and sends them to an external HTTP(S) backend for a decision based on scanning or policy rules. It is designed specifically for image policy enforcement, with configuration for fail-open/fail-closed behavior and support for default image policies like allowed registries or prefixes. This makes it the standard mechanism to reject images that fail security scanning before they are scheduled.

Kyverno is a Kubernetes-native policy engine running as an admission controller that can validate, mutate, and generate resources. It can define a ClusterPolicy requiring runAsNonRoot: true on every pod, and can even automatically mutate pods to set a non-root security context. Kyverno uses validating and mutating webhooks to intercept pod creation, making it a robust and current tool for guaranteeing container images run as non-root across the cluster.

An SBOM enumerates every direct and transitive dependency along with its version range, enabling deterministic cross-checks against vulnerability intelligence feeds such as CVE records, OSV entries, or vendor security advisories. This turns an opaque binary artifact into a structured inventory that tools can map to known flaws, so remediation prioritization and impact analysis become reproducible rather than based on guesswork.

`imageRegistry` is a dedicated field inside a Kyverno `validate` rule that defines a list of allowed image registries (e.g., `registry.mycompany.com/*`). When a target resource like a Pod is created or updated, Kyverno evaluates all container image references against this allowlist and denies admission if any image comes from a registry outside the list. This is the correct and direct way to enforce image registry validation, making it the answer for this question.

Trivy scans container images for OS package and language dependency vulnerabilities, integrating cleanly into CI pipelines as a CLI step that fails builds on high-severity CVEs. It satisfies the automated scanning requirement without needing a running cluster or registry-side agent, unlike runtime-focused alternatives.

Comparing the image SHA digest against a known-good digest is a direct integrity check because the digest is a cryptographic hash of the image manifest and content. If the computed digest matches the trusted reference, the image is byte-for-byte identical to the verified original; any modification would produce a different digest. This is considered a reliable and tamper-evident method, provided the known-good digest comes from a trusted source and is transmitted over a secure channel.

A minimal base image such as Alpine dramatically reduces the attack surface because it contains only the essential binaries and libraries needed to run the application. With fewer packages, there are fewer known CVEs to patch, and the smaller footprint also limits the potential impact of a compromised dependency. Distroless images take this further by removing package managers and shells, but Alpine is a practical middle ground that keeps the image size small and the tooling familiar.

Kyverno is a purpose-built policy engine that functions as a dynamic admission controller in the API request path. Its verifyImages rule integrates with Sigstore/cosign to check an image's cryptographic signature against configured public keys or Keyless authorities, and it can reject or patch any Pod that uses an unsigned or improperly signed image. Kyverno's rule can be scoped to namespaces and supports both failure modes, making it the appropriate tool to enforce this requirement.

The `cosign verify` command retrieves the image's signature artifacts from the registry and cryptographically verifies them against the specified public key. It recomputes the image digest from the manifest and checks that the signed payload matches, ensuring the image has not been modified. A successful exit status indicates the signature is valid and trusted, confirming the image was signed by the holder of the corresponding private key. This is the appropriate command for an administrator to verify provenance before deployment.

Kyverno with a verifyImages rule is correct because Kyverno runs as a dynamic admission controller inside the cluster and intercepts Pod creation requests before they are persisted. The verifyImages rule leverages cosign to check each container image's digital signature against the specified public keys, failing admission if the signature is missing or invalid. This enforces a policy that only signed images from trusted registries can run, at the exact point Kubernetes decides to allow the workload.

Syft scans container image layers and filesystem contents to produce an SBOM listing installed packages and their versions, satisfying the requirement to catalogue image components. Unlike general vulnerability scanners, its purpose is SBOM generation itself, outputting SPDX or CycloneDX formats directly from image references.

Updating the image tag in each Deployment's PodTemplateSpec is the correct declarative approach: it triggers a rolling replacement of the underlying ReplicaSets, so old pods are terminated only after new ones become Ready. During pod creation, the cluster's validating/mutating admission controller (e.g., Kyverno or OPA via cosign) checks the image's cryptographic signature and attestations; if the patched image is signed and passes policy, the update proceeds. This ensures every pod runs a verified, patched image with zero downtime.

Rebuilding the image with a minimal base image such as distroless or a slim alpine variant is the correct remediation because these bases contain only the runtime dependencies needed for the application, eliminating the package manager, shell, and other tools that often carry CVEs. By reducing the number of installed packages, the attack surface is significantly minimized, and many reported vulnerabilities are directly removed from the image. This approach addresses the root cause of the vulnerabilities rather than masking them, and aligns with the security principle of least privilege applied to container images.

Admission webhooks can be scoped using namespaceSelector or objectSelector. If the namespaces where unsigned pods are deployed are excluded, the webhook will not be invoked for those pods. This would allow unsigned images to be admitted without verification. This is a common misconfiguration that can silently bypass enforcement.

ImagePolicyWebhook is a built-in Kubernetes admission controller that forwards pod creation requests to an external HTTPS endpoint for image policy evaluation. That webhook can verify signatures against a trusted key, rejecting unsigned images before they are admitted to the cluster.

Cosign stores the signature for an image in a separate tag derived from the image digest (e.g., `sha256-<digest>.sig`) and does not use mutable tags like `latest` for signature lookup. When a CI pipeline overwrites a tag with a newly built image, the new image digest does not yet have a corresponding signature tag, so `cosign verify` finds no signatures for that digest. The old signature is still present but only applies to the previous digest, so verification fails with a "missing signature" error until the new image is explicitly signed after the push.

Cosign's sign subcommand with --key uses the supplied private key to create a signature, then uploads it to the same OCI registry as the image, attaching it as a referrer artefact. This satisfies the requirement to store the signature in the registry itself.

ImagePolicyWebhook is the correct choice because it is a specialized admission controller that delegates image policy decisions to an external webhook service. The kubelet sends the image name, pull spec, and associated metadata to the configured webhook, which can then validate cryptographic signatures or enforce a deny-list/allow-list before the image is used. This design is the native Kubernetes mechanism for ensuring that only signed or pre-approved images enter the cluster, and it operates at the point of image resolution rather than at pod creation.

This command uses Cosign to verify the signature of the specified image against the provided public key. It checks that the image was signed with the corresponding private key and that the signature is valid, ensuring integrity and authenticity. This is the correct approach for verifying a Cosign signature when the public key is available.

Alpine's musl libc and BusyBox base provide a far smaller package set than Debian or Ubuntu images, removing compilers, shells and unused daemons. Fewer installed packages mean fewer exploitable CVEs, satisfying the stem's Dockerfile hardening requirement.

Scanning images for vulnerabilities before pushing catches known CVEs in dependencies and base layers while the artefact is still inside the pipeline, preventing flawed images from reaching the registry. This satisfies the requirement to gate builds on security findings before publication.

Minimal images like distroless or Alpine strip out package managers, shells, and extraneous system utilities, removing the tools an attacker would need to pivot, write files, or download additional binaries after breaking into a process. Distroless images provide a root filesystem with only the application and its runtime libraries, offering no interactive shell; Alpine achieves small size and a lower CVE count through BusyBox and musl libc. For maximum benefit, pair minimal images with non-root execution, read-only root filesystems, and regular scanning, since even minimal images still require patching for vulnerabilities in their included libraries.

ImagePolicyWebhook forwards image admission requests to an external HTTPS endpoint that approves or rejects them. Configuring it to permit only myregistry.io images enforces the trusted-registry constraint at admission time, blocking pods referencing any other registry.

This is the correct command because `trivy image` is the dedicated subcommand for scanning container images. It resolves `myimage:latest` from the local Docker daemon cache or a remote registry, analyzes the image layers and SBOM of OS packages (like Alpine, Debian, CentOS) and language-specific dependencies (pip, npm, cargo, etc.), and then compares them against the Trivy vulnerability database to report CVEs. In a CI/CD pipeline, running this after `docker build` but before `docker push` catches vulnerable images before they are published.

Syft is a dedicated, purpose-built SBOM generator from Anchore that catalogs packages from container images, OCI layout archives, and directory trees. It supports a broad range of ecosystems — dpkg, RPM, APK, Python, npm, Go modules, Java archives, etc. — and emits standardized formats like SPDX, CycloneDX, and its own custom Syft format. Because its sole mission is to inventory components with precise versions and package URLs, syft is the authoritative and most commonly used tool for generating SBOMs in cloud-native environments.

Trivy scans container image layers and installed OS packages against vulnerability databases, reporting CVEs before deployment. Integrating it into the CI/CD pipeline satisfies the stem's requirement to detect known vulnerabilities pre-deployment, unlike admission controllers or runtime tools that act only after images reach the cluster.