Overview: Brian and Tyler talk about how Role-Based Access Control (RBAC) is implemented for Kubernetes.
Topic 1 – The concept of RBAC is best described as “Can ______ (noun) ______ (verb) on ______ (object) at ______ (location)?” where “noun” is a person/service, “verb” is an action, “object” is a function of the API, and “location” is proximity to a Kubernetes cluster.
Topic 2 – RBAC operates on the concept of Roles and RoleBindings, which map actors to actions, and those actors and actions are defined either globally or locally, and the actions are also defined globally or locally.
Topic 3 – RBAC can be manually defined, or enabled (by default) by an installer or distribution. It comes with a default set of Roles. Everything is done within the scope of a cluster.
Topic 4 – By default, the kube-scheduler, kube-controller-manager, and kube-proxy all have RBAC roles defined. Kubelets (node-level) don’t use RBAC by default, but have their own authorizer, which can then be combined with an RBAC authorizer.
Topic 5 – “Add-ons” (networking, monitoring, logging, etc.) can have RBAC defined in their manifests, or you can grant them access to their service account.
Topic 6 – “If the element needs to be something other than those default roles, or using default authorizer services, then CustomRoles can be created. Can use audit logs to track the needs of a specific add-on. Can use “audit2rbac” tool to views the logs and create custom RBAC roles.
Topic 7 – “Aggregate Roles” are now available in Kubernetes 1.9.