Transitioning from ABAC to RBAC in Kubernetes

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. To smooth the transition from ABAC to RBAC, you can create Kubernetes 1.6 clusters with both [ABAC and RBAC authorizers](/docs/reference/access-authn-authz/rbac/#parallel-authorizers) enabled. When both ABAC and RBAC are enabled, authorization for a resource is granted if either authorization policy grants access. However, under that configuration the most permissive authorizer is used and it will not be possible to use RBAC to fully control permissions. At this point, RBAC is complete enough that ABAC support should be considered deprecated going forward. It will still remain in Kubernetes for the foreseeable future but development attention is focused on RBAC. Two different talks at the at the Google Cloud Next conference touched on RBAC related changes in Kubernetes 1.6, jump to the relevant parts [here](https://www.youtube.com/watch?v=Cd4JU7qzYbE#t=8m01s) and [here](https://www.youtube.com/watch?v=18P7cFc6nTU#t=41m06s). For more detailed information about using RBAC in Kubernetes 1.6 read the full [RBAC documentation](/docs/reference/access-authn-authz/rbac/). **Get Involved** If you’d like to contribute or simply help provide feedback and drive the roadmap, [join our community](https://github.com/kubernetes/community#kubernetes-community). Specifically interested in security and RBAC related conversation, participate through one of these channels: - Chat with us on the Kubernetes [Slack sig-auth channel](https://kubernetes.slack.com/messages/sig-auth/) - Join the biweekly [SIG-Auth meetings](https://github.com/kubernetes/community/blob/master/sig-auth/README.md) on Wednesday at 11:00 AM PT Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.io/blog/2017/03/five-days-of-kubernetes-1-6). - Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) - Join the community portal for advocates on [K8sPort](http://k8sport.org/) - Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes) - Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates - Connect with the community on [Slack](http://slack.k8s.io/) - [Download](http://get.k8s.io/) Kubernetes

Transitioning from ABAC to RBAC involves scoping down default permissions, potentially impacting service accounts. To ease the transition, Kubernetes 1.6 allows enabling both ABAC and RBAC, but the most permissive authorizer takes precedence. ABAC is now considered deprecated, with development focused on RBAC. The community encourages engagement through Slack, SIG-Auth meetings, and other channels for feedback and contribution.