这是本系列文章中的第三篇,前两篇文章分别介绍了Kubernetes访问控制以及身份认证。本文将通过上手实践的方式,带你理解 Kubernetes 授权这一概念。
在文章正式开始之前,我们先快速回顾一下我们实操过程中的环境和场景。我们正在处理生产环境中的集群,其中每个部分都与命名空间相关联。现在,组里新来了一位同事叫 Bob,我们在上篇教程中帮助 Bob 以 engineering 命名空间管理员的身份加入集群。并且他已经获得私钥以及签名证书来访问集群。
如果你还没有完成上述操作,请查看上篇教程,运行其中的命令以完成环境设置以及为 Bob 配置证书。
好,我们正式开始本篇教程。
现在我们要给 Bob 授权,以控制属于 engineering 命名空间的资源。
首先,我们要为 kubectl 创建一个上下文(context),方便它在不同的环境之间切换。
kubectl config set-context eng-context \
--cluster=minikube \
--namespace=engineering \
--user=bob
Context "eng-context" created.
复制代码
上面的命令使用 Bob 在 minikube 集群中的凭据创建了一个指向 engineering 命名空间的新上下文。这会导致在〜/ .kube / config 文件中添加一个新的部分。
我们现在在 engineering 命名空间中创建一个简单的 pod:
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"]
复制代码
kubectl create -f myapp.yaml
pod/myapp created
复制代码
kubectl get pods -n=engineering
NAME READY STATUS RESTARTS AGE
myapp 1/1 Running 0 89s
复制代码
虽然您可以作为集群管理员在工程命名空间中创建和操作 pod,但 Bob 甚至无法在同一名称空间中列出 pod。
kubectl get pods --namespace engineering --as bob
Error from server (Forbidden): pods is forbidden: User "bob" cannot list resource "pods" in API group "" in the namespace "engineering"
复制代码
为了使得 Bob 可以在 engineering 命名空间中访问资源,我们需要给他授权。这可以通过创建具有适当权限的角色然后将其绑定到用户 Bob 来完成。实质上,我们使用的是基于角色访问控制(RBAC)来允许 Bob 对 engineering 命名空间中的某些 Kubernetes 资源执行特定操作。
创建一个名为 eng-reader 的 Kubernetes 角色,允许其在 engineering 命名空间中列出 pod。
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"]
复制代码
kubectl create -f role.yaml
role.rbac.authorization.k8s.io/eng-reader created
复制代码
kubectl get roles --namespace=engineering
NAME AGE
eng-reader 58s
复制代码
注意,这一角色目前和 Bob 毫无关联。我们需要通过角色绑定将角色中指定的权限应用于 Bob。
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
复制代码
kubectl create -f role-binding.yaml
rolebinding.rbac.authorization.k8s.io/eng-read-access created
复制代码
kubectl get rolebindings --namespace=engineering
NAME AGE
eng-read-access 31s
复制代码
让我们来检查一下 Bob 现在是否可以访问 pod。
kubectl get pods --namespace engineering --as bob
NAME READY STATUS RESTARTS AGE
myapp 1/1 Running 0 11m
复制代码
既然他现在已经关联了 eng-reader 角色,那么他就获得了 pod 列表的权限。
此时,Bob 在集群中的访问权限依旧十分有限。他所能做的只是在 engineering 命名空间中列出 pod。这对 Bob 帮助不大。他想要检查集群中的节点数量,但是令他失望的是,他遇到了 forbidden error。
kubectl get nodes --as bob
Error from server (Forbidden): nodes is forbidden: User "bob" cannot list resource "nodes" in API group "" at the cluster scope
复制代码
在 Kubernetes 中角色和角色绑定既可以应用在命名空间层面也可以应用在集群层面。我们现在创建一个集群角色以及一个与 Bob 关联的角色绑定,以使他能够列出节点。
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"]
复制代码
kubectl create -f cluster-role.yaml
clusterrole.rbac.authorization.k8s.io/cluster-node-reader created
复制代码
kubectl get clusterroles cluster-node-reader
NAME AGE
cluster-node-reader 49s
复制代码
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
复制代码
kubectl create -f cluster-role-binding.yaml
clusterrolebinding.rbac.authorization.k8s.io/read-cluster-nodes created
复制代码
kubectl get clusterrolebindings read-cluster-nodes
NAME AGE
read-cluster-nodes 35s
复制代码
现在,Bob 已经设置为可以在集群中列出节点。
kubectl get nodes --as bob
NAME STATUS ROLES AGE VERSION
minikube Ready master 52m v1.15.2
复制代码
本篇教程的目的是为了帮助你理解角色以及角色绑定如何在 Kubernetes 中工作的。在本系列下一篇文章中,我们将来看看 service account,保持关注哟~
评论