Container image signing provides a cryptographic guarantee about the origin and state of an image. The process involves a trusted entity (a developer or an automated build system) signing an image digest with a private key. Verification, typically performed by an admission controller in a Kubernetes cluster before deployment, uses the corresponding public key to confirm two critical security properties:

1. Authenticity: The signature is valid and was created by the holder of the private key, verifying the image's source.

2. Integrity: The image's current digest matches the digest that was originally signed, ensuring the image has not been altered or tampered with since it was created.

B. The primary purpose is establishing trust through authenticity and integrity, not defining legal or organizational ownership, which is a misinterpretation of the concept.

C. Image signing is a security best practice, not a universal mandate. Cloud providers and Kubernetes do not deny unsigned images by default; this enforcement requires explicit configuration.

D. The signature metadata adds a negligible amount to the registry storage, not the image layers, and verification occurs at deployment time, having no impact on the application's runtime performance.

1. Red Hat OpenShift Documentation: In the section on "Signing container images for trusted software supply chains

" it states

"You can use image signatures to resist tampering and to ensure that you are using a trusted image... When you verify the signature before you use the image

you can be sure that the image has not been tampered with and that it is from a trusted source." (Source: Red Hat OpenShift Container Platform 4.14 Documentation

Chapter 3. Signing container images for trusted software supply chains).

2. Google Cloud Documentation (Binary Authorization): "Binary Authorization is a deploy-time security control that ensures only trusted container images are deployed... By checking for verifiable attestations

Binary Authorization enforces that images have successfully passed required processes... before they are deployed." This directly links verification to ensuring integrity and authenticity in a cloud environment. (Source: Google Cloud

Binary Authorization documentation

"Overview").

3. The Linux Foundation (Sigstore/Cosign Project): The official documentation for Cosign

a project for signing container images

states its goal is to make signatures "invisible infrastructure" to "verify the authenticity and integrity of the artifacts." (Source: Sigstore Documentation

"Cosign" section).

4. Kubernetes Documentation: The mechanism for enforcing signature verification is the admission controller. The documentation on "Dynamic Admission Control" explains how webhooks can be used to "validate... requests

" which is the technical foundation for implementing policies that check image signatures before allowing a pod to run. (Source: Kubernetes Documentation

Reference > API Access Control > Dynamic Admission Control).

A Pod within a Kubernetes cluster can discover and attempt to connect to the API server using the automatically mounted ServiceAccount credentials and internal service discovery. However, this connection is subject to network-level controls. Kubernetes Network Policies are the standard mechanism for enforcing network segmentation. A properly configured egress Network Policy can explicitly deny traffic from a Pod (or a group of Pods) to the API server's endpoint, thereby blocking the connection attempt. This is a critical security practice to limit the potential impact of a compromised workload by preventing it from interacting with the cluster's control plane.

A. Kubernetes does not have a built-in feature to automatically detect a "compromise" and then isolate the Pod. This functionality requires external security monitoring and response tools.

B. This is incorrect because Network Policies can, and in a secure environment often do, place restrictions on which Pods are allowed to communicate with the API server.

D. This is fundamentally incorrect. Kubernetes operates on a principle of least privilege. A Pod's ServiceAccount is granted minimal (often no) permissions by default via RBAC.

1. Kubernetes Official Documentation

"Network Policies": This document explains how Network Policies control traffic flow. The section on "Egress rules" details how to specify destinations that Pods are allowed to connect to. A policy could be written to deny egress traffic to the API server's IP range for most Pods. (See: kubernetes.io/docs/concepts/services-networking/network-policies/#egress-rules)

2. Kubernetes Official Documentation

"Accessing the Cluster": This page describes how a Pod can communicate with the API server. The section "Accessing the API from a Pod" states

"When accessing the API from a pod

the location of the API server is injected into the pod...". This confirms the Pod can attempt the connection

which Network Policies can then block. (See: kubernetes.io/docs/tasks/access-application-cluster/access-cluster/#accessing-the-api-from-a-pod)

3. The Linux Foundation

"Kubernetes and Cloud Native Security" (LFS260 Courseware): University-level courseware developed by the Linux Foundation often covers these principles. For instance

modules on cluster security emphasize using Network Policies for micro-segmentation to limit the "blast radius" of a compromise

including restricting access to the control plane (API server) as a primary defense strategy. The KCSA exam curriculum explicitly lists "Understand Network Policy" under the "Cluster Security" domain.

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.

A RoleBinding grants permissions within a specific namespace. While the cluster-admin ClusterRole contains permissions for all actions on all resources cluster-wide, using it in a RoleBinding constrains those powerful permissions to the single namespace where the RoleBinding is created. This grants the subject (e.g., user, service account) complete control over all resources within that namespace, which explicitly includes the ability to modify the namespace object itself (e.g., its labels and annotations).

A: This is incorrect because the cluster-admin role's wildcard permissions ( on resources) include the namespaces resource, thus granting control over the namespace object itself within the binding's scope.

B: This describes the effect of using the cluster-admin role with a ClusterRoleBinding, which grants cluster-wide access. A RoleBinding is strictly namespace-scoped and cannot grant permissions across all namespaces.

D: This describes the default admin role, which is more limited. The admin role specifically disallows write access to resource quotas and the namespace object, unlike the unrestricted cluster-admin role.

1. Kubernetes Documentation

"Using RBAC Authorization": Under the section "Default Roles and Role Bindings

" the cluster-admin role is described: "When used in a RoleBinding

it gives full control over every resource in the RoleBinding's namespace

including the namespace itself." This directly validates answer C. The same section describes the admin role

confirming the description in option D belongs to a different role.

2. Kubernetes Documentation

"Using RBAC Authorization": The distinction between a RoleBinding and ClusterRoleBinding is fundamental. The documentation states

"A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants them cluster-wide." This confirms that a RoleBinding cannot provide the cluster-wide access described in option B.

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/