Cloud & Kubernetes Security
Kubernetes is not "just a container orchestrator" but a distributed system with its own control plane, a state store (etcd) and worker nodes. An attacker cares not about a single pod but about the path from any foothold to control over the whole cluster, and there are several such paths: the node network, exposed applications, the kube-api interface, and credentials. Cluster security is best studied precisely as an attack surface along these axes.
The beginner's trap is treating a pod as an isolated sandbox and kube-api as unreachable from inside. In reality a privileged pod with hostPath is nearly root on its node, anonymous access to kube-api or etcd hands over the whole cluster without a single password, and over-broad RBAC rights turn the compromise of one service into a takeover of the control plane. The full map is in the layer below.
Topic map
- The Kubernetes attack surface — the four axes of cluster takeover (infrastructure, applications, kube-api, credentials) and the defense along each.
Common traps
| Mistake | Consequence |
|---|---|
| Reducing cluster takeover to brute-forcing the dashboard | You miss faster paths via kube-api, etcd and RBAC |
| Treating a privileged pod as isolated like an ordinary one | A hostPath/privileged pod mounts the host FS and escapes to the node |
| Assuming Kubernetes blocks anonymous kube-api by default | In a bad config anonymous access hands over the control plane |
| Believing anonymous etcd exposes only metrics | etcd holds every cluster secret in cleartext once reachable |
| Handing out broad RBAC rights (exec, secrets, "*") | Compromise of one pod escalates to control over the cluster |
Interview relevance
The topic is asked to check whether you see a cluster as a system with trust boundaries rather than a set of isolated containers. A candidate who lists vectors by axis and names kube-api as the fastest path to control immediately gets ahead of one who talks only about "hacking the dashboard".
Typical checks:
- What the cluster attack surface consists of and why
kube-apiequals control over it. - Why a privileged pod is dangerous and how
hostPathleads to node compromise. - Why anonymous access to
etcdis as critical as tokube-api. - How over-broad
RBACrights turn a pod foothold into a cluster takeover.
Common wrong answer: "a pod is always isolated by the runtime and the control plane is unreachable from inside". In fact it is precisely in-cluster misconfigurations — privileged pods, broad RBAC, anonymous kube-api/etcd — that form the main escalation path up to the cluster level.