Platform Security practice questions

runAsUser: 1000

Why it fails: Running as a non-root UID restricts permissions but does not make the filesystem read-only.

allowPrivilegeEscalation: false

Why it fails: This setting prevents processes from gaining new privileges, not from writing to the filesystem.

privileged: false

Why it fails: While disabling privileged mode is important, it does not make the root filesystem read-only.

To provision persistent block storage volumes

Why it fails: Storage provisioning is handled by Container Storage Interface (CSI) plugins.

To manage DNS lookups across cluster namespaces

Why it fails: DNS resolution is handled by CoreDNS.

To encrypt all secrets stored within Kubernetes Secrets objects

Why it fails: Secret encryption at rest is managed by the Kubernetes API server configuration and encryption providers.

Kubernetes persistent volume snapshotting

Why it fails: Volume snapshotting backs up storage data, unrelated to runtime security monitoring.

CoreDNS query log analysis

Why it fails: CoreDNS logs resolve domain name queries, not runtime container security events.

A LimitRange with `max` CPU and memory values applied to namespace `team-a`.

Why it fails: A LimitRange sets per-pod or per-container maximums and defaults, but it does not cap the total aggregate consumption of the namespace. A tenant could still schedule many pods that each stay under the per-pod maximum and collectively exceed 2 CPU cores and 4Gi. It also injects defaults rather than rejecting pods that omit requests, so it fails both requirements.

A PodDisruptionBudget referencing the tenant's deployments in namespace `team-a`.

Why it fails: A PodDisruptionBudget controls how many pods may be voluntarily evicted during maintenance or node drains. It has nothing to do with CPU or memory consumption and cannot reject pods that omit resource requests. Using it here would leave the tenant completely unbounded on compute resources, so it does not meet the stated goal.

A NetworkPolicy with ingress and egress rules applied to namespace `team-a`.

Why it fails: A NetworkPolicy governs which pods can communicate with each other over the network. It is a layer 3/4 isolation control and does not constrain CPU or memory usage in any way. Applying it would not prevent a tenant from over-consuming node resources or from scheduling pods without resource requests, so it is irrelevant to this scenario.

/var/log/containers/

Why it fails: /var/log/containers/ holds kubelet-managed symlinks to container log files, so containerd never reads seccomp JSON there. It is tempting because it is a real, frequently referenced path on worker nodes, and it would be the right location when troubleshooting container log output.

/etc/kubernetes/manifests/

Why it fails: /etc/kubernetes/manifests/ holds static pod manifests read by the kubelet, not seccomp profiles referenced by pod specs. It is tempting because it is a well-known control-plane directory, and it would be the right location when deploying a static pod such as kube-apiserver.

/etc/containerd/certs.d/

Why it fails: /etc/containerd/certs.d/ stores registry TLS certificate configuration, so containerd ignores seccomp profiles placed there. It is tempting because it is a genuine containerd configuration directory, and it would be correct when configuring a private registry's certificate trust.

readOnlyRootFilesystem: false

Why it fails: Setting readOnlyRootFilesystem to false leaves the root filesystem writable, which governs filesystem immutability, not privilege escalation. It is tempting because read-only roots harden containers against tampering, and that setting would be correct when the requirement is preventing runtime modification of container files, not blocking setuid-based privilege gain.

privileged: true

Why it fails: privileged: true grants the container full access to host devices and capabilities, the opposite of preventing privilege gain. It is intended for trusted system workloads needing host-level access, whereas noNewPrivileges: true blocks setuid escalation as the stem requires.

runAsNonRoot: false

Why it fails: runAsNonRoot: false permits the container to start as UID 0, the opposite of restricting privilege acquisition; no_new_privs is the kernel feature that blocks setuid escalation. It is tempting because runAsNonRoot enforces non-root execution, which would be correct when the requirement is simply preventing containers from running as root.

Enable resource quotas on the default namespace

Why it fails: Resource quotas cap aggregate CPU, memory and object counts per namespace; they inspect no image contents and cannot block a pod because of a CVE. It is tempting because quotas are the correct mechanism when the requirement is preventing one namespace from consuming cluster resources beyond its allocation.

Rotate the cluster certificate authority

Why it fails: Rotating the cluster certificate authority refreshes the trust material used for TLS authentication between components; it does not inspect image layers or block workloads. Its purpose is recovering from CA compromise or expiry. Admission control, via a policy engine such as Kyverno or Gatekeeper, is what evaluates image scan results before a pod is admitted.

Add network policies to restrict outbound CVE database queries

Why it fails: Network policies filter pod ingress and egress traffic; they never inspect image layers, so a vulnerable image still schedules and runs. It is tempting because network policies are the correct mechanism when the requirement is restricting which pods or external endpoints a workload may communicate with.

Node OS package manager updates

Why it fails: Patching node OS packages leaves the container image's own outdated libraries untouched, since containers run their own userspace; the vulnerable packages persist and redeploy. Node patching is tempting because it hardens the host, which is the right fix when the vulnerability sits in host-level components rather than inside the image.

Kubelet container startup phase

Why it fails: Scanning at kubelet container startup catches vulnerable images only after they are scheduled onto a node, too late to prevent the image entering the registry or cluster. It is tempting because runtime admission can block pods, but the earliest effective remediation point is the build or CI phase, before the image is published.

Kubernetes API server audit logging

Why it fails: Audit logging records API requests to the Kubernetes control plane for security forensics; it never inspects image layers or package versions, so it cannot detect the vulnerable packages at all. It is tempting because audit logs are genuinely valuable for detecting suspicious cluster activity, but that is runtime monitoring, not build-time vulnerability remediation.

ingress.kubernetes.io/backend-protocol

Why it fails: backend-protocol tells NGINX how to speak to the backend Service (HTTP, HTTPS, GRPC), so it never references a client CA Secret for verifying inbound client certificates. It is tempting because it is a real NGINX annotation, and it would be correct when the upstream backend expects a non-HTTP protocol.

kubernetes.io/ingress.class

Why it fails: kubernetes.io/ingress.class selects which controller reconciles the Ingress; it carries no certificate data, so mutual TLS client-CA validation cannot be configured with it. It is tempting because it is a genuine NGINX-era annotation, and it would be correct when directing an Ingress to a specific controller class.

nginx.ingress.kubernetes.io/ssl-redirect

Why it fails: ssl-redirect forces HTTP requests to HTTPS, which encrypts transport but performs no client certificate verification, so no trusted Client CA Secret is consumed. It is tempting because it is a legitimate NGINX annotation, and it would be correct when the requirement is simply redirecting plaintext traffic to TLS.

Cilium CNI plugin

Why it fails: Cilium enforces network policy, load balancing and observability at the eBPF layer; it does not intercept admission requests or validate Cosign signatures on image manifests. It is tempting because it is a Kubernetes-native component, but its role is pod networking and security policy, not supply-chain verification.

Metrics-server

Why it fails: Metrics-server only aggregates CPU and memory usage for the Horizontal Pod Autoscaler and kubectl top; it never inspects image registries or admission requests, so it cannot verify Cosign signatures. It is tempting because it runs as a cluster add-on, but its purpose is resource metrics collection, not policy enforcement.

Helm package manager

Why it fails: Helm is a package manager that templates and deploys Kubernetes manifests; it does not perform admission-time signature verification. It is tempting because Helm charts reference images, but signature enforcement requires an admission controller policy engine integrating with Cosign, not a deployment packaging tool.

Container runtime shim

Why it fails: The container runtime shim (such as containerd-shim) supervises container processes and reports exit status to the runtime; it never intercepts network traffic. It is tempting because it sits beside every container, yet mTLS termination requires a sidecar proxy injected into the pod, not the process supervisor.

Kube-proxy

Why it fails: Kube-proxy programs iptables or IPVS rules for service load balancing; it does not terminate or originate TLS, so it cannot perform mTLS encryption or decryption. It is tempting because it runs on every node and handles pod traffic, but that role concerns service routing, not cryptographic interception.

Ingress controller

Why it fails: An ingress controller handles north-south traffic entering the cluster, terminating TLS at the edge, but it does not sit inside each pod or encrypt east-west service-to-service calls. It is tempting because it manages certificates, yet mesh mTLS requires a per-pod sidecar proxy.

The coreDNS plugin

Why it fails: CoreDNS resolves service names to cluster IP addresses for pods; it handles DNS queries, not system calls, so it cannot monitor or alert on runtime threats. It is tempting because CoreDNS is correct when configuring cluster service discovery, custom DNS entries, or forwarding rules.

The Kubernetes storage controller

Why it fails: The storage controller manages persistent volume provisioning and binding for pods; it never observes container system calls, so no syscall interception or alerting occurs. It is tempting because storage controllers are correct when configuring persistent storage classes, claims, and volume lifecycle for stateful workloads.

The kube-apiserver admission webhook

Why it fails: Admission webhooks intercept API server requests to validate or mutate Kubernetes objects before persistence, never system calls. Runtime syscall monitoring belongs to seccomp or eBPF hooks at the container runtime layer. Webhooks are the right choice for enforcing policy on resource manifests at admission time.

Grant cluster-admin permissions to all developers

Why it fails: Granting cluster-admin to every developer widens privilege far beyond image verification, so unsigned public images still deploy. It is tempting because broad permissions do ease troubleshooting and deployment friction, and would suit a disposable, isolated sandbox cluster where no multi-tenant security boundary exists.

Store plaintext passwords in ConfigMaps

Why it fails: ConfigMaps hold configuration as unencrypted plaintext readable by anyone with namespace access, so credentials leak and images remain unverified. It is tempting because ConfigMaps do inject registry credentials into pod specs, and would be correct for non-sensitive settings such as feature flags or log levels.

Disable all network policies in the cluster

Why it fails: Removing network policies permits unrestricted pod-to-pod and egress traffic, which does not verify image provenance and worsens exposure. It is tempting because disabling policies does unblock connectivity during debugging, and would be correct in a flat, trusted lab cluster with no lateral-movement concerns.

The core DNS configuration map

Why it fails: CoreDNS's ConfigMap holds cluster DNS zone and forwarding configuration; it contains no TLS cipher suite or protocol version settings for ingress listeners. It is tempting because ConfigMaps do hold NGINX ingress tuning, but the core DNS ConfigMap governs name resolution only.

The kube-apiserver static pod manifest file

Why it fails: The kube-apiserver static pod manifest configures the Kubernetes API server's own TLS listener, not the NGINX ingress controller's data-plane TLS termination. It is tempting because it is a genuine TLS configuration location, but it governs API server cipher suites and protocol versions, which are unrelated to ingress traffic.

Persistent Volume Claim storage classes

Why it fails: Persistent Volume Claim storage classes define how volumes are dynamically provisioned, including reclaim policy and binding mode; they carry no TLS parameters. It is tempting because storage classes are cluster-level configuration objects, but they never influence the cipher suites or protocol versions an ingress controller negotiates.

CAP_CHOWN

Why it fails: CAP_CHOWN only permits changing file ownership, so dropping it does nothing to block network reconfiguration or host filesystem mounts. It is tempting because it appears in the default Docker capability set and is commonly pruned during hardening, but that is for filesystem ownership hygiene, not the network and mount controls this scenario demands.

CAP_NET_BIND_SERVICE

Why it fails: CAP_NET_BIND_SERVICE only allows binding to privileged ports below 1024; it cannot reconfigure network interfaces or mount host filesystems. It is tempting because its name contains "NET", but it is the capability to retain or grant for services such as web servers listening on port 443, not the one governing interface changes.

CAP_DAC_OVERRIDE

Why it fails: CAP_DAC_OVERRIDE bypasses file read, write and execute permission checks; it grants no ability to alter network configuration or mount host filesystems. It is tempting because it is a genuinely dangerous default capability worth dropping, but it addresses discretionary access control on files, not the network and mount privileges the scenario targets.

By disabling all system calls related to file I/O

Why it fails: Docker and containerd do not disable file-I/O system calls by default; seccomp filters some calls, but device nodes are controlled through device cgroups. Disabling file I/O would break container operation entirely. This option tempts because seccomp profiles do restrict syscalls, so syscall-level control sounds plausible, but that mechanism governs syscall filtering, not device node access.

By routing all device access requests through kube-proxy

Why it fails: kube-proxy handles Service virtual IP load balancing, not device-node mediation; it plays no part in container device access. The tempting pull is that kube-proxy is a familiar container-networking component, so it sounds security-adjacent. It would be relevant when configuring Service routing or cluster network rules, not device cgroup restrictions.

By mounting the entire host /dev directory in read-write mode

Why it fails: Docker and containerd apply a default device cgroup that denies access to host device nodes; they do not mount the host /dev read-write. It is tempting because containers do see a minimal /dev with basic nodes like null and random, but that is a restricted tmpfs, not the host's full device tree.

Fluentd

Why it fails: Fluentd aggregates and forwards log data; it has no registry API and cannot proxy image pulls. It tempts as a familiar CNCF graduated project, yet log shipping is unrelated to caching OCI artefacts, which distribution handles through its pull-through cache configuration.

Jaeger

Why it fails: Jaeger provides distributed tracing for requests across services, storing spans rather than container images. It tempts because it is CNCF-hosted and observability-adjacent, but tracing instrumentation cannot satisfy registry rate limits; distribution's registry proxy is the component that caches upstream layers.

Prometheus

Why it fails: Prometheus is a metrics collection and alerting system, not a registry proxy; it cannot cache or serve container images. It tempts because it is a widely deployed CNCF project, but the required role belongs to distribution, which implements the registry API with pull-through caching.

Pod security standards must be enforced at the baseline level

Why it fails: PeerAuthentication STRICT governs mutual TLS between workloads, requiring encrypted, certificate-verified connections; it has no relationship to Pod Security Standards, which are enforced by the Pod Security admission controller via namespace labels. Baseline PSS would be the answer if the stem asked about privileged containers or hostPath volumes.

Network policies must block all traffic from outside the namespace

Why it fails: PeerAuthentication STRICT mandates mutual TLS between mesh workloads; it does not create or enforce Kubernetes NetworkPolicies, which are separate resources controlling pod-level IP traffic. NetworkPolicy would be the answer if the stem described namespace isolation or blocked CIDR ranges rather than certificate-based peer identity.

All external ingress traffic must pass through a Web Application Firewall

Why it fails: PeerAuthentication STRICT enforces mutual TLS on service-to-service traffic inside the mesh; it does not route or inspect ingress through a web application firewall, which is handled by an ingress gateway or external WAF. A WAF question would concern filtering inbound HTTP requests, not workload identity certificates.

Automatically encrypting persistent volume storage

Why it fails: Ingress TLS termination decrypts inbound HTTP traffic at the controller; persistent volume encryption is handled by storage-layer mechanisms such as EBS encryption or StorageClass parameters. It is tempting because both concern data protection, yet they operate at entirely different layers of the stack.

Preventing the container runtime from executing untrusted binaries

Why it fails: Ingress TLS termination centralises certificate handling and offloads decryption at the controller, but it neither inspects nor restricts what the container runtime executes. It is tempting because ingress controllers do enforce policy at the edge, yet binary execution control belongs to admission controllers and runtime security tooling.

Ensuring that all pod-to-pod communication is blocked

Why it fails: TLS termination at the ingress controller encrypts client-to-controller traffic only; pod-to-pod flows remain governed by NetworkPolicy, so no blanket blocking occurs. It is tempting because ingress sits at the cluster boundary, but east-west traffic control is a separate mechanism entirely.

Automatically encrypting secrets stored in etcd

Why it fails: Image scanning inspects container layers for known vulnerabilities and misconfigurations; it does not encrypt etcd secrets, which is handled by encryption at rest configured on the API server. It is tempting because scanning supports secrets hygiene by flagging hard-coded credentials baked into images.

Generating TLS certificates for ingress controllers

Why it fails: Image scanning examines container contents for vulnerabilities; TLS certificates for ingress are issued and managed by cert-manager or an equivalent controller. It is tempting because scanning pipelines sometimes validate certificate files bundled into images, but certificate generation itself lies outside scanning's function.

Enforcing role-based access control policies

Why it fails: Image scanning analyses artefacts for vulnerabilities and policy violations; RBAC enforcement is performed by the Kubernetes API server authorising requests against roles and bindings. It is tempting because scanning can flag excessive privileges in manifests, but it never enforces access decisions at runtime.