Kubernetes Security
RBAC and ServiceAccounts, ConfigMap vs Secret and why Secrets are not encrypted by default, SecurityContext and Linux capabilities, and cluster hardening.
8 questions
JuniorTheoryVery commonWhat is RBAC in Kubernetes, and how do Roles and ClusterRoles grant access to subjects?
What is RBAC in Kubernetes, and how do Roles and ClusterRoles grant access to subjects?
RBAC binds subjects — users, groups or ServiceAccounts — to allowed verbs on resources. A Role scopes rules to one namespace, a ClusterRole is cluster-wide, and a binding attaches a role to subjects. Nothing is permitted until a binding grants it.
Common mistakes
- ✗Thinking RBAC has deny rules rather than being allow-only
- ✗Confusing a namespaced Role with a cluster-wide ClusterRole
- ✗Believing permissions apply without a RoleBinding
Follow-up questions
- →How does a ClusterRole get scoped to one namespace via a RoleBinding?
- →Why is a broad ClusterRoleBinding to cluster-admin so dangerous?
JuniorTheoryCommonWhat is the difference between a ConfigMap and a Secret in Kubernetes?
What is the difference between a ConfigMap and a Secret in Kubernetes?
Both hold key-value config a Pod reads as env vars or mounted files; the difference is intent, not strong protection. A Secret is only base64-encoded, not encrypted at rest unless you enable etcd encryption, and anyone with get on it can read it.
Common mistakes
- ✗Believing a Secret is encrypted just because it is a Secret
- ✗Thinking base64 is a form of protection rather than encoding
- ✗Assuming get access on a Secret does not expose its plaintext
Follow-up questions
- →What has to be configured for Secrets to be encrypted at rest?
- →Why is putting a credential in a ConfigMap worse than in a Secret?
JuniorTheoryCommonWhat is a ServiceAccount in Kubernetes, and how does a Pod use one?
What is a ServiceAccount in Kubernetes, and how does a Pod use one?
A ServiceAccount is an in-cluster identity for workloads, not humans. Every Pod runs as one — the namespace default SA if none is set — and its token is mounted at a well-known path so the Pod can call the API server. RBAC bindings decide what it does.
Common mistakes
- ✗Thinking ServiceAccounts are for human users rather than workloads
- ✗Not realizing a Pod always gets the default SA when none is set
- ✗Believing the SA itself grants permissions without RBAC bindings
Follow-up questions
- →Where in the Pod is the ServiceAccount token mounted by default?
- →Why is running every workload as the default SA a bad idea?
MiddleTheoryCommonHow do you give a workload a dedicated ServiceAccount, and why disable token automounting?
How do you give a workload a dedicated ServiceAccount, and why disable token automounting?
Create a ServiceAccount per workload, set it in the Pod spec as serviceAccountName, and bind only the RBAC roles it needs. Set automountServiceAccountToken: false when the Pod never calls the API server, so a compromised container has no token.
Common mistakes
- ✗Leaving every Pod on the shared default ServiceAccount
- ✗Mounting the API token into Pods that never call the API
- ✗Granting the SA broad roles instead of only what it needs
Follow-up questions
- →What is the risk of a mounted token in a Pod exposed to the internet?
- →How does a projected bound token improve on the legacy secret token?
MiddleTheoryCommonWhat does a Pod or container securityContext control, and which settings harden a workload?
What does a Pod or container securityContext control, and which settings harden a workload?
A securityContext sets the process's security posture: runAsNonRoot with a non-zero runAsUser, readOnlyRootFilesystem, allowPrivilegeEscalation: false, and dropped capabilities. Avoid privileged: true, which grants near-full access to the host.
Common mistakes
- ✗Leaving containers running as root instead of
runAsNonRoot - ✗Confusing
allowPrivilegeEscalation: falsewithprivileged: true - ✗Thinking a read-only root filesystem breaks every application
Follow-up questions
- →What does
allowPrivilegeEscalation: falseactually block? - →Why does
privileged: trueeffectively defeat the other hardening fields?
JuniorTheoryOccasionalWhat are Linux capabilities in a container, and which should you drop by default?
What are Linux capabilities in a container, and which should you drop by default?
Linux capabilities split root's power into units like NET_BIND_SERVICE or SYS_ADMIN, so a process holds just a slice, not full root. Containers start with a broad default set, so drop ALL and add back only what the app needs — usually none.
Common mistakes
- ✗Thinking a container process is either full root or fully unprivileged
- ✗Leaving the default capability set instead of dropping ALL
- ✗Assuming every app needs some capability rather than none
Follow-up questions
- →Which
securityContextfield drops and adds capabilities? - →Why is
SYS_ADMINconsidered close to full root?
SeniorDesignOccasionalYou run one cluster shared by four product teams. Each team owns two namespaces (staging and prod) and must fully self-serve inside them — deploy, scale, read logs — but must never touch another team's namespaces, cluster-scoped objects like nodes and CRDs, or each other's Secrets. A small platform team needs cluster-wide admin, and CI (continuous-integration) pipelines need narrow deploy rights per namespace. Design the RBAC (role-based access control) model: how you use Roles versus ClusterRoles, RoleBindings versus ClusterRoleBindings, ServiceAccounts for CI, and how you keep it least-privilege and maintainable as teams and namespaces grow. Explain why a broad ClusterRoleBinding to cluster-admin would be the wrong tool, and how you avoid wildcard verbs and resources.
You run one cluster shared by four product teams. Each team owns two namespaces (staging and prod) and must fully self-serve inside them — deploy, scale, read logs — but must never touch another team's namespaces, cluster-scoped objects like nodes and CRDs, or each other's Secrets. A small platform team needs cluster-wide admin, and CI (continuous-integration) pipelines need narrow deploy rights per namespace. Design the RBAC (role-based access control) model: how you use Roles versus ClusterRoles, RoleBindings versus ClusterRoleBindings, ServiceAccounts for CI, and how you keep it least-privilege and maintainable as teams and namespaces grow. Explain why a broad ClusterRoleBinding to cluster-admin would be the wrong tool, and how you avoid wildcard verbs and resources.
Write one reusable ClusterRole of namespaced verbs and bind it per namespace with a RoleBinding to each team's group, granting access only inside that namespace. Give CI a deploy-only Role on its own ServiceAccount, keep cluster-admin for the platform team, and avoid wildcard rules.
Common mistakes
- ✗Granting teams a ClusterRoleBinding, which spans every namespace at once
- ✗Using wildcard verbs or resources instead of listing what is needed
- ✗Sharing one CI ServiceAccount with broad rights across all namespaces
Follow-up questions
- →How would you audit for over-broad bindings across the cluster?
- →What stops a namespaced RoleBinding from ever exposing cluster-scoped objects?
SeniorDesignOccasionalA security review flags that Kubernetes Secrets in your cluster are stored in plaintext-equivalent form and that several are baked into container images and Pod env vars. Requirements: credentials must be encrypted at rest, must not appear in images or in kubectl describe output, must be rotatable without rebuilding images, and access must be auditable and least-privilege. Design a secrets posture for the cluster — how you enable encryption at rest, whether and how you integrate an external secrets manager, how workloads consume secrets safely, and how you limit who can read them. Explain why 'it is a Secret, so it is encrypted' is wrong, and the trade-offs of an external store versus native Secrets.
A security review flags that Kubernetes Secrets in your cluster are stored in plaintext-equivalent form and that several are baked into container images and Pod env vars. Requirements: credentials must be encrypted at rest, must not appear in images or in kubectl describe output, must be rotatable without rebuilding images, and access must be auditable and least-privilege. Design a secrets posture for the cluster — how you enable encryption at rest, whether and how you integrate an external secrets manager, how workloads consume secrets safely, and how you limit who can read them. Explain why 'it is a Secret, so it is encrypted' is wrong, and the trade-offs of an external store versus native Secrets.
Enable etcd encryption at rest via an EncryptionConfiguration, ideally a KMS provider, since a native Secret is only base64-encoded. Source credentials from an external manager via a CSI driver, not images or env, so they rotate without rebuilds. Restrict reads with tight, auditable RBAC.
Common mistakes
- ✗Assuming a Secret is encrypted at rest without an EncryptionConfiguration
- ✗Baking credentials into images or Pod env vars
- ✗Granting broad
geton Secrets instead of least-privilege reads
Follow-up questions
- →What are the trade-offs of an external store versus native encrypted Secrets?
- →How does a KMS (key-management-service) provider differ from the default aescbc encryption?
