KCSA Practice Questions

The verification of a signed container image is based on asymmetric (public-key) cryptography. The signing authority uses its secret private key to generate a digital signature for the image. To verify the image's authenticity and integrity, a user needs the digital signature itself and the corresponding public key of the signing authority. The verification process uses the public key to confirm that the signature is valid for the image, proving it was signed by the holder of the private key and has not been tampered with.

A. The private key is used for signing, not verification, and must be kept secret by the signing authority.

B. The private key is exclusively for creating the signature. Distributing it for verification would compromise the entire security model.

C. While the image's hash is used internally during verification, the user needs the actual digital signature, which is the cryptographic proof to be validated.

1. Kubernetes Documentation

"Signing container images": In the "Verify image signatures" section

the documentation states: "To verify the image signature

you need the signer's public key." This explicitly confirms that the public key is required for the verification step.

Source: Kubernetes Authors

Signing container images

Kubernetes Documentation

Concepts > Containers > Images.

2. Sigstore (Cosign) Documentation: The official documentation for the cosign verify command

a standard tool for signing container images

shows its usage as cosign verify --key . This demonstrates that the public key and the image (which has an associated signature) are the necessary inputs for verification.

Source: The Sigstore Authors

Cosign Verify Command Reference

Sigstore Documentation.

3. MIT OpenCourseWare

"6.857 Computer and Network Security

Fall 2017": Lecture 9 on Public-Key Cryptography defines the digital signature scheme. The verification algorithm is formally described as Verify(message

signature

publickey)

which returns true or false. This academic principle directly applies to verifying signed container images.

Source: Rivest

R.

Lecture 9: Public-Key Cryptography

Digital Signatures

MIT OpenCourseWare

6.857

Fall 2017.

This scenario describes a container breakout achieved through process injection. The hostPID: true setting in a Pod's security context breaks the process ID (PID) namespace isolation. This allows processes inside the container to see all other processes running on the host node. However, seeing the processes is not enough to modify them. The SYSPTRACE Linux capability grants the permission to trace and manipulate arbitrary processes using system calls like ptrace(2). The combination of seeing host processes (hostPID) and having the permission to manipulate them (SYSPTRACE) directly enables this privilege escalation.

A. This is incorrect because misconfigurations of privileges and capabilities are a well-documented vector for container escape and privilege escalation in Kubernetes.

C. hostPath grants access to the host's filesystem, not its processes. AUDITWRITE allows writing to the kernel audit log, which is unrelated to process manipulation.

D. hostNetwork grants access to the host's network stack, and NETRAW allows crafting raw network packets. These are network-related privileges, not process control privileges.

1. Kubernetes Official Documentation

Pod Security Standards: The "Baseline" policy explicitly disallows setting hostPID to true

highlighting its security risk. The documentation states

"The baseline policy is a set of controls that prevent known privilege escalations."

Source: Kubernetes Documentation > Reference > Security > Pod Security Standards

Section: Policy definitions > Baseline > Host Namespaces (spec.hostPID

spec.hostIPC)

2. Kubernetes Official Documentation

Configure a Security Context for a Pod or Container: This document explains how to set security context fields

including Linux capabilities. It shows the syntax for adding capabilities like SYSPTRACE to a container

which grants privileges not given by default.

Source: Kubernetes Documentation > Tasks > Configure Pods and Containers > Configure a Security Context for a Pod or Container

Section: Set capabilities for a Container

3. Linux Programmer's Manual

capabilities(7): The official Linux man page defines the SYSPTRACE capability.

Source: man 7 capabilities

Section: CAPSYSPTRACE

Quote: "Trace arbitrary processes using ptrace(2)... This capability is required to attach to other processes." The ptrace system call is the primary mechanism for debugging

inspecting

and modifying another process's memory and registers.

A multi-stage build is a feature used in Dockerfiles to create more efficient and smaller container images. It involves using multiple FROM instructions, where each FROM starts a new, temporary build stage. An initial stage might use a larger image containing compilers, SDKs, and build tools to compile the application. A subsequent, final stage then starts from a minimal base image (e.g., alpine or distroless) and copies only the necessary compiled artifacts from the initial stage. This process discards all intermediate build tools and dependencies, resulting in a significantly smaller, optimized, and more secure production image.

A. This describes a collaborative development workflow, not the technical process of a multi-stage build.

B. This refers to the architecture of a container registry or image distribution strategy, not the image creation process.

C. This describes parallelization, whereas multi-stage builds are about sequential stages to isolate build-time and run-time environments.

1. Docker Official Documentation

"Multi-stage builds": "With multi-stage builds

you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base

and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another

leaving behind everything you don’t want in the final image."

2. Red Hat OpenShift Documentation

"Creating images using a multi-stage build": "A multi-stage build is a process that divides the Dockerfile into multiple stages to separate the build-time dependencies from the run-time dependencies... The final image is smaller and more secure because it does not contain the build-time dependencies." (Section: "About multi-stage builds").

3. Google Cloud Documentation

"Container build best practices": "One of the most effective ways to minimize your image size is to use Docker's multi-stage builds. For example

you can use a build stage that contains the build tools for your application

and a separate runtime stage that contains only the application runtime and the built application." (Section: "Minimize image size").

gVisor is an application kernel, often called a user-space kernel, that intercepts system calls from a containerized application and handles them within a sandboxed environment, isolating the application from the host kernel. This provides a strong security boundary without the overhead of a full virtual machine. In contrast, Firecracker is a Virtual Machine Monitor (VMM) that utilizes the Linux Kernel-based Virtual Machine (KVM) to create and manage minimalist micro-VMs. This approach provides hardware-virtualized isolation, which is ideal for secure, multi-tenant workloads like those in function-as-a-service (FaaS) platforms.

B. This option incorrectly swaps the definitions of gVisor and Firecracker. Firecracker is the VMM, and gVisor is the user-space kernel.

C. They are distinct isolation technologies, not interchangeable container runtimes. Their performance, compatibility, and security trade-offs are fundamentally different.

D. They are separate, competing technologies developed by different organizations (Google for gVisor, Amazon/AWS for Firecracker) with different underlying architectures.

1. gVisor Official Documentation: "gVisor is an application kernel

written in Go

that implements a substantial portion of the Linux system call interface. It provides an isolation boundary between the application and the host kernel."

Source: gVisor Project Documentation

"Overview

" gvisor.dev/docs/.

2. Firecracker Official Documentation: "Firecracker is an open source virtualization technology that is purpose-built for creating and managing secure

multi-tenant container and function-based services... Firecracker uses the Linux Kernel-based Virtual Machine (KVM) to run workloads in lightweight virtual machines

called microVMs."

Source: Firecracker Project Documentation

"What is Firecracker?"

firecracker-microvm.github.io/.

3. Peer-Reviewed Academic Publication: "Firecracker is a virtual machine monitor (VMM) that is purpose-built for running serverless functions and containers safely and efficiently... Unlike general-purpose VMMs

Firecracker is minimalistic."

Source: Agache

A.

et al. (2020). Firecracker: Lightweight Virtualization for Serverless Applications. 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI '20). Section 1: Introduction. (Available via USENIX Association).

Static Pods are managed directly by the kubelet daemon on a specific node, bypassing the Kubernetes control plane components like the API server and the scheduler for their creation. The kubelet watches a specific path on the node's filesystem (e.g., /etc/kubernetes/manifests) for Pod manifest files. When a manifest appears, the kubelet creates the Pod on that node without any intervention from the kube-scheduler. Because they are not managed by standard API-driven controllers (like Deployments or ReplicaSets), their lifecycle is tied directly to the kubelet on a single node, which makes centralized tracking, scaling, and management more difficult compared to standard Pods.

A. Static Pods are, by definition, confined to the single node where their manifest file resides and are managed by that node's kubelet; they cannot span multiple nodes.

B. There is no specific, predefined limit of 5 static Pods per node. The number of Pods a node can run is determined by its resources and the general --max-pods kubelet configuration.

D. The kubelet deploys static Pods as soon as it detects their manifest files in its configured directory, regardless of the kube-scheduler's operational status.

1. Kubernetes Documentation

"Static Pods": "Static Pods are managed directly by the kubelet daemon on a specific node

without the API server observing them. [...] the kubelet on each node watches a specific directory for static pods. The kubelet on each node acts as the scheduler and controller for its own static pods." This confirms that the kubelet manages them locally

bypassing the central scheduler.

Source: Kubernetes Authors. (n.d.). Static Pods. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/

2. Kubernetes Documentation

"Kubelet": The kubelet configuration options

specifically --pod-manifest-path

define the mechanism for discovering static Pods. There is no mention of a specific numerical limit for static Pods

nor is their deployment conditional on the scheduler's state.

Source: Kubernetes Authors. (n.d.). kubelet. Kubernetes Documentation. Retrieved from https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/

The Kubernetes project has officially migrated its container image registry from k8s.gcr.io to registry.k8s.io. As of April 3, 2023, the k8s.gcr.io registry was frozen, meaning no new images or updates are published to it. Consequently, any attempt to pull image versions released after this date from the old k8s.gcr.io address will fail because they do not exist there. The cluster must be updated to pull images from the new registry.k8s.io endpoint to access the latest versions.

A. A network issue would likely cause all image pulls from the registry to fail, not just those for more recent versions.

B. While a bug is possible, the announced and implemented deprecation of the registry is a far more direct and certain cause for this specific issue.

C. Images on k8s.gcr.io are public, and pulling them does not typically require authentication credentials, making this an unlikely cause.

1. Kubernetes Blog. (2023

March 20). k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2023/03/10/image-registry-redirect/. In the "What is changing?" section

it states

"On Monday

April 3

2023

we will redirect traffic from k8s.gcr.io to registry.k8s.io."

2. Kubernetes Documentation. Registry k8s.io: replacing k8s.gcr.io. Retrieved from https://kubernetes.io/docs/reference/k8s-api/workload-resources/pod-v1/#registry-k8s-io. The documentation explicitly states

"The Kubernetes project runs a container image registry at registry.k8s.io to host the container images it manages. This replaces the legacy registry

k8s.gcr.io."

3. Kubernetes Blog. (2022

November 28). k8s.gcr.io is going away

what you need to know. Kubernetes.io. Retrieved from https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/. The "Timeline" section details the plan to freeze the k8s.gcr.io registry in April 2023.

Admission controllers are the primary Kubernetes mechanism for enforcing policies on objects during their creation, update, and deletion. A validating admission webhook, a type of admission controller, can be configured to intercept Pod creation requests sent to the API server. This webhook can then invoke an external service to verify that the container images specified in the Pod manifest have valid signatures (e.g., using Sigstore/Cosign). If an image is unsigned or the signature is invalid, the admission controller denies the request, preventing the Pod from being scheduled and thus blocking the image from running in the cluster.

B. Using PodSecurityPolicy (PSP) to enforce image signing and validation.

PodSecurityPolicy (PSP) is a deprecated feature (removed in v1.25) that controlled pod security contexts and did not have a native mechanism for image signature validation.

C. Using Pod Security Standards (PSS) to enforce validation of signatures.

Pod Security Standards (PSS) define security levels for pods (e.g., privileged, baseline, restricted) but do not include controls for verifying image provenance or digital signatures.

D. Configuring Container Runtime Interface (CRI) to enforce image signing and validation.

While some container runtimes can validate image signatures, this is a decentralized, node-level configuration, not a centralized, cluster-wide policy enforcement mechanism managed via the Kubernetes API.

1. Kubernetes Documentation

"Using Admission Controllers": "Admission controllers are plugins that govern and enforce how the cluster is used. They can be thought of as a gatekeeper that intercepts (authenticated) API requests and may change the request object or deny the request altogether." This establishes their role as the primary policy enforcement mechanism.

2. Kubernetes Documentation

"Dynamic Admission Control": Section "What are admission webhooks?" explains how webhooks are used to implement custom admission policies. It states

"Validating admission webhooks... can reject requests to enforce custom policies." This is the specific mechanism used for tasks like signature validation.

3. CNCF

"Cloud Native Security Whitepaper v2"

Section 4.2.2 - Secure

Page 31: "An admission controller can be used to enforce a policy that all images must be signed by a trusted party before they can run in a cluster." This directly links admission controllers to the enforcement of image signing policies.

4. Kubernetes Documentation

"Pod Security Standards (PSS)": This page details the specific controls enforced by PSS

which are related to a pod's Security Context (e.g.

runAsUser

seccompProfile

capabilities). It makes no mention of image signature validation

confirming this is outside its scope.

A service mesh is a dedicated infrastructure layer designed to manage service-to-service communication within a microservices architecture. It operates at the application layer (Layer 7) by injecting sidecar proxies (e.g., Envoy) into each application pod. These proxies intercept all network traffic, enabling the enforcement of fine-grained security policies for internal (east-west) cluster traffic. This includes features like mutual TLS (mTLS) for identity and encryption, and authorization policies based on application-level attributes such as HTTP methods, headers, or gRPC service names, which is not possible with standard Kubernetes resources.

A. Network Policy: This is a native Kubernetes resource that operates at the network and transport layers (L3/L4), controlling traffic based on IP addresses and ports, not application-layer data.

B. Ingress Controller: This component manages external traffic entering the cluster (north-south), routing it to internal services. It does not manage or apply policy to internal service-to-service communication.

C. Container Runtime: This software (e.g., containerd) is responsible for running containers. It handles container lifecycle and host-level isolation, not network policy enforcement between services.

1. Istio Documentation

"Authorization Policy": The official documentation for Istio

a prominent service mesh

explicitly shows how to create authorization policies that operate at Layer 7. For example

rules can specify allowed HTTP methods (e.g.

"GET") or paths (e.g.

"/api/v1"). This demonstrates the application-layer capabilities for internal traffic.

Source: Istio Authors

Authorization Policy

Istio Documentation

istio.io/latest/docs/reference/config/security/authorization-policy/. Accessed October 2023.

2. Kubernetes Documentation

"Network Policies": The official Kubernetes documentation states that Network Policies use pod selectors

IP blocks

and port numbers to control traffic flow. This confirms their operation at Layers 3 and 4 of the OSI model

not the application layer.

Source: The Kubernetes Authors

Network Policies

Kubernetes Documentation

kubernetes.io/docs/concepts/services-networking/network-policies/. Accessed October 2023.

3. Gao

Y.

et al. (2021). "A Survey on Service Mesh: Architecture

State-of-the-art

and Challenges." This peer-reviewed academic paper describes the core architecture of a service mesh

highlighting its data plane (sidecar proxies) which "can parse application-layer protocols (e.g.

HTTP

gRPC)" to provide advanced security and traffic management.

Source: IEEE Access

vol. 9

pp. 34035-34053

2021

DOI: 10.1109/ACCESS.2021.3059977. (Section III-B

"Security").

4. Linkerd Documentation

"Authorizing Incoming Requests": The documentation for Linkerd

another CNCF service mesh

details its server-side authorization policies. These policies can match on application-layer criteria like the path of an HTTP request

demonstrating L7 policy enforcement for internal cluster traffic.

Source: Linkerd Authors

Authorizing Incoming Requests

Linkerd Documentation

linkerd.io/2.14/features/server-policy/. Accessed October 2023.

The act of "trojanising" a container image is a direct manipulation and unauthorized modification of its contents. The STRIDE threat modeling framework categorizes threats based on the type of security property violated. In this scenario, the integrity of the container image is compromised. The Tampering category specifically addresses the unauthorized modification of data or code. By injecting malicious code into the image on the build server, the attacker has tampered with the asset, violating its integrity.

A. Repudiation: This threat involves an attacker denying they performed a malicious action. It does not describe the act of modifying the image itself.

B. Spoofing: This involves impersonating another user, component, or entity. While the tampered image might be used to spoof a legitimate service, the core act of modification is tampering.

C. Denial of Service: This threat focuses on making a system or resource unavailable to legitimate users. The modification itself is not a DoS, although the resulting trojan could potentially cause one.

1. Microsoft Documentation: In the official description of the STRIDE model

Tampering is defined as the "modification of data." The scenario describes a modification to the data and code within the container image.

Source: Microsoft

"The STRIDE Threat Model

" Security Development Lifecycle. Section: "Tampering."

2. University Courseware: University security courses define tampering as a violation of integrity. Modifying a container image to include a trojan is a classic example of an integrity violation.

Source: University of Washington

Paul G. Allen School of Computer Science & Engineering. CSE 481D: Systems and Security

Lecture 2: Threat Modeling

Slide 15

"STRIDE

" defines Tampering as "Modification of data (integrity)."

3. Academic Publication: Foundational security literature and academic papers on threat modeling consistently link the unauthorized modification of assets to the threat of tampering.

Source: Shostack

A. (2008). Experiences Threat Modeling at Microsoft. MODSEC. Section 2.1

"STRIDE

" describes Tampering as "If an attacker can change my data

that's a violation of integrity." The container image is the data in this context.

Grafana is an open-source analytics and interactive visualization web application. It enables users to query, visualize, alert on, and understand metrics from various data sources. Its primary function is to create dashboards for time-series data, which is crucial for monitoring the performance of applications and infrastructure. Grafana connects to popular time-series databases like Prometheus, InfluxDB, and Elasticsearch, allowing operators to build comprehensive monitoring solutions by visualizing complex data in graphs, charts, and alerts.

A. This describes a distributed tracing system like Jaeger or Zipkin. Grafana can visualize trace data but is not a tracing system itself.

B. This describes a container orchestration platform like Kubernetes, which is used for deploying and managing containerized applications, not for data visualization.

D. This describes a cloud-native security tool such as Falco or Trivy, which focuses on runtime security and vulnerability scanning, not monitoring metrics.

1. Grafana Labs Official Documentation: In the "Introduction to Grafana" section

it states

"Grafana is an open source visualization and analytics software. It allows you to query

visualize

alert on

and explore your metrics

logs

and traces no matter where they are stored. In simple terms

it provides you with tools to turn your time-series database (TSDB) data into beautiful and easy to understand graphs and visualizations."

Source: Grafana Labs Documentation

"What is Grafana?"

Introduction.

2. Kubernetes Official Documentation: The Kubernetes documentation on monitoring describes using Grafana to visualize metrics collected by Prometheus. It states

"Grafana is a popular graphing tool that can be used to create custom dashboards for the metrics that Prometheus collects."

Source: Kubernetes Documentation

Tasks > Monitoring

Logging

and Debugging > "Tools for Monitoring Resources"

Prometheus section.

3. University of California

Berkeley Courseware: In the "Data 100: Principles and Techniques of Data Science" course

lecture materials on monitoring and alerting describe Grafana's role: "Grafana: Visualization layer on top of a time-series database (e.g. Prometheus). Allows for creating dashboards and alerts."

Source: UC Berkeley

Data 100

Fall 2020

Lecture 25: "Real-Time & Streaming"

Slide 53.