RBAC of kubernetes authority management (1)

Want to make APP Same thing as WeChat , Can run small programs smoothly ？ | Experience will send you to Xinjiang 、 Huawei 、 Cherry keyboard ！>>>

k8s In enabling role-based access control RBAC（Role-based-Access-Control） Authorization mode of . Equivalent to property based access control ABAC（Attribute-based Access Control）,RBAC Mainly introduced role （Role Set of authorities ） Bind to the role （RoleBinding） Abstract concept of . stay ABAC in ,k8s Access policies in a cluster can only be directly associated with users ; and RBAC in , Access policies can be associated with a role , Specific users are associated with a role or multiple roles .

RBAC There are four new k8s Top level resource object ：  role （Role）、 The cluster character （ClusterRole）、 Character binding （RoleBinding）、 Cluster role binding （ClusterRoleBinding）. Same as others API Resource objects are the same , Users can use kubectl perhaps API Call mode and so on to operate these resource objects .

 

RBAC It has the following advantages .
1、 Complete coverage of resource and non resource permissions in the cluster .
2、 Whole RBAC It's all about a few API Object complete , Same as others API object  , It can be used kubectl or API To operate .
3、 It can be adjusted at runtime , No need to restart  API Server.
4、 To use  RBAC  Authorization mode  , be   Need to be in  API Server  Start of   Parameters in   add --authorization-mode=RBAC.

 

1） role ( Role)
A role is a set of permissions , The permissions here are in the form of permission , There is no rule of rejection . In a namespace , Roles can be used to define a role , If it's cluster level , You need to use ClusterRole 了 . Roles can only authorize resources within a namespace , The role defined in the following example has read Pod Authority :

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default            // This means default The role under the namespace 
  name: pod-reader
rules:
- apiGroups: [""]    # "" An empty string , It means the core API Group 
  resources: ["pods"]            // The resource to operate 
  verbs: ["get", "watch", "list"]        // Operation resources correspond to specific permissions 

 

rules  The parameters in are described as follows ：
apiGroups:  Supported by API Group list , for example ”apiVersion: batch/v1”、”apiVersion: extensions”、”apiVersion: apps”
resources:  List of supported resource objects , for example  pods、deployments、secrets、jobs、configmaps、endpoints、persistentvolumeclaims、replicationcontrollers、statefulsets、namespaces etc. .
verbs:  For resource objects   List of operation methods for  ,  for example  get、 watch、 list、 delete、 replace、 patch 、create etc. 

 

2） The cluster character （ClusterRole）
In addition to the ability to manage resources in the same namespace as the role , Because of its cluster level effective range , It can also be used for authorization management of the following special elements ：

Cluster wide resources , Such as Node.

Non resource based path , Such as ”/healthz”.

Resources that contain all the namespace , for example pods（ be used for kubectl get pods –all-namespaces Such operations are authorized ）

The following cluster role can give users access to any or all of the namespace's secrets（ Depending on how it's bound ）：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: my-cluster-role
  # ClusterRole It's not limited to the namespace , So it omits namespace The definition of 
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

 

3） Character binding （RoleBinding） and Cluster role binding （ClusterRoleBinding）

First, role binding or cluster role binding is used to bind a role to a target , The binding target can be User（ user ）、Group（ Group ） perhaps Service Account. Use RoleBinding You can authorize a namespace , Use ClusterRoleBinding Cluster wide authorization is possible .

RoleBinding You can reference Role To authorize . In the following example RoleBinding Will be in default Put... In the namespace pod-reader The role grants the user jane, This operation makes jane Can read default In namespace Pod：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods
  namespace: default        // The namespace specified by the role binding 
subjects:
- kind: User                // The type of operation is user
  name: jane                //user The name of 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                // The type of permission binding is  role
  name: pod-reader            // For the above role name 
  apiGroup: rbac.authorization.k8s.io

 

RoleBinding You can also quote ClusterRole To authorize .

RoleBinding You can reference ClusterRole, To belong to the same namespace ClusterRole Define the resource subject to authorize . A very common practice is , The Cluster Administrator predefines a set of roles for the cluster scope （ClusterRole）, And then reuse these in multiple namespace ClusterRole. This can greatly improve the efficiency of authorization management , It also makes the basic authorization rules under each namespace consistent with the user experience .

For example, the following , although secret-reader It's a cluster role , But because of the use of RoleBinding``, therefore dave Can only read development Namespace `` Medium secret.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development   #  In the cluster role , Only in development Only permissions in the namespace can be granted dave
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding, Roles in cluster role binding can only be cluster roles . For authorization at the cluster level or for all namespace .
The following example allows manager The user of the group reads any namespace Medium secret：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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

The figure below shows the above pair of Pod Of get/watch/list Operations are authorized Role and RoleBinding logical relationship .

 

4） How resources are referenced

Most resources can be expressed as strings of their names , That is to say Endpoint Medium URL Relative paths , for example pods. However , some k8s API Include subordinate resources , Such as pod Log （logs）.pod The log Endpoint yes GET/api/v1/namespaces/{namespace}/pods/{pod_name}/log.

In this case ,Pod Is a resource in a namespace ,log It's a subordinate resource . To be in RBAC In the role , You need to use a slash ‘/‘ To distinguish between resources and subordinate resources .

If you want to authorize a subject to read at the same time Pod and Pod log, You can configure resources Is an array ：

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

Resources can also be named （ResourceName） reference （ This refers to the name of the resource instance ）. In the specified ResourceName after , Use get、delete、update、patch The request for action , Will be limited to the scope of this resource instance .

Such as A statement allows a subject to only one configmap Conduct get and update operation

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

resourceName This usage is correct for list、watch、create、deletecollection The operation is invalid , It's because you have to pass URL For authentication , And the resource name is in list、watch、create and deletecollection You can only ask for Body Part of the data .

Because there is so much , That's all for this issue , Next time we'll talk about common role examples 、 Common role binding examples . See you next time ~