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/