In the K8s RBAC system, there are three types of authorization objects: User, Group, and ServiceAccount.

As a resource type of K8s, ServiceAccout has a specific API that can be operated. This article introduces User and Group, which have no specific resource definition and are relatively difficult to view.

K8s RBAC model

Create User and Group

1. Issue X509 Client certificate

If the certificate is issued by CA, apiserver auth logic will parse the subject object of the certificate and use common_name (CN) as User and organization (O) as Group. e.g. the content of the certificate used by kubeconfig is as follows (view via cfssl-certinfo -cert admin.pem)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "subject": {
    "common_name": "kubernetes-admin",
    "organization": "system:masters",
    "names": [
      "system:masters",
      "kubernetes-admin"
    ]
  },
  ...
}

In this example, the User is kubernetes-admin, the Group is system:masters, and the other fields can be ignored for now.

2. Providing a static file to kube-apiserver

The kube-apiserver has a -token-auth-file parameter that points to a csv file where the user and group are declared; this way the declared user and group are valid for a long time, but if you want to change the contents of the file, you need to restart the apiserver.

The default csv file has 4 columns, token, user name, user uid, and the last column is group, which is optional. Multiple groups can be separated by ,. The example is as follows.

1
2

4ca847e7669ed6da37bc060da63e84c388,kubectl,10001,"system:view"
bc060da63e8046a9cfef23dd4e4c31a6a6,node-admin,10001,"system:masters"

How does the permission system validate User and Group permissions?

As with ServiceAccount, User and Group permissions are verified through the K8s RBAC mechanism, either using RoleBinding or ClusterRoleBinding for User and Group authorization.

By looking at the subjects.kind description of the RoleBinding or ClusterRoleBinding you can see that kind has three options “User”, “Group” and “ServiceAccount”, just specify the type of authorization you need in this field.

KIND: RoleBinding VERSION: rbac.authorization.k8s.io/v1

FIELD: kind DESCRIPTION: Kind of object being referenced. Values defined by this API group are “User”, “Group”, and “ServiceAccount”. If the Authorizer does not recognized the kind value, the Authorizer should report an error.

Taking the cluster-admin authorization as an example, the following YAML file grants the cluster-admin role (which has all cluster privileges) for the system:masters Group. We saw earlier that the organization in the certificate is signed by system:masters, so that’s why you can have K8s admin-level privileges with that certificate.

Bind the ClusterRole of the system:masters group to cluster-admin.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

ClusterRole cluster-admin has all permissions for all K8s resources.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

Ref