权限控制-经过实例理解Kubernetes的受权

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

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

若是你还没完成上面的实验环境,请参照上一篇文章bash

接下来,我将受权Bob访问engineering namespace下的资源。app

1. 为了方便切换不一样的用户环境,首先为Kubectl配置contextpost

kubectl config set-context eng-context \
	--cluster=minikube \
	--namespace=engineering \
	--user=bob
复制代码

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

cat ~/.kube/config | grep bob
复制代码

2. 在engineering namespace下建立podthis

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的权限spa

kubectl get pods -n engineering --as bob
复制代码

4. 对bob进行受权翻译

为了让Bob能够访问engineering namespace下的资源,咱们须要对Bob进行受权操做。主要是经过建立具备相关权限的role,而后将role绑定到Bob上。本质上,使用Role Based Access Control(RBAC)使的Bob具备对engineer namespace下资源特定操做的权限。code

  • 在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…,行文时略有删减

相关文章
相关标签/搜索