What you need to know about Kubernetes RBAC

Managing access to resources is an essential part of ensuring the reliability, security, and efficiency of any infrastructure, but can quickly get complicated to manage. With Kubernetes, attribute-based access control (ABAC) is very powerful but complex, while role-based access control (RBAC) makes it easier to manage permissions using kubectl and the Kubernetes API directly. This post shares how to get started with RBAC and some best practices to adopt.

RBAC vs ABAC

RBAC made beta release with Kubernetes 1.6 and general availability with 1.8. A fundamental building block of Kubernetes, RBAC is an authorization mechanism for controlling how the Kubernetes API is accessed using permissions.

RBAC is now preferred over ABAC, which is difficult to manage and understand. ABAC also requires SSH and root access to make authorization policy changes.

Resource management can be delegated using RBAC without giving away SSH access to the Cluster Master VM and permission policies can be configured using kubectl or the Kubernetes API itself.

RBAC resources

Using RBAC, Authorizations can be given using a set of permissions that can be limited within a namespace or the entire cluster. To do this, you can define A set of permission is called a Role, which is defined within a namespace. If you want A role that is cluster-wide, this is defined as a ClusterRole.

Below, you can see an example of a role definition:

Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Like other Kubernetes resources, a role definition contains kind, apiVersion, and metadata, but with the addition of rules.

For the rules key, you will define how your permissions will work. You can specify what resources within apiGroup(s) are permitted and how they can be accessed using verbs (including create, delete, deletecollection, get, list, patch, update, and watch). The apiGroups key defines the location in the API where the resources are found. If you provide an empty value in this list, it means the core API group.

ClusterRole

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

The major difference in the definition for a ClusterRole is the absence of a namespace, because the permissions defined here are cluster-scoped. However, when referenced by a RoleBinding, a ClusterRole can be used to grant permissions to namespaced resources defined in the ClusterRole role within the RoleBinding’s namespace.

RoleBinding and ClusterRoleBinding

A RoleBinding allows you to associate a Role with a user or list of users. This grants the Role permissions to the users. The user(s) are defined under subjects, and the Role association under role references (roleRef). For example:

RoleBinding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: abu
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Best practices

Applying the principle of least privileges is crucial, as it reduces exposure and vulnerability. A few of the essential best practices include:

• Be specific with the resources you are granting access to and the verbs being used; avoid wild cards
• Use Roles instead of Cluster Roles where possible
• Only give permissions required for the specific tasks to be performed by a user and nothing more
• Create and use service accounts for processes and services like Tiller that require permission instead of using the default service accounts

GitLab + RBAC

Currently, integrating GitLab with a Kubernetes cluster with RBAC enabled is not supported. You will need to enable and use the legacy ABAC mechanism (see the documentation here). RBAC will be supported in a future release. This affects GitLab.com and all self-managed versions of GitLab.

Learn more

• Controlling access
• Authorization
• RBAC
• RBAC and TLS certificates