Step 01 of 06
Learn the concept
Least privilege appears twice. One version asks what Beacon may do to the Kubernetes API. The other asks which packets may reach or leave it. Attackers are famously willing to use either door.
The ideas this is made of
ServiceAccounts are workload identities
Every Pod runs as a ServiceAccount. If you do not name one, it uses the namespace's default ServiceAccount. That default identity is convenient and ambiguous. A named beacon ServiceAccount makes intent visible, gives RBAC bindings a narrow subject, and prevents future workloads in the namespace from inheriting permissions meant for Beacon.
Roles are namespaced; ClusterRoles can cross namespaces
A Role grants verbs on resources inside one namespace. A ClusterRole can grant cluster-wide resources or be reused across namespaces. RoleBinding connects a subject, such as a ServiceAccount, to a Role or ClusterRole. Beacon does not need to mutate the Kubernetes API to serve HTTP, so its Role should be tiny or absent until a real API need exists.
`kubectl auth can-i` tests the identity, not your optimism
RBAC is easy to overgrant because YAML looks harmless. kubectl auth can-i list pods --as=system:serviceaccount:beacon:beacon -n beacon asks the API authorizer what that identity can do. Use it before and after bindings. A good answer for Beacon listing Pods is usually no. Services rarely need to inspect their neighbors.
NetworkPolicy defaults to allow-all until you say otherwise
In namespaces with a policy-capable CNI, Pods can usually receive and send traffic freely until NetworkPolicies select them. A default-deny ingress policy changes the baseline: nothing can call selected Pods unless a later policy allows it. Egress needs special care for Beacon because Beacon's job is making outbound HTTP and HTTPS checks to the internet.
badge: may enter records room
firewall: may call address 203.0.113.8
one stolen badge does not open every network pathRBAC and NetworkPolicy are orthogonal. One limits API authority; the other limits packets. You want both because attackers enjoy whichever one you skipped.
RBAC and NetworkPolicy
| Control | Protects | Common mistake |
|---|---|---|
ServiceAccount | Workload identity | Using |
Role | Namespaced API access | Granting |
RoleBinding | Who receives role | Binding whole groups |
Ingress policy | Inbound traffic | Forgetting DNS/controller callers |
Egress policy | Outbound traffic | Blocking the app's purpose |
What these are called on the job
ServiceAccount — The Kubernetes identity assigned to Pods for API authentication.
Role — Namespaced RBAC permissions over resources and verbs.
RoleBinding — A binding from users, groups or ServiceAccounts to a Role or ClusterRole.
NetworkPolicy — A namespaced network rule selecting Pods and allowing specific ingress or egress flows.