Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization.

RBAC consists of three key building blocks: Subject, API Resource, Operations(Verbs)*.Together, they connect API primitives and their allowed operations to the so-called subject which is a user, a group, or a ServiceAccount.

• Subject: The user or process that wants to access a resource.
• Resource: The Kubernetes API resource type e.g. a Deployment or node.
• Verb: The operation that can be executed on the resource e.g. creating a Pod, or deleting a Service.

Creating a Subject

user account, service account, or a group can use as subject.

User Accoutns

Authentication strategy	Description
X.509 client certificate	Uses an OpenSSL client certificate to authenticate.
Basic authentication	Uses username and password to authenticate.
Bearer tokens	Uses OpenID (a flavor of OAuth2) or webhooks as a way to authenticate.

Service Account

kubectl create serviceaccount build-bot # create sa
kubectl describe serviceaccount build-bot
kubectl get secrets

Assigning a Service Account to a Pod

kubectl run build-observer --image=alpine --restart=Never \
--serviceaccount=build-bot

or

apiVersion: v1
kind: Pod
metadata:
name: build-observer
spec:
serviceAccountName: build-bot
...

RBAC API Primitives

Within RBAC for Kubernetes, you have four primary resources:

• Roles

• ClusterRoles

• RoleBindings

• ClusterRoleBindings

• Role: The Role API primitive declares the API resources and their operations this rule should operate on.

• RoleBinding: The RoleBinding API primitive binds the Role to the subject(s). It is the glue for making the rules active.

Role and ClusterRole

Roles are permissions that you can give users, groups, and service accounts, and they are namespace scoped. ClusterRole is the same thing as a Role. The only difference is that it’s not namespace scoped.

A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs in.

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

ClusterRole, by contrast, is a non-namespaced resource. The resources have different names (Role and ClusterRole) because a Kubernetes object always has to be either namespaced or not namespaced; it can't be both.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing Secret
  # objects is "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

kubectl get roles # list roles
kubectl describe role read-only # show role details

RoleBinding and ClusterRoleBinding

A RoleBinding is a way that you tie/attach a Role to a user/group/service account. Just as with Roles and ClusterRoles, the only difference is that RoleBindings are namespace scoped and ClusterRoleBindings are not and can be used throughout the cluster.

The following RoleBinding takes the Role reader-pod and attaches it to the miketest service account.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: reader-pod
  namespace: ingress
subjects:
- kind: ServiceAccount
  name: miketest
  apiGroup: ""
roleRef:
  kind: Role
  name: reader
  apiGroup: rbac.authorization.k8s.io

the following ClusterRoleBinding will attach the miketest service account to the ClusterRole reader-cluster and reference the following ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pod-global
subjects:
- kind: ServiceAccount
name: miketest
apiGroup: ""
roleRef:
kind: ClusterRole
name: reader-cluster
apiGroup: rbac.authorization.k8s.io

Referring to resources

Referring to subjects

Aggregated ClusterRoles

Existing ClusterRoles can be aggregated to avoid having to redefine a new,composed set of rules that likely leads to duplication of instructions.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: list-pods
  namespace: rbac-example
  labels:
    rbac-pod-list: "true"
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: delete-services
  namespace: rbac-example
  labels:
    rbac-service-delete: "true"
rules:
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - delete

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pods-services-aggregation-rules
  namespace: rbac-example
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
    rbac-pod-list: "true"
  - matchLabels:
    rbac-service-delete: "true"
rules: []

Creating Role

$ kubectl create role read-only --verb=list,get,watch \
--resource=pods,deployments,services

or

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - services
  verbs:
  - list
  - get
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - list
  - get
  - watch

RoleBuinding

# Create
kubectl create rolebinding read-only-binding --role=read-only -
-user=johndoe

or

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-only-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: read-only
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: johndoe

kubectl get rolebindings # list role buinding
kubectl describe rolebinding read-only-binding # show detail rolebinding

Default User-Facing Roles

Default ClusterRole	Description
cluster-admin	Allows read- and write-access to resources across all namespaces.
admin	Allows read- and write-access to resources in namespace including Roles and RoleBindings.
edit	Allows read- and write-access to resources in namespace except Roles, and RoleBindings. Provides access to Secrets.
view	Allows read-only access to resources in namespace except Roles, RoleBindings, and Secrets.