Container & Kubernetes Security
Docker and Kubernetes hardening — container escape, root/privileged risk, minimal images, RBAC, NetworkPolicy, Pod Security Standards, secrets, service-account tokens, supply chain, runtime detection and image scanning.
13 questions
MiddleDesignVery commonYour platform runs 40 services in one namespace per environment, on a Calico CNI that enforces NetworkPolicy. Pod-to-pod traffic is unrestricted today — any pod reaches any other pod and the cluster-internal database, and a review flagged that a single compromised front-end pod could talk to payments and to the database directly. Design east-west segmentation with NetworkPolicy under these constraints — with no policy present the default is allow-all; production must not break during rollout; DNS resolution must keep working; three services legitimately need cross-namespace access to a shared cache; and the platform team wants the result reviewable in Git. Describe the policy model you would apply, the order you would roll it out, and how you would verify it.
Your platform runs 40 services in one namespace per environment, on a Calico CNI that enforces NetworkPolicy. Pod-to-pod traffic is unrestricted today — any pod reaches any other pod and the cluster-internal database, and a review flagged that a single compromised front-end pod could talk to payments and to the database directly. Design east-west segmentation with NetworkPolicy under these constraints — with no policy present the default is allow-all; production must not break during rollout; DNS resolution must keep working; three services legitimately need cross-namespace access to a shared cache; and the platform team wants the result reviewable in Git. Describe the policy model you would apply, the order you would roll it out, and how you would verify it.
Set a deny-all ingress and egress baseline per namespace, then allow only named label-to-label pairs plus egress to kube-dns. Roll out one namespace at a time, observing traffic first, keep the policies in Git beside the workloads, and verify with connectivity tests both ways.
Common mistakes
- ✗Assuming pods are isolated by default when no NetworkPolicy exists
- ✗Writing ingress rules only and leaving egress, including DNS, unconsidered
- ✗Enforcing a default-deny baseline everywhere at once without observing traffic
Follow-up questions
- →How would you discover the real traffic pairs before enforcing anything?
- →What breaks first if egress to cluster DNS is not explicitly allowed?
MiddleTheoryVery commonWhat do the Pod Security Standards define, and how does admission control enforce them?
What do the Pod Security Standards define, and how does admission control enforce them?
They are three profiles — privileged, baseline and restricted — stating which pod security fields are allowed. Pod Security Admission applies a chosen profile per namespace in enforce, audit or warn mode, so a violating pod is rejected at creation.
Common mistakes
- ✗Treating the standards as a report card rather than an admission-time decision
- ✗Assuming the restricted profile is applied cluster-wide by default
- ✗Skipping audit or warn mode and enforcing straight into a live namespace
Follow-up questions
- →How would you move an existing namespace from baseline to restricted safely?
- →What would you use when a policy need exceeds what the three profiles express?
JuniorTheoryCommonWhat does container image scanning find, and why is scanning once not enough?
What does container image scanning find, and why is scanning once not enough?
A scanner matches the packages and libraries baked into an image against vulnerability feeds and reports known CVEs by severity. Feeds grow after the build, so a clean image can be vulnerable tomorrow — rescan stored images and rebuild on a fresh base.
Common mistakes
- ✗Treating a green scan at build time as permanent proof the image is clean
- ✗Believing a scanner detects malicious application logic rather than known CVEs
- ✗Scanning only the base OS packages and ignoring language dependencies
Follow-up questions
- →Why does pinning a base image by digest change how you plan rescanning?
- →How would you prioritise a long CVE list so the work stays finishable?
JuniorTheoryCommonHow do minimal or distroless base images reduce a container's attack surface?
How do minimal or distroless base images reduce a container's attack surface?
Every binary in an image is code an attacker can reuse. A distroless or minimal base ships no shell, package manager or debug tools, so tooling for the next step is absent, and far fewer packages need patching or raise CVE alerts.
Common mistakes
- ✗Thinking a small base image is only a build-size or pull-speed optimisation
- ✗Assuming a distroless image removes the need to scan application dependencies
- ✗Keeping a shell and package manager in production images for convenience
Follow-up questions
- →How do you debug a running distroless container without adding a shell to it?
- →Why does a smaller base also shrink the vulnerability backlog you must triage?
JuniorTheoryCommonWhy should a container run as a non-root user with a read-only root filesystem?
Why should a container run as a non-root user with a read-only root filesystem?
Container root is host root filtered only by namespaces, so a compromised process starts far more powerful than it needs. An unprivileged UID and a read-only root filesystem block package installs, binary drops and config tampering.
Common mistakes
- ✗Believing the runtime remaps container root to an unprivileged host user by default
- ✗Treating a read-only root filesystem as a storage tweak rather than a control
- ✗Assuming network isolation compensates for a process running as root
Follow-up questions
- →Where do you put the paths an application genuinely needs to write?
- →How would you detect images that still declare a root user?
MiddleTheoryCommonHow does Kubernetes RBAC work, and why are cluster-admin and wildcard verbs risky?
How does Kubernetes RBAC work, and why are cluster-admin and wildcard verbs risky?
A Role or ClusterRole lists verbs on resource types, and a binding attaches it to a user, group or ServiceAccount. Least privilege means namespaced Roles naming explicit verbs. A wildcard or cluster-admin grants everything cluster-wide, including reading every Secret.
Common mistakes
- ✗Granting cluster-admin to a workload ServiceAccount to unblock a deployment
- ✗Thinking a ClusterRole cannot expose namespaced objects such as Secrets
- ✗Using wildcard verbs or resources because the exact set is tedious to enumerate
Follow-up questions
- →How would you review existing bindings to find over-privileged ServiceAccounts?
- →Why does the verb list matter as much as the resource list in a Role?
MiddleDesignCommonA service needs a database password, a third-party API key and a TLS private key. Today the password is baked into the image, the API key is a plain environment variable in a Deployment manifest committed to Git, and the TLS key sits in a Kubernetes Secret in a cluster with no encryption at rest. Design the secret handling under these constraints — the managed cluster offers a KMS provider; the organisation already runs an external secret store; developers must not be able to read production secrets; rotation must not require rebuilding the image; and manifests stay in Git. Describe where each secret should live, how it reaches the pod, and what you would put in place so that a leaked manifest is not a leaked secret.
A service needs a database password, a third-party API key and a TLS private key. Today the password is baked into the image, the API key is a plain environment variable in a Deployment manifest committed to Git, and the TLS key sits in a Kubernetes Secret in a cluster with no encryption at rest. Design the secret handling under these constraints — the managed cluster offers a KMS provider; the organisation already runs an external secret store; developers must not be able to read production secrets; rotation must not require rebuilding the image; and manifests stay in Git. Describe where each secret should live, how it reaches the pod, and what you would put in place so that a leaked manifest is not a leaked secret.
Take the values out of the image and out of Git — a Kubernetes Secret is base64-encoded, not encrypted. Turn on etcd encryption at rest with the KMS provider, sync values in from the external store, project them as mounted files rather than environment variables, and gate reads with RBAC.
Common mistakes
- ✗Believing the base64 encoding of a Kubernetes Secret provides encryption
- ✗Leaving secret material in image layers and rotating it by rebuilding
- ✗Delivering secrets as environment variables that leak into logs and crash dumps
Follow-up questions
- →Why does etcd encryption at rest not remove the need for RBAC on Secrets?
- →What changes in your design if the same secret is needed by ten namespaces?
JuniorTheoryOccasionalWhy is the kube-apiserver the centre of Kubernetes security, and what protects it?
Why is the kube-apiserver the centre of Kubernetes security, and what protects it?
All cluster state is reached through the apiserver, which runs authentication, then RBAC authorization, then admission on every call. Protect it by disabling anonymous access, keeping it off the public internet, and encrypting etcd.
Common mistakes
- ✗Thinking components talk to etcd directly instead of through the apiserver
- ✗Assuming anonymous apiserver access is disabled by default in every distribution
- ✗Forgetting that etcd holds every Secret in the cluster in plain form
Follow-up questions
- →Why is direct read access to etcd equivalent to reading every Secret?
- →What does the admission stage add that authorization alone cannot?
MiddleTheoryOccasionalHow do dropped capabilities, syscall filter seccomp and LSM profile AppArmor harden a container?
How do dropped capabilities, syscall filter seccomp and LSM profile AppArmor harden a container?
Containers share the host kernel, so that surface is what an escape must cross. Dropping all capabilities and adding back only what is needed removes privileged operations, seccomp narrows the syscalls a process may issue, and AppArmor confines its file access.
Common mistakes
- ✗Believing each container runs on its own kernel rather than the shared host kernel
- ✗Treating capabilities, seccomp and AppArmor as interchangeable duplicates
- ✗Adding capabilities back wholesale instead of naming the few that are needed
Follow-up questions
- →How would you derive a seccomp profile for an application you did not write?
- →Which capability would you expect a plain HTTP service to need, and why?
MiddleTheoryOccasionalWhat does container runtime security detect that build-time image scanning cannot?
What does container runtime security detect that build-time image scanning cannot?
Scanning describes an image before it runs; runtime tooling watches live syscalls and process events on the node. It flags a shell spawned inside a container, an unexpected exec, writes to sensitive host paths or new outbound connections — behaviour no scan predicts.
Common mistakes
- ✗Expecting runtime tooling to report the same CVE list a scanner already produced
- ✗Believing syscall activity inside a container is invisible from the node
- ✗Treating runtime detection as a replacement for build-time gates and admission
Follow-up questions
- →Which container behaviours would you treat as a high-confidence alert, and why?
- →How would you keep such rules from drowning the on-call in false positives?
MiddleTheoryOccasionalWhy disable ServiceAccount token automounting, and what does a leaked token allow?
Why disable ServiceAccount token automounting, and what does a leaked token allow?
By default a pod gets its ServiceAccount token mounted, so any code execution inside it becomes authenticated API access with that account's rights. Set automountServiceAccountToken to false unless the pod calls the API, and bind each ServiceAccount narrowly.
Common mistakes
- ✗Thinking a mounted token is bound to the pod and cannot be used elsewhere
- ✗Leaving automount enabled for workloads that never call the Kubernetes API
- ✗Assuming a token only authenticates and carries no authorization with it
Follow-up questions
- →How do bound, time-limited projected tokens change the impact of a leak?
- →What would you check to find pods mounting a token they never use?
SeniorTheoryOccasionalWhy is a container not the same security boundary as a virtual machine?
Why is a container not the same security boundary as a virtual machine?
A container is host processes separated by namespaces and cgroups over one shared kernel, so a kernel flaw or permissive setting reaches the node. Privileged mode, hostPath, hostPID and a docker socket mount are node-level access; untrusted tenants need VM isolation.
Common mistakes
- ✗Treating a container as a hypervisor-grade boundary for untrusted tenants
- ✗Believing each container has its own kernel rather than sharing the host one
- ✗Reading privileged mode or a host mount as a resource setting rather than access
Follow-up questions
- →Which workloads would you insist run on VM-backed isolation, and on what basis?
- →How would you find pods in a cluster that already carry node-level settings?
SeniorDebuggingOccasionalA kube audit entry shows a front-end ServiceAccount listing secrets cluster-wide — find the RBAC gap
A kube audit entry shows a front-end ServiceAccount listing secrets cluster-wide — find the RBAC gap
A ClusterRoleBinding to a role with a wildcard resource lets a namespaced front-end read every Secret in the cluster. Replace it with a namespaced Role naming that one ConfigMap and the verbs needed, bind it with a RoleBinding, and turn token automounting off.
Open full question →Common mistakes
- ✗Reading a ClusterRoleBinding as if it were limited to one namespace
- ✗Assuming read-only verbs make an over-broad role harmless
- ✗Treating the audit log verbosity as the defect rather than the grant
Follow-up questions
- →How would you find every other binding in the cluster with the same shape?
- →What detection rule would you add so this pattern alerts next time?
