Getting Permission or Asking Forgiveness?
summary
Kubernetes permissions map to roles and rolebindings tied to resources, not to file-like owners, so access requires traversing roles → bindings → subjects; RBAC has many verbs (get/list/watch/create/update/delete) and clusterwide equivalents. Demo runs a pod under a superpower service account token that switches from anonymous denied to full API access (could list or delete cluster objects). A small GitHub proof‑of‑concept tool that answers “who can” queries exists to reverse these mappings and it works for auditing.
AI-written summary · about
chapters (5)
- 0:00Start
- 3:24Files have owners and permissions
- 11:49Many Cluster RoleBindings to start with
- 14:29Permissions are additive
- 20:30Can I create a pod?
related talks
35mRBAC to the Future: Untangling Authorization in Kubernetes
33mHow the Basics Of Kubernetes Auth Scale For Organizations
35mSmarter Kubernetes Access Control: A Simpler Approach to Auth
32mStop giving root access and start securing your Kubernetes clusters instead
31mKubernetes RBAC Security: A Practical Overview
40mEffective RBAC
49mCompromising Kubernetes Cluster by Exploiting RBAC Permissions
34mFine-Grained Permissions in K8s: What’s Missing, and How to Fix That