Role Based Access Control is how Kubernetes limits what users (or service accounts) can perform what actions. For example, we might say that Jason can deploy pods in a particular namespace, or that Jason is an administrator. It is worth noting that you can deploy Kubernetes with RBAC disabled, but this is not recommended.
At its most basic level, you define roles and then bind those roles to particular users, groups, or service accounts.
Some roles are just relevant for a particular namespace in Kubernetes, and others are relevant for all namespaces. We call these Roles and ClusterRoles, respectively. ClusterRoles are global whereas Roles are relevant just for a particular namespace. Broadly, roles have a list of APIs and verbs, such as the ability to read pods or the ability to list pods.
Here is an example cluster role from the official documentation:
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: aggregate-cron-tabs-view labels: # Add these permissions to the "view" default role. rbac.authorization.k8s.io/aggregate-to-view: "true" rules: - apiGroups: ["stable.example.com"] resources: ["crontabs"] verbs: ["get", "list", "watch"]
Roles must then be binded to a particular user, group, or service account through the use of a RoleBinding or ClusterRoleBinding.
apiVersion: rbac.authorization.k8s.io/v1 # This role binding allows "jane" to read pods in the "default" namespace. # You need to already have a Role named "pod-reader" in that namespace. kind: RoleBinding metadata: name: read-pods namespace: default subjects: # You can specify more than one "subject" - kind: User name: jane # "name" is case sensitive apiGroup: rbac.authorization.k8s.io roleRef: # "roleRef" specifies the binding to a Role / ClusterRole kind: Role #this must be Role or ClusterRole name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io
Thus far, we have talked about how a user, group, or service account can be binded to a role, and this role then confers upon them the rights to perform certain actions. I bet you have been thinking – where do the users, groups, and service accounts come from? And how do these authenticate with the Kubernetes API?
Users and groups do not ostensibly *live* inside of Kubernetes, but rather you can authenticate as a user or group and then, upon authenticating, you can do anything that that user/group is allowed to do.
Kubernetes supports several methods of authentication, but for our purposes, I want to focus on one of the more common – X509 Client Certificates. When using certificates, you can generate a certificate using openssl and then import it into Kubernetes in what is called a Certificate object.
This certificate would be stored in Kubernetes and then associated with a list of groups or users. Refer to the Kubernetes documentation for more information. In most cases, doing this manually is unnecessary if you are using a managed kubernetes service such as AKS, EKS, GKS, or Rancher because they have tooling that does this for you automatically.
Built in Roles
There are default roles you can bind to in a small organization, such as cluster-admin, admin, edit, or view roles. You should be cautious with giving users or services too many privileges as even the view role could be used to gather intelligence to run exploits against. There are also many others (for more information, refer to the linked documentation).
We recommend you use RBAC and setup individual certificates for each user, granting them the minimal amount of access that they need to perform their job function. This follows the principle of least privileges, which reduces your attack surface and prevents users from accidentally causing harm. Also, if you have any compliance requirements (HIPAA, SOC 1 or SOC 2, etc) chances are it is required anyways.
If you use managed Kubernetes services like AKS, EKS, GKS, or Rancher, chances are they have some kind of identity provider integration (such as microsoft active directory) and a set of command line tools for users to authenticate. Under the hood, these tools will authenticate a user, create a certificate for them (typically short lived) in Kubernetes, and then associate that certificate with the appropriate groups which can then be bound to the appropriate roles or cluster roles.