Kubernetes Auth and Access Control
summary
Kubernetes authentication and authorization detail actual mechanisms: x.509 client certs and bearer tokens become usernames and groups, service accounts are cluster-managed JWTs mounted into pods, and RBAC is enforced via roles, rolebindings and clusterroles with built-in escalation prevention. Demo shows Dex OpenID Connect issuing JWT ID tokens federating GitHub teams into groups and successfully authenticating to the API server. Notes versions: default bootstrap roles land around 1.5–1.6 and authorization defaults to deny-all unless configured.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:44Why a talk about auth?
- 3:10API server auth: request flow
- 9:18Users in Kubernetes: service accounts
- 18:09Roles vs Bindings
- 19:01RBAC: Role Bindings
- 19:46Cluster Roles vs. Roles
- 20:54Cluster RoleBindings vs. RoleBindings
- 22:31RBAC: Cluster Roles vs Roles
- 25:50Authorization and RBAC: 1.5
- 28:00Authorization: other plugins
- 31:38OpenID Connect Token Response
related talks
33mBeyond Cluster-Admin: Getting Started with Kubernetes Users and Permissions
33mHow the Basics Of Kubernetes Auth Scale For Organizations
32mStop giving root access and start securing your Kubernetes clusters instead
59mKubernetes access control in the enterprise
45mBeyond cluster-admin: Getting Started with Kubernetes Users and Permissions
35mRBAC to the Future: Untangling Authorization in Kubernetes
39mDeep Dive: Auth SIG
28mWhat Do You Mean K8s Doesn't Have Users? How Do I Manage User Access Then?