Container and Kubernetes Security, Interview Questions.

VMs each run their own kernel behind a hypervisor, so isolation is strong. Containers share the host kernel and are isolated with namespaces and cgroups, so a kernel flaw or misconfiguration can affect every container on the host. Containers are lighter, but the isolation boundary is weaker.

Namespaces limit what a process can see (PIDs, network, mounts, users). Cgroups limit what it can use (CPU, memory, I/O). Together with capabilities, seccomp and LSMs they form container isolation.

Use minimal trusted base images, pin versions or digests, scan for vulnerabilities, keep secrets out of layers, run as a non-root user, use multi-stage builds so build tools are not shipped, and sign images.

FROM python:3.12-slim AS base
RUN useradd --create-home --uid 10001 app
WORKDIR /app
COPY --chown=app:app requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY --chown=app:app . .
USER 10001
CMD ["python", "main.py"]

If an attacker escapes the application, root inside the container maps to powerful access and widens escape options. A non-root user, dropped capabilities and a read-only filesystem limit what a compromise can do.

A container run with nearly all host capabilities and device access. It removes most isolation, so a compromise is close to host compromise. Avoid it, and block it with admission policy.

Objects for sensitive values. By default they are only base64-encoded in etcd, not encrypted. Enable encryption at rest (with a KMS provider), restrict RBAC access, and consider an external secrets manager.

RBAC grants verbs on resources through Roles and ClusterRoles bound to subjects. Mistakes: cluster-admin for apps, wildcard rules, broad access to Secrets, permission to create pods or exec, and default service account tokens mounted everywhere. Use namespaced roles, review bindings and disable token automount when unneeded.

Three profiles enforced by the built-in Pod Security Admission: privileged (unrestricted), baseline (blocks known privilege escalations) and restricted (hardened best practice). Apply per namespace in enforce, audit or warn modes.

Run as non-root, block privilege escalation, drop all capabilities, use a read-only root filesystem and the runtime default seccomp profile.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

They select pods and define allowed ingress and egress. By default pods can talk to each other freely. Start with a default-deny policy per namespace and then allow needed flows. The CNI plugin must enforce policies, otherwise they do nothing.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

It intercepts API requests after authentication and authorisation. Validating controllers reject non-compliant objects and mutating ones modify them. Policy engines such as OPA Gatekeeper and Kyverno use this to enforce rules like no privileged pods, allowed registries, and required signatures.

Restrict API server access to private networks, require strong authentication (OIDC) and RBAC, enable audit logging, protect and encrypt etcd, rotate certificates, use managed control planes when possible, and keep versions patched.

Detecting behaviour while containers run: unexpected processes, shells in containers, writes to sensitive paths, outbound connections, and privilege changes. eBPF-based tools such as Falco and Tetragon watch syscalls and alert or block.

Build in a trusted pipeline, scan images and dependencies, produce SBOMs, sign images (for example with Sigstore cosign) and verify signatures at admission, pull only from approved registries, and use digests instead of mutable tags.

The kubelet runs pods on each node. An exposed or unauthenticated kubelet API can allow executing commands in pods. Disable anonymous auth, require authorisation, and keep the port off public networks.

Privileged mode, host path mounts of sensitive directories, mounted container runtime sockets, excess capabilities, host namespaces (hostPID, hostNetwork), and kernel or runtime vulnerabilities. Defence is to remove those options, enforce Pod Security restricted, use sandboxed runtimes (gVisor, Kata) for untrusted workloads, and patch nodes.

Namespaces plus RBAC, resource quotas, network policies and Pod Security give soft isolation. For hostile tenants use separate clusters or node pools with sandboxed runtimes. Isolate secrets, ingress and observability data per tenant.

A mesh issues each workload an identity and encrypts and authenticates service-to-service traffic with mutual TLS, enabling identity-based authorisation policies rather than IP rules. It does not replace application authorisation, and it adds operational complexity.

Runtime alerts for shells and unexpected binaries, unusual egress (mining pools, command servers), service account token use from new places in audit logs, access to the metadata endpoint, new pods or daemonsets, and resource spikes. Correlate cluster audit logs with node and network telemetry.

Anyone with that access can start new privileged containers on the host, effectively owning the node. Never mount it in application pods, and use rootless or daemonless build tools in CI.

Review chart sources, pin versions, scan templates and rendered manifests with policy checks, sign charts, protect the Git repository and the GitOps controller's credentials (it is effectively cluster admin), and require pull request review. Secrets use sealed or external secret operators.

Isolate with a deny network policy and cordon the node if needed, capture evidence (pod spec, image, logs, node data), identify the entry point (vulnerable app, exposed dashboard, leaked credentials), review service account permissions and audit logs for lateral actions, redeploy from a clean image, rotate secrets, and add admission and runtime controls.

Focus on exploitable, reachable and fixable issues in packages actually used, internet-exposed services, and known exploited CVEs. Move to a smaller base image to remove most noise, rebuild regularly, and set policy thresholds for critical findings with exceptions tracked.

Offer namespaced roles with deploy permissions through GitOps so humans rarely need direct access, and break-glass elevation with approval and audit for emergencies.

Remove the exposure, review access logs and audit logs for activity, rotate tokens and secrets reachable by the dashboard's account, check for new workloads and persistence, and rebuild if compromise is likely. Prefer access through authenticated proxies or no dashboard at all.