Kubernetes Security

Both define a set of permissions — verbs on resources — but differ in scope. A Role is namespaced: it only grants access to resources within its namespace. A ClusterRole is cluster-wide and can grant access to cluster-scoped resources like nodes, or to namespaced resources across all namespaces. The subtlety is the binding: a ClusterRole referenced by a RoleBinding applies only within that binding's namespace, which is how you define one reusable permission set — say "secret-reader" — and grant it per-namespace. You use a Role for app-team permissions scoped to their namespace, and a ClusterRole for platform-level access or for reusable permission templates bound per namespace.

By default every pod gets its service account's token mounted into the filesystem, and that token can call the Kubernetes API with whatever RBAC the service account has. If the pod is compromised — say via an app RCE — the attacker immediately has that token and can use it against the API server to escalate: list secrets, create pods, or exec into others, depending on the SA's permissions. So an over-permissioned service account plus automounting turns a single app compromise into cluster escalation. The mitigations are to set automountServiceAccountToken false on pods that don't need API access, give each workload its own least-privilege service account, and use short-lived projected tokens. It's the Kubernetes equivalent of stealing the pod's identity.

A privileged container runs with all Linux capabilities and access to host devices, effectively dropping the isolation between container and host. With that, an attacker inside the container can see the host's block devices under /dev, mount the host root filesystem, and chroot into it — now operating as root on the node. They could also load kernel modules or write to host paths to establish persistence. The root reason it works is that a container is just an isolated process on the shared host kernel, and privileged removes the restrictions that kept it contained. The defense is never running privileged in production, enforced by Pod Security Standards restricted and an admission policy that rejects privileged pods.

Defense in depth. At the workload level, set the securityContext with runAsNonRoot true and a non-zero runAsUser, drop all capabilities, readOnlyRootFilesystem, and allowPrivilegeEscalation false. But individual specs get forgotten, so I enforce it at the cluster level: apply the Pod Security Standards "restricted" profile to production namespaces via the built-in Pod Security admission, which rejects pods that run as root or request privileges. For richer rules I'd add a policy engine — Kyverno or OPA/Gatekeeper — to validate and even mutate specs at admission. And I'd bake non-root USER into the images themselves. The principle is to make root the rejected exception, enforced by admission control, not left to each developer.

Both are policy engines that run as admission controllers to validate or mutate Kubernetes resources, enforcing policy-as-code. The main difference is the language and ergonomics. OPA/Gatekeeper uses Rego, a powerful general-purpose policy language that's more expressive but has a learning curve, and OPA can be used beyond Kubernetes. Kyverno is Kubernetes-native — policies are written as YAML CRDs that look like Kubernetes resources, so there's no new language to learn, and it does validation, mutation, and generation. In practice teams pick Kyverno for approachability and K8s-only use, and Gatekeeper/Rego when they want maximum expressiveness or a policy language shared across systems.

I treat it as a potential active compromise, because production containers shouldn't have interactive shells — they run one defined process. First I scope without tipping off: identify the pod, image, and node, and pull what the shell did from Falco and the audit logs. Then I think in the three escalation ladders — did it try to reach the pod's cloud credentials or the node metadata, did it use the service account token against the API server, and is the pod privileged enough to escape to the node. For containment I isolate the pod with a deny-all NetworkPolicy and cordon the node rather than immediately deleting the pod, so I preserve evidence; capture what I can; then revoke the pod's identity and, if it may have reached the node or API, treat those as compromised too. Afterward, eradicate by redeploying from a clean image and fixing how the shell got there. It's the EKS pod IR playbook.

Binary Authorization is an admission-time control that only allows container images meeting a policy to run — typically images that are signed and attested by trusted parties, from approved registries. At deploy time the admission controller verifies cryptographic signatures and attestations (via Sigstore/cosign) before the pod is scheduled, so an unsigned image, one from an untrusted source, or one that didn't pass required checks like a vulnerability scan is rejected. This closes a major supply-chain gap: it stops a tampered or rogue image — say one an attacker pushed to the registry — from silently running in the cluster, and it enforces that everything in production came through your trusted build and signing pipeline. It's the runtime enforcement of the "verify provenance" half of supply-chain security.

A Kubernetes Secret is only base64-encoded, not encrypted, and by default it's stored in etcd in plaintext — so anyone who can read the Secret object via the API, read etcd directly, or get an etcd backup has the cleartext. Three fixes, increasing in strength: first, enable etcd encryption-at-rest so the data is encrypted in the datastore and in backups; second, lock down RBAC so very few principals can get secrets, since broad "get secrets" is itself a major risk; and third, the strongest, keep secrets out of etcd entirely by sourcing them from an external manager like Vault or AWS Secrets Manager through the External Secrets Operator or the CSI Secrets Store driver, so the real secret is injected at runtime and never persisted by Kubernetes. The headline is that K8s Secrets are obfuscated, not encrypted.