Shulou(Shulou.com)06/02 Report--

This is the third article in this series, and the first two articles introduced Kubernetes access control and authentication, respectively. This article will take you to understand the concept of Kubernetes authorization through hands-on practice.

Before the article officially begins, let's take a quick look at the environment and scenes in our practical process. We are working on clusters in a production environment, where each part is associated with a namespace. Now, there is a new colleague in the group named Bob, and in the previous tutorial, we helped Bob join the cluster as the administrator of the engineering namespace. And he has obtained the private key and signed certificate to access the cluster.

If you have not done so, please review the previous tutorial and run the commands to complete the environment settings and configure the certificate for Bob.

Okay, let's officially start this tutorial.

Now we want to authorize Bob to control resources that belong to the engineering namespace.

First, we want to create a context for kubectl so that it can switch between different environments.

Kubectl config set-context eng-context\-cluster=minikube\-namespace=engineering\-user=bobContext "eng-context" created.

The above command creates a new context that points to the engineering namespace using Bob's credentials in the minikube cluster. This causes a new section to be added to the ~ / .kube / config file.

Let's now create a simple pod in the engineering namespace:

ApiVersion: v1kind: Podmetadata: name: myapp namespace: engineering labels: app: myappspec: containers:-name: myapp image: busybox command: ["/ bin/sh", "- ec", "while:; do echo'.'; sleep 5; done"] kubectl create-f myapp.yamlpod/myapp createdkubectl get pods-n=engineeringNAME READY STATUS RESTARTS AGEmyapp 1and1 Running 089s

Although you can create and manipulate pod in the project namespace as a cluster administrator, Bob cannot even list pod in the same namespace.

Kubectl get pods-namespace engineering-as bobError from server (Forbidden): pods is forbidden: User "bob" cannot list resource "pods" in API group

In order for Bob to access resources in the engineering namespace, we need to authorize it. This can be done by creating a role with the appropriate permissions and binding it to the user Bob. In essence, we are using role-based access control (RBAC) to allow Bob to perform specific operations on certain Kubernetes resources in the engineering namespace.

Create a Kubernetes role named eng-reader that allows it to list pod in the engineering namespace.

Kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: engineering name: eng-readerrules:- apiGroups: ["] #" indicates the core API group resources: ["pods", "services", "nodes"] verbs: ["get", "watch", "list"] kubectl create-f role.yamlrole.rbac.authorization.k8s.io/eng-reader createdkubectl get roles-- namespace=engineeringNAME AGEeng-reader 58s

Note that this role currently has nothing to do with Bob. We need to apply the permissions specified in the role to the Bob through role binding.

Kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: eng-read-access namespace: engineeringsubjects:- kind: User name: bob # Name is case sensitive apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role # this must be Role or ClusterRole name: eng-reader # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.iokubectl create-f role-binding.yamlrolebinding.rbac.authorization.k8s.io/eng-read-access createdkubectl get rolebindings-namespace=engineeringNAME AGEeng-read-access 31s

Let's check to see if Bob can now access pod.

Kubectl get pods-- namespace engineering-- as bobNAME READY STATUS RESTARTS AGEmyapp 1 Compact 1 Running 0 11m

Now that he is associated with the eng-reader role, he has access to the pod list.

At this point, Bob's access to the cluster is still very limited. All he can do is list pod in the engineering namespace. This is not very helpful to Bob. He wanted to check the number of nodes in the cluster, but to his disappointment, he encountered forbidden error.

Kubectl get nodes-as bobError from server (Forbidden): nodes is forbidden: User "bob" cannot list resource "nodes" in API group

In Kubernetes, role and role binding can be applied both at the namespace level and at the cluster level. We now create a cluster role and a role binding associated with Bob to enable him to list nodes.

Kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: # "namespace" omitted since ClusterRoles are not namespaced name: cluster-node-readerrules:- apiGroups: [""] resources: ["nodes"] verbs: ["get", "watch" "list"] kubectl create-f cluster-role.yamlclusterrole.rbac.authorization.k8s.io/cluster-node-reader createdkubectl get clusterroles cluster-node-readerNAME AGEcluster-node-reader 49skind: ClusterRoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: read-cluster-nodessubjects:- kind: User name: bob # Name is case sensitive apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: cluster-node-reader apiGroup: rbac.authorization.k8s.iokubectl create-f cluster- Role-binding.yamlclusterrolebinding.rbac.authorization.k8s.io/read-cluster-nodes createdkubectl get clusterrolebindings read-cluster-nodesNAME AGEread-cluster-nodes 35s

Bob is now set up to list nodes in the cluster.

Kubectl get nodes-as bobNAME STATUS ROLES AGE VERSIONminikube Ready master 52m v1.15.2

The purpose of this tutorial is to help you understand roles and how role bindings work in Kubernetes. In the next article in this series, we will take a look at service account and keep an eye on it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.