Kubernetes Security Interview Questions

A Role is a namespaced RBAC resource, so the permissions it grants apply only inside the namespace where it is created. A ClusterRole is cluster-scoped, so it is not confined to any single namespace. It can define permissions that apply across all namespaces, or it can be referenced by a RoleBinding to grant those permissions within just one namespace. Because both halves of the statement hold, the statement is true.

A RoleBinding is a namespaced resource that grants the permissions defined in a Role, or in a ClusterRole, to specified subjects within that RoleBinding's namespace. A ClusterRoleBinding grants across all namespaces. ServiceAccount is an identity, not a binding. Role only defines permissions; it does not bind them to subjects.

Kubernetes RBAC has two role-resource types. A Role grants access to resources only in the namespace where it is created, while a ClusterRole grants access cluster-wide. A ClusterRole can also be referenced by a RoleBinding to apply its permissions within a single namespace, but the cluster-wide scope belongs to a ClusterRole used with a ClusterRoleBinding.

Two related facts trip people up: the default SA is real and auto-created (not 'no ServiceAccount'), and imagePullSecrets can live on the ServiceAccount as a one-time setup rather than being copy-pasted onto every workload that needs the same private registry.

Unconfined sounds like it might mean 'default confinement' but means the opposite — no filtering at all. Knowing restricted rejects it (and rejects an unset profile) explains a common PSA admission failure on images with no seccompProfile configured.

A ClusterRole is a set of rules with no namespace scope, so whether its permissions apply cluster-wide or in one namespace depends on the binding. A ClusterRoleBinding grants the ClusterRole's permissions across all namespaces, which is what is needed here. A RoleBinding that references a ClusterRole narrows the grant to the RoleBinding's own namespace, so a RoleBinding in the default namespace or in kube-system only grants access there. Kubernetes RBAC has no namespaceSelector field on RoleBinding, so that configuration cannot be expressed.

A Role is namespaced and contains the permission rules, so it fills the first blank. A RoleBinding is the namespaced object that connects those rules to specific subjects, so it fills the second blank. Without the RoleBinding, the Role's permissions are inert because no subject receives them until the binding exists.

This is true. A ClusterRole defines permissions that are not tied to a namespace, but when a namespace-scoped RoleBinding references it, the granted permissions apply only within the RoleBinding's namespace. This lets administrators define a reusable ClusterRole once and bind it in each namespace without duplicating the role. A ClusterRoleBinding, by contrast, applies the referenced ClusterRole across the whole cluster.

automountServiceAccountToken can be set on the ServiceAccount object (a default for every Pod using it) and independently on the Pod spec. When both specify a value, the Pod-level field wins — it's the more specific setting. So here the token is mounted, despite the ServiceAccount saying false. This lets you set a safe org-wide default on the ServiceAccount while still opting a specific Pod in or out.

A ServiceAccount subject needs its own kind: ServiceAccount plus separate name and namespace fields — that's how the binding resolves to the exact identity. kind: User with a bare report-generator never matches, because a ServiceAccount's actual authenticated username is the full system:serviceaccount:<namespace>:<name> string, not the bare name. kind: Group with batch:report-generator is malformed too — the real groups a ServiceAccount belongs to are system:serviceaccounts and system:serviceaccounts:<namespace>, not a <namespace>:<name> pair. And cramming the namespace into name (batch/report-generator) doesn't work either — namespace is always its own field on a ServiceAccount subject.

Pod-level securityContext fields act as defaults inherited by every container; a container's own securityContext overrides individual fields for itself. So this container runs as 2000 while any sibling container without its own runAsUser still runs as 1000. There's no admission-time conflict check for this — it's ordinary override behavior, the same shape as CSS specificity or config layering, not a validation error.

Dropping all capabilities and adding back only what's required (capabilities.drop: ["ALL"] followed by adding back only what's needed) and locking the root filesystem read-only (readOnlyRootFilesystem: true) are genuine hardening moves — the second one is also a common source of surprise crashes when an app writes logs, temp files, or a cache to an unmounted path under /. Unconfined is the opposite of the filtered default — it turns syscall filtering off entirely, RuntimeDefault is the one that applies the runtime's filtered set. And capability drops take effect regardless of privileged; in fact privileged: true grants the full capability set back and overrides drops anyway, so the two options are not linked the way the claim that dropping capabilities has no effect unless the container also sets privileged: true claims.

False. PSA replaced PodSecurityPolicy (removed in Kubernetes 1.25) — it did not replace RBAC. RBAC governs which identities can call which API verbs and resources (can this user or ServiceAccount create a Pod at all?); PSA governs what security posture a Pod's spec must have to be admitted into a namespace, checked regardless of who created it. A user with full RBAC rights to create Pods in a namespace can still be blocked by PSA if the Pod's securityContext doesn't meet the namespace's configured level. Both mechanisms remain necessary and operate independently — treating one as a substitute for the other leaves a real gap.

restricted is the strictest Pod Security Standard, and it's checked against the Pod template a Deployment produces. With no securityContext set anywhere, every restricted-only requirement fails at once: runAsNonRoot is unset (defaults to allowing root), allowPrivilegeEscalation is unset (defaults to true), no capabilities are dropped, and no seccomp profile is set. Any one of those alone would be enough to reject the Pod. replicas and namespace placement have nothing to do with PSA, and Deployments are a completely normal, supported workload type under Pod Security Admission — the check runs against the Pods they create.

PSA has no separate policy CRD — it's entirely namespace labels. The three modes decouple 'what would this reject' from 'what does this actually reject,' which is what makes the audit/warn-first-then-enforce rollout pattern possible without breaking existing workloads blind.

The ClusterRole pod-reader defines a reusable rule set granting get and list on pods. The RoleBinding pod-reader-binding is created in the staging namespace, references that ClusterRole, and binds the user alice. A RoleBinding is a namespaced object, so even when its roleRef names a ClusterRole, the grant only takes effect within the binding's own namespace. Therefore alice can get and list pods in staging only. A ClusterRoleBinding referencing the same ClusterRole would instead grant those permissions across all namespaces.

A RoleBinding grants the permissions of whatever role it references — including a ClusterRole — only within its own namespace; the binding, not the role object, determines the effective scope. Disabling default token automount prevents the kubelet from injecting a long-lived token into every Pod; explicitly provisioning a token via a projected TokenRequest volume or a service-account Secret lets you constrain the token's audience, lifetime, and rotation, which reduces exposure if a token leaks or a Pod is compromised.

kubectl auth can-i is the standard CLI for ad-hoc authorization checks. For the current caller it submits a SelfSubjectAccessReview, and the API server evaluates that request against the active authorization modules, including RBAC, and returns whether the action is allowed. Knowing the underlying SelfSubjectAccessReview resource matters for programmatic RBAC audits and for building policy tooling that checks permissions without reading Role bindings directly.

The Role pod-reader has two rules. The first grants get and list on the pods resource in the core API group (the empty string). The second grants get on the pods/log subresource, also in the core API group. The RoleBinding binds the ci-runner ServiceAccount to this Role in the staging namespace, so the ServiceAccount inherits exactly those permissions and nothing more. Creating a pod requires the create verb on the pods resource, and neither rule grants it. Because Kubernetes RBAC denies by default and permits only explicitly listed verbs, the API server returns 403 Forbidden for the create request. The ServiceAccount can read pods and their logs but cannot create, update, or delete them.

Since 1.22, the kubelet obtains this token through the TokenRequest API and mounts it via a projected volume — it's short-lived, scoped to specific audiences, and rotated automatically before it expires. The older behavior, an auto-created long-lived Secret holding a static token, is what this replaced; Kubernetes stopped auto-generating those legacy Secret tokens by default starting around 1.24, reaching GA in 1.27. Treating the mounted token as a permanent credential is exactly the assumption bound tokens were introduced to break — a leaked bound token has a short shelf life.

This Pod already clears every baseline and restricted rule around capabilities and seccomp: dropping all capabilities and adding none back satisfies both levels' capability rules, and RuntimeDefault satisfies both levels' seccomp requirement. The one rule that's restricted-only is runAsNonRoot: true (with a non-zero runAsUser) — baseline never checks it. So baseline admits this Pod as-is, and restricted is the level that catches the root UID and rejects it. Conflating 'dropped all capabilities' with 'runs as non-root' is a common gap in an otherwise well-hardened spec.

False. allowPrivilegeEscalation: false is overridden the instant the same container sets privileged: true (or holds CAP_SYS_ADMIN) — Kubernetes forces privilege escalation back on in that case, because a privileged container already has broader host access than escalation alone would add. The two settings must agree to have any effect; privileged: true always wins over an explicit allowPrivilegeEscalation: false, so pairing them gives you privileged access with a false sense of a mitigating flag.

runAsUser only fixes the process's UID. If runAsGroup is left unset, the primary GID the process runs with defaults to GID 0 — root's group — regardless of how non-root the UID is. That's exactly why new files show up group-owned by root even though runAsNonRoot: true is satisfied (it only checks the UID, not the group). The fix is to set runAsGroup explicitly alongside runAsUser. runAsNonRoot isn't redundant — it's a validation gate the kubelet enforces, refusing to start the container if the resolved UID is 0 — and fsGroup (a Pod-level, volume-ownership setting) has no such equality requirement with runAsUser.

Every step depends on the one before it: there's no token to send until the kubelet has mounted it, no identity to authorize until authentication has resolved one, and no processing until authorization passes. This is also why a Pod with automountServiceAccountToken: false can't call the API at all — step one never happens, so there's nothing to attach to the request in step two.

The system:masters group is special-cased in the kube-apiserver authorization chain. The API server checks for system:masters membership early in request processing and short-circuits all authorization checks, unconditionally allowing the request without consulting any RBAC RoleBindings or ClusterRoleBindings. The cluster-admin ClusterRoleBinding that references system:masters is effectively redundant — it exists for discoverability but does not grant the access; the access is hardcoded. Deleting it therefore has no effect. To genuinely restrict a system:masters member, an administrator must remove the user from the group at the identity-provider or authentication-config level, because no RBAC policy can override or narrow the hardcoded bypass.