RBAC principle and usage

1.RBAC API resource object description

RBAC introduces four new top-level resource objects: Role, ClusterRole, RoleBinding and ClusterRoleBinding. These resource objects can be operated by kubectl or API calls.

1. Role

A Role is a collection of permissions. All permissions here are in the form of permission, and there is no rejection rule. In a namespace, a Role is defined by Role, and ClusterRole is used at the cluster level. A Role can only authorize resources within a namespace.

• The role defined in the following example has permission to read Pod:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: pod-reader
  namespace: namespace-test
rules:
  - apiGroups:
      - ""     # An empty string represents the core API Group
    resources:
      - "pods"
    verbs:
      - "get"
      - "list"
      - "watch"

# Or write:
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Parameter description in rules:

• apiGroup: list of supported API groups, such as: '', APIVersion: batch/v1, APIVersion: extensions:v1, apiVersion:apps/v1, etc
• resources: list of supported resource objects, such as pods, deployments, jobs, secrets, service, namespace, etc
• verbs: list of operation methods for resource objects, such as get, watch, list, delete, replace, patch, etc

2. Cluster role

In addition to the ability to manage resources in the namespace consistent with the role, the cluster role can also be used for the authorization of the following special elements because of its cluster level scope.

• Cluster wide resources, such as node

• A non resource path, such as / healthz

• Resources that contain all namespaces, such as pods

• The clusterrole in the following example allows users to access the secrets of any or all namespaces:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader  # ClusterRole is not limited to namespace, so the definition of namespace name is omitted
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

3. Role binding and cluster role binding

Role binding or cluster role binding is used to bind a role to a target. The binding target can be User, Group or ServiceAccount. Use RoleBinding to authorize a namespace and ClusterRoleBinding to authorize within the cluster.

RoleBinding can refer to Role for authorization. In the following example, RoleBinding will grant the Pod reader Role to user test in the namespace test namespace, allowing the test user to read the Pod in the namespace test namespace.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: namespace-test

subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding can also reference ClusterRole to authorize resource principals defined by ClusterRole in the same namespace. A common practice is that the Cluster Administrator pre defines a set of roles (clusterroles) for the cluster scope, and then reuses these clusterroles in multiple namespaces.

• The RoleBinding in the following example binds the cluster role secret reader, so that user dave can only read the secret in the development namespace:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development

subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

The roles in the cluster role binding can only be cluster roles, which are used for cluster level or effective authorization for all namespaces.

• The ClusterRoleBinding in the following example allows the user of the manager group to read the secret in any namespace

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

2. Reference method of resources

Most resources can be expressed by the string of their name, that is, the relative path of the URL in the Endpoint, such as pods. Then, some kubernetes APIs contain subordinate resources, such as the logs of Pod. The Endpoint of the Pod log is GET /api/v1/namespaces/{namespaces}/pods/{name}/logs.

Pod is a resource in a namespace, and logs is a subordinate resource. To be embodied in an RBAC role, you need to use slashes / to divide resources and subordinate resources.

• In the following example, authorization enables a role to read Pod and Pod logs at the same time, and resources can be configured as an array:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

　　
Resources can also be referenced by name (ResourceName). After specifying the ResourceName, requests using get, delete, update and patch verbs will be limited to the resource instance.

• The declaration of the following example allows an entity to only get and update a configmap called my configmap:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get", "update"]

3. Common role examples

• It is allowed to read and write the pod resources in the core API Group and the jobs resources in the "batch" and "extensions" groups

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

• It is allowed to read a configmap named my config (it must be bound to a RoleBinding to limit it to a configmap in a namespace)

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

• Read the Node resources of the core group (nodes belong to cluster level resources, which must be placed in ClusterRole and bound with ClusterRoleBinding)

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

　　

• Allow GET/POST operations on non resource endpoints / healthz and all its sub paths (ClusterRole and clusterrolebinding must be used)

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

4. Common role binding

• user name Alice@example.com

subjects:
- kind: User
  name: "Alice@example.com"
  apiGroup: rbac.authorization.k8s.io

• Group name frontend admins

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io

• Default ServiceAccount in Kube system namespace

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

• All service accounts in the qa namespace

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

• All serviceaccounts

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

• All users (all unauthenticated + all authenticated)

subjects:
- kind: Group
  name: system:authentication
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthentication
  apiGroup: rbac.authorization.k8s.io

5. Default role and role binding

API Server will create a set of default ClusterRole and ClusterRoleBinding objects, many of which are prefixed with system: to indicate that these resources belong to the infrastructure. Changes to these objects may cause cluster failure.

Common system roles are as follows:

Default ClusterRole	Default ClusterRoleBinding	describe
system:basic-user	system:authenticated	Enable users to read their own information
system:discovery	system:authenticated	Read only access to API discovery Endpoint, which is used for API level discovery and negotiation
system:public-info-viewer	system:authenticated and system:unauthenticated groups	Allow read-only access to non sensitive information of the cluster

Some default roles are not prefixed with system:, these roles are for users, including the super user role cluster admin, some for cluster level role cluster status, and the roles admin, edit and view for namespace

Common user roles are as follows:

Default ClusterRole	Default ClusterRoleBinding	describe
cluster-admin	system:masters group	Let the super user perform any operation on any resource. If it is used in ClusterRoleBinding, it will affect any resource in all namespaces of the whole cluster; If you use RoleBinding, you can control the resources in the bound namespace, including the namespace itself
admin	None	Allow admin and restrict the use of RoleBinding in one namespace. If used in RoleBinding, it allows read-write access to most resources in the namespace, including the ability to create roles and role bindings. This role does not allow operations on the namespace itself or write resource quotas.
edit	None	It is allowed to read and write most resources in the namespace. It is not allowed to view or modify roles and role bindings.
view	None	Read only operations are allowed on most objects, but roles, role bindings and secret are inaccessible.

Core component roles:

Default ClusterRole	Default ClusterRoleBinding	describe
system:kube-scheduler	System: Kube scheduler user	Be able to access the resources required by the Kube scheduler component
system:kube-controller-manager	System: Kube controller manager user	Be able to access the resources required by the Kube controller manager component
system:node	system:nodes group	Allows access to resources required by kubelet, including reading of secret and writing of pod. In the future, the above two permissions will be limited to the objects assigned to this node. In the authentication process in the future, kubelet must be in the form of system:node and a user name in the form of system:node
system:node-proxier	System: Kube proxy user	Allow access to resources required by Kube proxy

Other component roles:

Default ClusterRole	Default ClusterRoleBinding	describe
system:auth-delegator	None	It is allowed to outsource identity authentication and authentication check operations. This role is usually used on plug-in API servers to achieve unified identity authentication and authentication.
system:heapster	Node	Roles defined for the Heapster component (deprecated).
system:kube-aggregator	Node	Roles defined for the Kube aggregator component.
system:kube-dns	Kube DNS service account in Kube system namespace	Roles defined for Kube DNS components.
system:kubelet-api-admin	Node	Allow full access to the kubelet API.
system:node-bootstrapper	Node	Allows access to resources needed to perform kubelet TLS boot.
system:node-problem-detector	Node	Roles defined for the node problem detector component.
system:persistent-volume-provisioner	Node	Allows access to resources required by most dynamic volume drivers.
system:monitoring	system:monitoring group	Allow read access to control plane monitoring endpoints (for example: Kube apiserver survival and readiness endpoints (/ healthz, / livez, / readyz), various health check endpoints (/ healthz /, / livez /, / readyz / *) and / metrics). Note that each health check endpoint and metric endpoint may expose sensitive information.

Query command:

kubectl describe clusterrole admin
kubectl describe clusterrole cluster-admin
kubectl describe clusterrole edit
kubectl describe clusterrole view

Reference documents:
https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/