RBAC Integration and Permissions Changes in Kubernetes

RBAC is now deeply integrated into Kubernetes and used by the system components to grant the permissions necessary for them to function. [System roles](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) are typically prefixed with system: so they can be easily recognized. ``` ➜ kubectl get clusterroles --namespace=kube-system NAME KIND admin ClusterRole.v1beta1.rbac.authorization.k8s.io cluster-admin ClusterRole.v1beta1.rbac.authorization.k8s.io edit ClusterRole.v1beta1.rbac.authorization.k8s.io kubelet-api-admin ClusterRole.v1beta1.rbac.authorization.k8s.io system:auth-delegator ClusterRole.v1beta1.rbac.authorization.k8s.io system:basic-user ClusterRole.v1beta1.rbac.authorization.k8s.io system:controller:attachdetach-controller ClusterRole.v1beta1.rbac.authorization.k8s.io system:controller:certificate-controller ClusterRole.v1beta1.rbac.authorization.k8s.io ... ``` The RBAC system roles have been expanded to cover the necessary permissions for running a Kubernetes cluster with RBAC only. During the permission translation from ABAC to RBAC, some of the permissions that were enabled by default in many deployments of ABAC authorized clusters were identified as unnecessarily broad and were [scoped down](/docs/reference/access-authn-authz/rbac/#upgrading-from-1-5) in RBAC. The area most likely to impact workloads on a cluster is the permissions available to service accounts. With the permissive ABAC configuration, requests from a pod using the pod mounted token to authenticate to the API server have broad authorization. As a concrete example, the curl command at the end of this sequence will return a JSON formatted result when ABAC is enabled and an error when only RBAC is enabled. ``` ➜ kubectl run nginx --image=nginx:latest ➜ kubectl exec -it $(kubectl get pods -o jsonpath='{.items[0].metadata.name}') bash ➜ apt-get update && apt-get install -y curl ➜ curl -ik \ -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \ https://kubernetes/api/v1/namespaces/default/pods ``` Any applications you run in your Kubernetes cluster that interact with the Kubernetes API have the potential to be affected by the permissions changes when transitioning from ABAC to RBAC.

RBAC is deeply integrated into Kubernetes for managing permissions, with system roles prefixed with 'system:'. Transitioning from ABAC to RBAC involves scoping down some overly broad permissions, especially those related to service accounts. Applications interacting with the Kubernetes API may be affected by these permission changes.