Permission Controler-通过Instance理解Kubernetes的授权

这一系列文档都是关于Kubernetes集群内部pods等资源对外部请求的认证与授权的管以及如何使用roles和role binding控制Kubernetes内部资源的访问权限。

• Kubernetes Permission Controler概览

• Permission Controler-通过Instance理解Kubernetes的Auth

• Permission Controler-通过Instance理解Kubernetes的授权

• Permission Controler-探索Kubernetes的Service Accounts

我们回顾下实验场景：线上的集群需要通过不同的namespaces隔离不同部门的员工。DevOps团队来了一位新员工Bob，他主要管理engineering namespace下的资源。他已经提交了私钥和证书，Kubetnets admin管理员也已经做好了Bob访问Kubernetes集群的认证工作。

如果你还没完成上面的实验环境，请参照上一篇文章。

接下来，我将授权Bob访问engineering namespace下的资源。

1. 为了方便切换不同的用户环境，首先为Kubectl配置context

kubectl config set-context eng-context \
	--cluster=minikube \
	--namespace=engineering \
	--user=bob

上面的命令将会使用Bob的认证创建可以访问集群engineering namespace的上下文环境。上面命令执行的最终将写到~/.kube/config file中。

cat ~/.kube/config | grep bob

2. 在engineering namespace下创建pod

cat >> myapp.yaml <<EOF
heredoc> apiVersion: v1
kind: Pod
metadata:
  name: myapp
  namespace: engineering
  labels:
    app: myapp
spec:
  containers:
  - name: myapp
    image: busybox
    command: ["/bin/sh", "-ec", "while :; do echo '.'; sleep 5 ; done"]
heredoc> EOF

kubectl create -f myapp.yaml

kubectl get pods -n engineering

3. 上面的命令我们使用是admin的用户，Bob用户并没有list engineering namespace pods的权限

kubectl get pods -n engineering --as bob

4. 对bob进行授权

为了让Bob可以访问engineering namespace下的资源，我们需要对Bob进行授权操作。主要是通过创建具有相关权限的role，然后将role绑定到Bob上。本质上，使用Role Based Access Control（RBAC）使的Bob具有对engineer namespace下资源特定操作的权限。

• 在eng-reader的role中设置list engineering namespace下pods的权限

cat >> eng_role.yaml <<EOF
heredoc> kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: engineering
  name: eng-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods", "services", "nodes"]
  verbs: ["get", "watch", "list"]
heredoc> EOF

kubectl create -f eng_role.yaml

验证

kubectl get roles --namespace=engineering

接下来，我们将通过role binding将描述特殊权限的role授权给Bob用户。

cat >> role_binding_bob.yaml <<EOF
heredoc> kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: eng-read-access
  namespace: engineering
subjects:
- kind: User
  name: bob # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  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.io
heredoc> EOF

kubectl apply -f role_binding_bob.yaml

kubectl get rolebindings -n engineering

5. 验证Bob是否具有访问engineering namespace下资源的权限

kubectl get pods --namespace engineering --as bob

可见在bob绑定eng-reader权限后便具有list engineering namespace下资源的权限。

通过上面的例子可以完美演示如何通过权限限制bob访问集群，现在bob所能做的只是list engineering namspace下的pods。当好奇的我们使用bob查看集群的节点个数时，我们将会遇到下面的拒绝提示：

kubectl get nodes --as bob

6. 使用集群层级的cluster role和cluster role binding

不但可以使用namespace级别的Roles和role binding，还可以使用集群级别的。接下来我们创建集群级别的cluster role并将它绑定到用户bob，从而实现bob list 集群nodes个数的行为。

cat >> cluster_node_reader.yaml <<EOF
heredoc> kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: cluster-node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]
heredoc> EOF

kubectl apply -f cluster_node_reader.yaml

kubectl get clusterroles cluster-node-reader

接下来通过 cluster role binding 将 cluster role绑定到bob上

cat >> cluster_node_reader_binding_bob.yaml <<EOF
heredoc> kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-cluster-nodes
subjects:
- kind: User
  name: bob # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-node-reader
  apiGroup: rbac.authorization.k8s.io
heredoc> EOF

kubectl apply -f cluster_node_reader_binding_bob.yaml

kubectl get clusterrolebinding   read-cluster-nodes

7. 验证bob是否具有list node的权限

kubectl get nodes --as bob

本篇文章我主要讲解role和role binding授权用户已特定的行为访问集群中的特定资源，在这个系列的最后一篇文章中我将详细讲解service accounts。

文章翻译自thenewstack.io/a-practical…,行文时略有删减