Kubernetes Threat Model practice questions

Internal DNS records for CoreDNS

Why it fails: CoreDNS records map names to IPs but do not inherently provide cryptographic authentication material.

HorizontalPodAutoscaler metric configurations

Why it fails: HPA configs contain scaling targets, not sensitive credential material.

PersistentVolume claim capacity metadata

Why it fails: PVC metadata describes storage size and access modes, lacking credential value.

Deploy the Pod in the kube-system namespace

Why it fails: kube-system houses critical control plane components and is not intended for isolating general workloads.

Attach a ClusterRoleBinding granting anonymous system:unauthenticated rights

Why it fails: Binding to unauthenticated groups increases risk rather than securing the workload.

Read-only access to all Secrets and ConfigMaps cluster-wide

Why it fails: Default service accounts cannot read secrets or configmaps outside of API discovery calls.

Full administrative rights restricted strictly to its own namespace

Why it fails: Default service accounts do not receive admin rights within their own namespace by default either.

Cluster-admin permissions across all cluster namespaces

Why it fails: Giving default service accounts cluster-admin privileges would violate the principle of least privilege and was never default behavior.

Enabling the AlwaysAdmit authorization webhook mode

Why it fails: AlwaysAdmit permits all requests and provides zero security isolation.

Default ClusterRole bindings assigned automatically to all service accounts

Why it fails: Default service accounts do not receive cluster-wide privileges automatically.

NetworkPolicies blocking traffic directed at the Kubernetes API server port

Why it fails: NetworkPolicies govern pod-to-pod traffic, while API server access is controlled via authentication and RBAC authorization.

Granting all service accounts cluster-admin permissions to simplify deployments

Why it fails: Granting wide permissions violates least privilege and increases blast radius.

Disabling audit logging to reduce etcd disk I/O latency

Why it fails: Disabling audit logging removes accountability and hinders incident investigation.

PodSecurityStandards

Why it fails: PodSecurityStandards enforce security contexts such as privilege escalation and root user execution, not resource limits.

ValidatingWebhookConfiguration

Why it fails: While custom webhooks can check resources, LimitRanger is the built-in admission controller purpose-built for resource constraints.

NetworkPolicy

Why it fails: NetworkPolicy controls layer 3/4 network traffic between pods, not node-level compute resource consumption.

Kubelet TLS bootstrapping

Why it fails: Kubelet TLS bootstrapping automates issuance of kubelet client certificates to join nodes securely; it has no role in verifying container image signatures. It is tempting as a cluster trust mechanism, but the audit concerns image provenance from public registries, which requires signature verification rather than node identity bootstrapping.

Secret encryption at rest using a KMS provider

Why it fails: KMS-backed secret encryption protects Kubernetes Secret objects stored in etcd, not container image provenance or signature verification. It is tempting because both are cluster hardening controls, but encryption at rest addresses data confidentiality after storage, whereas the audit requires cryptographic validation of image signatures at admission time.

ImagePolicyWebhook

Why it fails: ImagePolicyWebhook is a deprecated admission plugin that forwards image admission decisions to an external HTTPS service; it does not itself perform signature verification. It is tempting because it sits at admission time, but the stem already specifies an admission webhook, so the missing control is a signature-verification mechanism such as Sigstore policy enforcement.

Environment variables require etcd encryption at rest to function correctly.

Why it fails: Environment variables have no dependency on etcd encryption configuration.

Environment variables cannot be read by the application running inside the container.

Why it fails: Applications can easily read environment variables; the risk is unauthorized visibility by users with pod read access.

Environment variables prevent the pod from passing liveness probes.

Why it fails: Environment variables do not interfere with liveness probe execution.

Connect to the etcd server on port 2379 using the default etcd client certificate found in the container image.

Why it fails: etcd client certificates are not distributed with container images. They are stored on control plane nodes and are not accessible from a compromised pod. Also, etcd is typically bound to localhost or protected by mutual TLS, so an attacker inside a pod cannot simply connect without credentials or network access. This step would not be a practical initial enumeration method.

Read the kubelet configuration file at /var/lib/kubelet/config.yaml on the node to extract the cluster's certificate authority key.

Why it fails: The kubelet configuration file resides on the host node filesystem, not inside the container's filesystem. Unless the pod has a hostPath mount to /var/lib or runs privileged, the attacker cannot access it. Even if accessed, the kubelet config typically contains client CA and kubeconfig paths, not the cluster CA private key, so it would not directly enable API enumeration.

Use the Kubernetes DNS service to perform a zone transfer and retrieve all service records in the cluster.

Why it fails: CoreDNS, the default Kubernetes DNS provider, does not support zone transfers (AXFR) for cluster services. DNS queries can reveal individual service names if guessed, but a zone transfer is not possible. This method would not provide a comprehensive list of pods or services and is not a typical attacker technique in Kubernetes threat models.

CoreDNS

Why it fails: CoreDNS resolves service and pod DNS names inside the cluster; it exposes no management API and performs no authentication or authorization of administrative requests. It is tempting because it runs in the control plane's namespace and is critical infrastructure, but the correct answer is kube-apiserver, which serves the authenticated management interface.

kube-proxy

Why it fails: kube-proxy programs iptables or IPVS rules on each node to implement Service load balancing; it exposes no management API and authenticates no administrative clients. It is tempting because it is a core Kubernetes networking component, but the correct answer is kube-apiserver, which exposes the authenticated cluster management interface.

kube-scheduler

Why it fails: kube-scheduler only assigns pending pods to nodes; it exposes no management API and accepts no client authentication, so it cannot be the cluster's primary management interface. It is tempting because it is a control-plane component, and hardening it matters, but the correct answer is kube-apiserver, which serves kubectl and all authenticated requests.

Manual inspection of etcd database backups

Why it fails: Inspecting etcd backups reveals cluster state and secrets, not the packages inside container images, so it cannot identify vulnerable base images. It is tempting because etcd holds cluster configuration and is a recognised hardening target, but this is runtime state review rather than pre-deployment image scanning.

Configuring kube-dns forwarding rules to external resolvers

Why it fails: kube-dns forwarding rules control name resolution to external resolvers, which has no bearing on image contents or vulnerability detection. It is tempting because DNS configuration is a cluster-level hardening task, yet it addresses network egress resolution rather than scanning base images in the CI pipeline before workloads reach the cluster.

Setting up PersistentVolume backup retention policies

Why it fails: PersistentVolume backup retention governs recovery of cluster storage, not inspection of image layers, so it cannot detect vulnerable base images before deployment. It is tempting because backups are a supply chain resilience control, but retention policies address data durability after compromise rather than scanning artefacts during the build stage.

Configuring Horizontal Pod Autoscalers to limit request rates

Why it fails: Horizontal Pod Autoscalers adjust replica counts in response to CPU or custom metrics; they neither inspect nor block API requests, so an SSRF-originated call still reaches the API server. Autoscaling is tempting because it manages request load, and it would be correct when the requirement is scaling workloads to match demand rather than filtering network traffic.

Enabling Pod Security Standards in baseline mode across all namespaces

Why it fails: Pod Security Standards govern pod spec fields such as privileged containers and hostPath mounts; they do not authenticate or authorise API server calls, so an SSRF request from a compromised controller still reaches the API server. Baseline mode is tempting because it hardens workloads cluster-wide, and it would be correct when restricting pod capabilities rather than API traffic.

Disabling the Kubelet read-only port on all worker nodes

Why it fails: The Kubelet read-only port serves pod and node metadata on each worker; disabling it closes that unauthenticated endpoint but does nothing to API server requests, so SSRF traffic still arrives. It is tempting because it removes an unauthenticated listener, and it would be correct when hardening Kubelet exposure rather than controlling API server access.

NamespaceLifecycle admission plugin

Why it fails: NamespaceLifecycle blocks object creation in namespaces that are terminating or nonexistent; it evaluates namespace state, not image content. It would correctly reject a pod submitted to a namespace mid-deletion, but signature verification requires a policy engine such as ImagePolicyWebhook or a Sigstore-backed admission controller.

DefaultStorageClass admission controller

Why it fails: DefaultStorageClass assigns a default PersistentVolumeClaim storage class when none is specified; it acts on storage claims, not container images. It would be the correct controller for automatically binding PVCs to a designated class, but it performs no verification of image signatures or registry trust.

LimitRanger

Why it fails: LimitRanger enforces per-pod resource requests, limits and default constraints within a namespace; it inspects resource quantities, not image signatures or registry provenance. It would be the right plugin for capping CPU and memory consumption, but it cannot evaluate whether an image is signed.

Denial of Service via CPU exhaustion

Why it fails: CPU exhaustion is a resource-consumption attack mitigated by resource requests, limits and quotas; hostNetwork does not allocate or restrict CPU. Those controls address denial of service. hostNetwork instead places the pod in the node's network namespace, exposing node interfaces and elevating spoofing and information-disclosure threats.

Tampering of container image layers at rest

Why it fails: Tampering of image layers at rest concerns registry storage integrity, which hostNetwork does not affect; the pod still pulls the same image. Image signing and admission controls address that threat. hostNetwork instead exposes the node's network namespace, elevating spoofing and information disclosure risks.

Repudiation of database audit logs

Why it fails: Repudiation concerns deniability of actions, typically addressed through audit logging and non-repudiation controls; hostNetwork does not alter database log integrity. Centralised logging tackles that threat. hostNetwork instead shares the node's network stack, exposing services and elevating spoofing and information-disclosure risks.

Bypassing Kubernetes NetworkPolicies across different worker nodes

Why it fails: Docker socket access grants control of the local Docker daemon on that host, not the cluster-wide policy engine that enforces NetworkPolicies. It is tempting because socket escape does yield host-level privilege, and it would be correct if the question concerned bypassing CNI enforcement on the same node.

Direct modification of the etcd database state via local unix socket tunneling

Why it fails: The Docker socket talks to dockerd, not etcd; etcd listens on its own ports and requires separate credentials or certificates, so no unix socket tunnel reaches it. It is tempting because etcd compromise is a genuine cluster takeover path, and it would be correct if the container had mounted etcd's client certificates or data directory.

Automatic escalation of RBAC roles assigned to the API server

Why it fails: RBAC bindings live in the API server's authorisation layer and are not modified by dockerd; the socket yields container and host control instead. It is tempting because privilege escalation is the real outcome of socket exposure, and it would be correct if the container held a service account token with excessive permissions.

ResourceQuota

Why it fails: ResourceQuota caps aggregate namespace consumption of CPU, memory, storage and object counts; it exerts no control over network destinations, so metadata requests remain permitted. It is tempting because quotas constrain workloads, but that constraint is resource-based rather than traffic-based. A NetworkPolicy restricting egress to the metadata IP is required here.

ValidatingWebhookConfiguration

Why it fails: ValidatingWebhookConfiguration intercepts API server admission requests to validate manifests; it never inspects or filters Pod egress traffic, so metadata calls proceed. It is tempting because webhooks enforce cluster policy, but they govern object creation, not runtime networking. A NetworkPolicy selecting the metadata endpoint blocks this vector.

SecurityContext

Why it fails: SecurityContext sets Pod or container privileges such as user ID, capabilities and filesystem access; it does not filter outbound connections, so the metadata request still reaches its destination. It is tempting because it hardens containers, but hardening is not network segmentation. A NetworkPolicy denying egress to the metadata endpoint addresses this vector.

Kernel memory exploitation via unprivileged user namespaces

Why it fails: Kernel memory exploitation via unprivileged user namespaces is a container escape technique, not a supply chain vector; it abuses namespace and privilege bugs to break isolation. It is tempting because it targets cloud-native runtime components, but it would be the answer if the question asked about container breakout rather than typosquatted package publication.

Denial of Service via packet flooding

Why it fails: Packet flooding is a network-layer availability attack, not a supply chain vector; it exhausts bandwidth or connection state rather than injecting malicious code through dependency resolution. It would be correct if the scenario described volumetric DoS against an exposed service, but here the mechanism is publishing lookalike package names.

Man-in-the-Middle etcd keystore sniffing

Why it fails: Sniffing the etcd keystore is a control-plane interception attack, not a supply chain vector; it targets unencrypted peer traffic to steal secrets or cluster state. It would be correct if the question concerned unprotected etcd communications, but typosquatting operates at package publication and dependency installation instead.

Enforcing Basic HTTP Authentication headers in kubelet configuration files

Why it fails: Basic HTTP authentication sends reusable credentials in cleartext and is deprecated in kubelet; it does not provide the certificate-based identity or webhook authorisation the API requires. It is tempting because it adds a credential check, and would be correct only where TLS client certificates are unavailable and transport is otherwise protected.

Disabling the Kubelet API entirely by turning off port 10250

Why it fails: Port 10250 also serves legitimate control-plane functions such as exec, logs and metrics, so disabling it breaks cluster operations rather than securing access. It is tempting because removing the listener eliminates the attack surface, and would be correct only for a node deliberately excluded from control-plane management.

Enabling anonymous requests with strict NetworkPolicy egress rules

Why it fails: Anonymous authentication explicitly permits unauthenticated requests to the Kubelet API, which is the exposure being remediated; NetworkPolicy cannot filter kubelet traffic on port 10250. It is tempting because NetworkPolicy segments pod traffic, and would be correct when restricting east-west pod communication rather than authenticating kubelet callers.

Repudiation

Why it fails: Repudiation concerns denying that an action occurred, addressed through logging, audit trails and non-repudiation controls. It does not describe an attacker reading unencrypted traffic between pods. Repudiation would be the correct category if the scenario involved a user or service denying having performed an action without verifiable evidence.

Tampering

Why it fails: Tampering covers modification of data or code, not interception of traffic in transit. Eavesdropping on unencrypted pod-to-pod traffic is an information disclosure concern, which STRIDE addresses separately. Tampering would fit an attacker altering packets or container images, so the category does not match the confidentiality breach described.

Denial of Service

Why it fails: Denial of Service covers attacks that exhaust resources or make a service unavailable, such as flooding pods or the API server. Eavesdropping on unencrypted internal traffic does not disrupt availability; it breaches confidentiality. Denial of Service would apply if the attacker aimed to crash or overwhelm cluster workloads rather than observe them.

It enforces TLS encryption for all outbound pod network connections.

Why it fails: readOnlyRootFilesystem governs writes to the container's root filesystem layer; it has no relationship to network transport security. TLS for outbound connections is configured at the application or service-mesh level. The option tempts because both are pod securityContext settings, but they control entirely separate mechanisms.

It automatically encrypts all environment variables stored in the Pod spec.

Why it fails: Read-only root filesystems block writes to the container's filesystem layer; they have no effect on environment variable encryption, which depends on Secrets and etcd encryption at rest. It tempts because both concern container security hardening, but encryption is configured separately from filesystem write protection.

It completely prevents any container from starting up if PersistentVolumeClaims are attached.

Why it fails: A read-only root filesystem has no bearing on whether PersistentVolumeClaims can be attached or whether pods start; volumes mount at separate paths regardless. It is tempting because read-only mounts and PVC attachment both concern filesystem writes, but the setting only blocks writes to the container's own root layer, not volume provisioning.