Kubernetes Security Fundamentals practice questions

NamespaceLifecycle

Why it fails: NamespaceLifecycle ensures that requests to a non-existent namespace are rejected and prevents deletion of system namespaces.

DefaultStorageClass

Why it fails: DefaultStorageClass observes PersistentVolumeClaim creation and assigns a default storage class.

LimitRanger

Why it fails: LimitRanger enforces resource allocation limits within a namespace.

storageClassName for volume attachment

Why it fails: Storage classes relate to persistent storage, not networking.

nodeSelector for worker placement

Why it fails: Node selectors are not part of NetworkPolicy rules.

Allows containers to run in privileged mode if requested

Why it fails: Privileged mode is strictly forbidden in restricted profiles.

Permits mounting the host network namespace without restriction

Why it fails: Host network mounting is forbidden in restricted profiles.

Mounting an emptyDir volume into the container.

Why it fails: emptyDir volumes are permitted under both baseline and restricted standards.

Omitting the 'runAsUser' field, allowing the container to run as UID 0 by default.

Why it fails: Running as root (UID 0) is permitted under the baseline standard (though forbidden under restricted).

Adding the 'NET_BIND_SERVICE' capability to the container.

Why it fails: NET_BIND_SERVICE is allowed under the baseline standard.

A PodSecurityPolicy enforcing frontend network access.

Why it fails: PodSecurityPolicy governs pod admission controls such as privileged mode, volumes and capabilities; it has no mechanism for expressing network reachability, so it cannot restrict which pods connect on port 5432. It would be correct for hardening what a pod may request at creation time.

A ServiceMesh AuthorizationPolicy restricting namespace-level routes.

Why it fails: An AuthorizationPolicy is enforced by a service mesh sidecar proxy, so it only governs traffic passing through the mesh; pods without sidecars, or traffic arriving before interception, bypass it entirely. It is the right tool for mTLS identity-based routing between mesh workloads, not for pod-level port isolation.

A NetworkPolicy with an egress rule allowing frontend pods to reach the database.

Why it fails: An egress rule on the database policy governs traffic leaving the database pod, not inbound connections to port 5432; ingress must be restricted instead. Egress rules are the right choice when the requirement is to limit which external destinations a workload may initiate connections to.

Enable the ValidatingAdmissionPolicy to inspect the user's decryption key.

Why it fails: Admission policies control resource creation/updates, not subsequent read requests for existing secrets.

Set the secret data encoding to AES-256 within the manifest metadata.

Why it fails: Secret data must be base64 encoded, and custom metadata fields do not alter RBAC or read capabilities.

Apply a Role restricting Secret viewing by adding a label selector to the RoleBinding.

Why it fails: RoleBindings do not support label selectors to restrict access to individual secret objects based on their labels.

Add the production label to the target pod's metadata and reference it in the egress block.

Why it fails: Egress controls outgoing traffic; ingress is needed for incoming traffic.

Specify only a 'podSelector' with 'environment=production' without any namespace selector.

Why it fails: Omitting the namespaceSelector restricts the rule to pods within the same namespace only.

Use a cluster-wide ClusterNetworkPolicy resource with global label matching.

Why it fails: While AdminNetworkPolicy exists in some networking stacks, standard NetworkPolicies use namespaceSelector for cross-namespace rules.

Assign the tool to the system:masters group.

Why it fails: system:masters bypasses all RBAC authorization checks entirely.

Grant cluster-admin access and restrict requests using a kube-proxy firewall rule.

Why it fails: cluster-admin grants full control and violates least privilege.

Create a ClusterRole with API groups [''] and resources ['pods/status'].

Why it fails: pods/status allows reading or updating pod status conditions, not arbitrary HTTP health endpoints on pods.

Disallowing privileged containers.

Why it fails: Privileged containers are prohibited by both baseline and restricted profiles.

Prohibiting hostPort usage entirely.

Why it fails: Both baseline and restricted profiles disallow hostPort by default (or restrict them).

All outgoing traffic from backend pods is allowed because egress rules were not defined.

Why it fails: Unlike ingress, selecting a pod with a NetworkPolicy restricts unmentioned directions to deny-by-default.

Outgoing traffic is allowed only to frontend pods.

Why it fails: Ingress rules govern incoming traffic, they do not automatically grant egress connectivity back to those sources.

Only DNS egress traffic on port 53 is permitted automatically.

Why it fails: Kubernetes NetworkPolicies do not automatically allow DNS traffic unless explicitly configured via egress rules.

By applying a PodSecurityPolicy with spec.hostNetwork set to false.

Why it fails: Host network settings control network namespace sharing, not service account token mounting.

By editing the kube-apiserver manifest to include the --disable-service-account-tokens flag.

Why it fails: This flag does not exist in kube-apiserver; token mounting is controlled per ServiceAccount or per Pod.

By creating a LimitRange that restricts secret volume mounts.

Why it fails: LimitRanges constrain resource quantities (CPU, memory, storage request/limits), not service account tokens.

Run all containers as the root user (UID 0) to ensure smooth file permission handling.

Why it fails: Running containers as UID 0 means a breakout grants root on the host, defeating the isolation hardening aims to preserve. Root is tempting because it avoids permission errors on mounted volumes, and it is acceptable only where an image genuinely requires privileged file access, which non-root securityContext settings should replace.

Enable hostNetwork and hostPID on all production pods to improve debugging visibility.

Why it fails: Enabling hostNetwork and hostPID shares the node's network and process namespaces with pods, letting a container breakout reach node processes and interfaces directly. These flags are intended for legitimate monitoring or CNI agents needing node-level visibility, not for general production workloads being hardened.

The pod will run in a restricted sandbox environment automatically.

Why it fails: Baseline enforcement rejects privileged pods outright; it never rewrites the securityContext into a sandboxed profile. Sandboxing is delivered by runtime classes or gVisor, not by Pod Security Standards. The option confuses enforcement with automatic remediation, which no admission controller performs here.

The pod will be created successfully, but a warning will be logged in the audit log.

Why it fails: Baseline enforcement blocks privileged pods at admission, so the API server returns an error and no object is persisted; audit warnings accompany the warn or audit labels, not enforce. Warning-only logging is what the audit mode produces when you want visibility before switching to enforcement.

The kubelet will automatically strip the 'privileged: true' setting and run the pod safely.

Why it fails: The kubelet never mutates pod specs; admission control rejects the request before scheduling, and privileged is a boolean the container runtime honours as written. Stripping fields is the job of mutating admission webhooks, which the Pod Security Standards do not implement.

Ingress

Why it fails: Ingress manages inbound HTTP and HTTPS routing from outside the cluster to Services, and cannot select backend pods by label to deny traffic. East-west pod-to-pod restriction needs a NetworkPolicy with podSelector and ingress rules. Ingress is correct when publishing an application externally with host or path routing.

FirewallRule

Why it fails: FirewallRule is not a Kubernetes API resource; it belongs to cloud provider firewalls operating at the subnet or VNet boundary, outside cluster pod networking. Pod label selectors cannot be expressed there. Such rules are correct when restricting traffic to infrastructure outside the cluster, not between pods inside a namespace.

Service

Why it fails: A Service provides stable virtual IP load balancing to a set of pods; it neither inspects nor filters traffic between them. Label-based pod-to-pod restriction requires a NetworkPolicy selecting both tiers. Services are the right resource when exposing a workload internally or externally, not for enforcing communication rules.

It automatically generates valid X.509 client certificates for cluster nodes.

Why it fails: Impersonate lets a caller assume an existing identity's authorisation; it does not mint certificates. X.509 client certificates for nodes are issued by the cluster CA via the kubelet TLS bootstrap process, so this describes certificate provisioning, not the impersonate verb's privilege-escalation risk.

It allows the pod to intercept network traffic of other pods on the same node.

Why it fails: Impersonate is an RBAC verb scoped to the API server's authentication and authorisation path; it grants no network-level capability. Traffic interception on a node arises from privileged pods, hostNetwork, or a compromised CNI, so this describes a container escape or packet-sniffing scenario rather than an RBAC permission.

It permits the ServiceAccount to bypass the Kubernetes API server and write directly to etcd.

Why it fails: Impersonation operates through the API server's authorisation layer, letting the holder issue requests as another user; it never touches etcd directly, since etcd access requires separate credentials and network reachability. Direct etcd writes are the concern when etcd ports are exposed or client certificates leak, not when RBAC grants impersonate.

ClusterRoleBinding referencing the Role 'secret-reader'

Why it fails: A ClusterRoleBinding grants cluster-wide scope and cannot reference a namespaced Role, so it would over-permit and the Role reference is invalid. It is tempting because ClusterRoleBinding is the usual way to bind a ClusterRole, and would be correct when the grant must apply across all namespaces.

NamespaceRoleBinding referencing the ClusterRole

Why it fails: NamespaceRoleBinding is not a Kubernetes resource; the namespaced binding type is RoleBinding, which can reference a ClusterRole and restrict it to one namespace. It is tempting because the name implies namespace-scoped binding, which is the desired outcome, but the resource itself does not exist.

ServiceAccountBinding referencing the ClusterRole

Why it fails: ServiceAccountBinding is not a Kubernetes RBAC resource type, so it cannot bind anything; the API would reject it. It is tempting because the name suggests exactly the service-account-to-role link required, and would be correct if such a resource existed for that purpose.

All ingress traffic remains allowed by default.

Why it fails: Once any NetworkPolicy selects a pod, that pod becomes isolated for the specified direction, so unmatched ingress is denied rather than allowed. The tempting confusion is that namespaces without any NetworkPolicy do default to allow-all traffic, which is the scenario where this statement would hold.

The policy fails to apply because an egress rule must also be defined.

Why it fails: NetworkPolicy ingress and egress rules are independent; omitting an egress block simply leaves egress unrestricted, so the ingress rule still applies and denies unmatched traffic. The temptation is that policies often pair both directions, but that pairing is a design convention, not a Kubernetes validation requirement.

Only traffic from other namespaces is denied; same-namespace traffic is still allowed.

Why it fails: NetworkPolicy selectors operate on pod labels, not namespace boundaries, so unmatched traffic is denied regardless of whether its source sits in the same namespace or another. The temptation is assuming namespaces grant implicit trust, which would be true only if no policy selected the backend pods at all.

Create a MutatingWebhookConfiguration that injects security contexts into every pod spec.

Why it fails: Mutating webhooks rewrite pod specs but do not evaluate or reject workloads against Pod Security Standards; enforcement requires the built-in Pod Security admission controller with namespace labels. Mutating webhooks are the right tool for defaulting fields such as securityContext, which is why injection appears relevant.

Modify the kubelet configuration file on every worker node to enable restricted mode.

Why it fails: kubelet settings govern runtime behaviour on each node and cannot enforce Pod Security Standards per namespace; admission happens at the API server before scheduling. Node-level hardening is legitimately used for host and container runtime configuration, making this option superficially attractive.

Deploy a custom PodSecurityPolicy object targeting the namespace selector.

Why it fails: PodSecurityPolicy was deprecated in Kubernetes 1.21 and removed in 1.25, so it cannot serve as the modern mechanism; Pod Security Admission with namespace labels replaces it. PSP is tempting because it historically enforced exactly these restricted, baseline and privileged profiles.

Disable the Pod Security admission controller entirely across the cluster.

Why it fails: Disabling the controller cluster-wide removes enforcement of the restricted profile for every workload, not just this pod, eliminating the baseline isolation the standard provides. It is tempting because it instantly unblocks the legacy pod, and would be valid only in a non-production cluster where no security standard is mandated.

Set the namespace enforce level to 'privileged' permanently.

Why it fails: Setting the namespace to privileged permanently removes all Pod Security restrictions, letting any workload run as root cluster-wide. It tempts because it unblocks the legacy pod immediately, and would be correct only for namespaces genuinely requiring unrestricted workloads, not one root-dependent application.

Mount the host socket inside the pod to bypass user namespace restrictions.

Why it fails: Mounting the host socket grants container escape to the node, defeating isolation entirely rather than satisfying the restricted profile. It tempts because it appears to bypass the runAsNonRoot check, and would be correct only for legitimate node-management agents that genuinely need host-level access.

SecurityContextConstraints

Why it fails: SecurityContextConstraints are an OpenShift-specific admission resource controlling pod privileges, not Kubernetes RBAC permission grants. It is tempting because it governs pod behaviour, and would be correct for restricting what a pod may do, such as running privileged containers or mounting host paths.

PodSecurityPolicy

Why it fails: PodSecurityPolicy is a deprecated admission controller that validates pod security settings, not a mechanism for granting read-only permissions. It is tempting because it references pods directly, and would be correct for enforcing restrictions such as disallowing privileged containers or host networking.

ClusterRole

Why it fails: A ClusterRole grants permissions cluster-wide or must be bound with a RoleBinding to scope it; the requirement is namespace-scoped read access to pods. It is tempting because ClusterRoles define rules identically, and would be correct for resources that are cluster-scoped, such as nodes or persistent volumes.