Role-based Access Control (RBAC) is a method of regulating and controlling access to computers or network resources based on the roles of users in an enterprise.

. RBAC using RBAC authorization. K8s. IO API group to drive the authentication operation, through Kubernetes API allows administrators to dynamic allocation strategy.

In version 1.8, RBAC model is stable and through the RBAC authorization. K8s. IO/v1 API provides support.

To enable RBAC, add the –authorization-mode=RBAC parameter when you start the API server.

Summary of the API

This section describes the four top-level types declared by the RBAC API. Users can interact with these resources (through Kubectl, API calls, and so on) in the same way they interact with other API resources. For example, the command kubectl apply -f (resource).yml can be used on top of any of these examples. However, it is recommended that you proceed through the following chapters gradually, from the simplest to the most advanced.

Create a user that can access only one namespace

Create a User Account that can only access the kube-system namespace:

  • username:mooon
  • group: cmcc

Step 1: Create user credentials

As mentioned earlier, Kubernetes does not have a User Account API object, but it is quite easy to create a User Account by using a private key assigned to you by the administrator. Here we use the OpenSSL certificate to create a User, of course we can also use the simpler CFSSL tool to create a User:

Create a private key for user mooon and name it: mooon.key:

$ openssl genrsa -out mooon.key 2048
Copy the code

Create a certificate signing request file using the private key we just created: mooon.csr, be sure to specify the user name and group in the -subj argument (CN for user name, O for group) :

openssl req -new -key mooon.key -out mooon.csr -subj "/CN=mooon/O=cmcc"
Copy the code

And then find our Kubernetes cluster CA, we use the kubeadm installation of cluster, the CA certificate is located in the/etc/Kubernetes/pki/directory below, if you is to establish the binary mode, you should begin to build in the cluster was specifies the directory in which the good CA, We will use the ca.crt and ca.key files under the directory to approve the above certificate request and generate the final certificate file. Here we set the validity of the certificate to 500 days:

openssl x509 -req -in mooon.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out mooon.crt -days 500
Copy the code

Now check to see if a certificate file is generated under our current folder:

ls
mooon.csr mooon.key mooon.crt
Copy the code

Now we can use the certificate file and private key file we just created to create new credentials and contexts in the cluster:

kubectl config set-credentials mooon --client-certificate=mooon.crt --client-key=mooon.key
Copy the code

We can see that a user haimaxy has been created and then set a new Context for this user:

kubectl config set-context mooon-context --cluster=kubernetes --namespace=kube-system --user=mooon
Copy the code

At this point, our user haimaxy has been created successfully. Now we should get an error when we use the current configuration file to manipulate kubectl, because we haven’t defined any permissions for the user:

kubectl get pods --context=haimaxy-context
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"
Copy the code

Step 2: Create roles

After the user is created, we need to add operation rights to the user. Let’s define a YAML file and create a role that allows the user to operate Deployment, Pod, ReplicaSets as follows :(mooon-role-.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pods-reader
rules:
- apiGroups: ["] ""
  resources: ["pods","pods/exec"]
  verbs: ["get", "list". "watch". "create"] # can also use ['*']
Copy the code

create

kubectl create -f mooon-role.yaml
Copy the code

Step 3: Create role permission bindings

ClusterRole has been created, but obviously at this point our ClusterRole has nothing to do with our user Mooon, right? Create a ClusterRoleBinding object and bind the mooon-role role to the user mooon under the kube-system namespace :(mooon-rolebinding. Yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pods-readonly
subjects:
- kind: User
  name: mooon
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pods-reader
  apiGroup: rbac.authorization.k8s.io
Copy the code

create

kubectl create -f mooon-rolebinding.yaml
Copy the code

Step 4. Test

We should now be able to manipulate the cluster using the mooon-context above:

kubectl get pods --context=mooon-context
kubectl get nodes --context=haimaxy-context
Error from server (Forbidden): pods is forbidden: User "mooon" cannot list pods in the namespace "default"
Copy the code

Some command line tools

kubectl create role

Create a Role object that defines permissions in a namespace. Such as:

  • Create “pod-reader”RoleObject that allows the user to perform “get”, “watch”, and “list” actions on pods:
kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
Copy the code
  • Create a Role object named “pod-reader” and specify resourceNames:
kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Copy the code
  • Create a Role object named “foo” and specify apiGroups:
kubectl create role foo --verb=get,list,watch --resource=replicasets.apps
Copy the code
  • Create a Role object named “foo” and assign subresource permissions:
kubectl create role foo --verb=get,list,watch --resource=pods,pods/status
Copy the code
  • Create a Role object named “my-component-lease-holder” with get/update privileges on a given named resource:
kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component
Copy the code

kubectl create clusterrole

Create a ClusterRole object. Such as:

  • Create “pod-reader”ClusterRoleObject that allows users to perform “get”, “watch”, and “list” operations on pods objects:
kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
Copy the code
  • Create a file named “pod-reader”ClusterRoleObject and specify the resource name:
kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod
Copy the code
  • Create one named “foo”ClusterRoleObject and specify apiGroups:
kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps
Copy the code
  • Create one named “foo”ClusterRoleObject and specify a child resource:
kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status
Copy the code
  • Create one named “foo”ClusterRoleObject and specify a non-resource path:
kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*
Copy the code
  • Create one called “Monitoring”ClusterRoleObject and specify the aggregation rule:
kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"
Copy the code

kubectl create rolebinding

Authorize roles or ClusterRoles in a specific namespace. Such as:

  • In the namespace “acme”, will be named adminClusterRoleThe permission is granted to the user named “Bob” :
kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme
Copy the code
  • In the namespace “acme”, the view namedClusterRoleGrant permission to the service account named “myapp” in the namespace “acme” :
kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme
Copy the code
  • In the namespace “acme”, the view namedClusterRoleObject permissions are granted to service accounts named “myapp” in namespace “MyAppNamespace” :
kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme
Copy the code

kubectl create clusterrolebinding

Authorize ClusterRole across the cluster, including all namespaces. Such as:

  • Cluster-admin will be named across the clusterClusterRoleThe permission is granted to user “root” :
kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root
Copy the code
  • Across the cluster, there will be a file named System: Node-ProxierClusterRoleTo user system:kube-proxy:
kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy
Copy the code
  • Across the cluster, will be named ViewClusterRoleThe permissions defined in the object are granted to the service account named “myapp” in the “acme” namespace:
kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp
Copy the code

Setting Cluster Parameters

[root@k8s-master admin]# kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/cert/ca.pem --embed-certs=true --server=${KUBE_APISERVER} --kubeconfig=kubectl.kubeconfig
Copy the code

Set client authentication parameters

[root@k8s-master admin]# kubectl config set-credentials admin --client-certificate=admin.pem --client-key=admin-key.pem --embed-certs=true --kubeconfig=kubectl.kubeconfig
```shell
#Set the context parameters, including the cluster name and the name of the user accessing the cluster
```shell
[root@k8s-master admin]# kubectl config set-context kubernetes --cluster=kubernetes --user=admin --kubeconfig=kubectl.kubeconfig
Copy the code

Use the Default context

[root@k8s-master admin]# kubectl config use-context kubernetes --kubeconfig=kubectl.kubeconfig
Switched to context "kubernetes"
Copy the code

reference

www.jianshu.com/p/f77d5d0df… V1-17. Docs. Kubernetes. IO/useful/docs/ref…