Rbac introduces four top-level resource objects, role, ClusterRole, RoleBinding, and ClusterRoleBinding. As with other API resource objects, users can use Kubectl or API calls to manipulate resource objects.

1, the role

A role is a set of permissions. The permissions are in the form of permission, and there is no denial rule. Within a namespace, a role can be defined by a role. If both are at the cluster level, clusterRole is required.

A role can only authorize resources in a namespace. The role defined in the following example has the permission to read pods.

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: default
      name: pod-reader
    rules:
    - apiGroups: [""]	The empty string represents the core API group
      resources: ["pods"]
      verbs: ["get"."watch"."list"]
Copy the code

The following table describes the parameters in rules.

  • ApiGroups: indicates the list of supported API groups, for example, apiVersion: Batch /v1 apiVersion: Extensions :v1beta1 apiVersion: apps/v1beta1
  • Resources: List of supported resource objects, such as Pods, deployments, Jobs, and so on.
  • Verbs: provides a list of operations on resource objects, such as Get, Watch, List, Delete, replace, and Patch

In addition to managing resources in the same namespace as the role, the clusterole role can also be used to authorize the following special elements due to its cluster-level scope.

  • Cluster-wide resources, such as Node.
  • Non-resource path, for example, /healthz.
  • Resources that contain all namespaces, such as PODS (for operation authorizations such as Kubectl get Pods –all-namespaces).
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      # cluseterole is not limited to namespaces, so you do not need to set a namespace name
    rules:
    - apiGroups: [""]	The empty string represents the core API group
      resources: ["secerts"]
      verbs: ["get"."watch"."list"]
Copy the code

Clusterrolebinding or clusterRoleBinding is used to bind a role to a target, which can be user, group or SA. Use RoleBinding for a namespace and cluseterBinding for cluster-wide authorization. Rolebinding can be conferred by reference to roles. In the following example, roleBinding grants the pod-reader role to user Jane in the default namespace. This operation enables Jane to read pods in the default namespace:

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

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: read-secerts-global
    subjects:
    - kind: Group
      name: manager
      apiGroup: rbac.authorization.k8s.io
    rules:
      kind: ClusterRole
      name: secert-reader
      apiGroups: rbac.authorization.k8s.io
Copy the code