Container & Kubernetes Security

A virtual machine boots its own guest kernel behind a hypervisor. A container is an ordinary Linux process on the host's shared kernel, isolated by namespaces, cgroups, capabilities and seccomp. Removing those features, for example with privileged mode, weakens the boundary between container and host.

As an administrator, run kubectl auth can-i --list -n <namespace> --as=system:serviceaccount:<namespace>:<name> to list its permissions, or ask a single question such as kubectl auth can-i get secrets with the same --as flag. The API server answers yes or no without needing the account's token.

They are three built-in profiles: privileged, baseline and restricted. Pod Security Admission enforces them per namespace through labels such as pod-security.kubernetes.io/enforce=restricted. Pods that break the profile, for example privileged containers or containers running as root, are rejected at admission before they are stored.

Not by default in every setup. Secret values in the API are only base64-encoded, which anyone can decode. Protect them with strict RBAC on the secrets resource, encryption at rest for etcd, protected backups, or an external secret store.

The API server accepts NetworkPolicy objects regardless of whether anything enforces them. Enforcement is done by the cluster's network plugin, and some plugins do not support it. Always prove a policy with a negative connection test, such as a request that should time out.

Create a disposable cluster on your own laptop with kind or minikube, confirm with kubectl config current-context that you are in the lab, run your tests there, and delete the cluster afterwards. Only test systems you own or are explicitly authorised in writing to test.