【云原生丨K8s系列20】 RBAC 的配置⽅法演示(上):创建⼀个只能访问某个 namespace 的⽤户
前言
在上一篇文章中我们深入学习了
RBAC - 基于⻆⾊的访问控制
这一重要概念以及它的适用情况,接下来给大家演示创建⼀个只能访问某个 namespace 的⽤户。
文章目录
- 前言
- 创建⼀个只能访问某个命名空间的⽤户
- 第1步:创建⽤户凭证
- 第2步:创建⻆⾊
- 第3步:创建⻆⾊权限绑定
- 第4步:测试
创建⼀个只能访问某个命名空间的⽤户
我们来创建⼀个 User Account,只能访问 kube-system 这个命名空间:
- username: haimaxy
- group: youdianzhishi
第1步:创建⽤户凭证
我们前⾯已经提到过, Kubernetes 没有 User Account 的 API 对象,不过要创建⼀个⽤户帐号的话也是挺简单的,利⽤管理员分配给你的⼀个私钥就可以创建了,这个我们可以参考官⽅⽂档中的⽅法,这⾥我们来使⽤ OpenSSL 证书来创建⼀个 User,当然我们也可以使⽤更简单的 cfssl ⼯具来创建:
- 给⽤户 haimaxy 创建⼀个私钥,命名成:haimaxy.key:
$ openssl genrsa -out haimaxy.key 2048
- 使⽤我们刚刚创建的私钥创建⼀个证书签名请求⽂件:haimaxy.csr,要注意需要确保在 -subj 参数中指定⽤户名和组(CN表示⽤户名,O表示组):
$ openssl req -new -key haimaxy.key -out haimaxy.csr -subj "/CN=haimaxy/O=youdianzhis"
- 然后找到我们的 Kubernetes 集群的 CA ,我们使⽤的是 kubeadm 安装的集群, CA 相关证书位于 /etc/kubernetes/pki/ ⽬录下⾯,如果你是⼆进制⽅式搭建的,你应该在最开始搭建集群的时候就已经指定好了 CA 的⽬录,我们会利⽤该⽬录下⾯的 ca.crt 和 ca.key 两个⽂件来批准上⾯的证书请求
- ⽣成最终的证书⽂件,我们这⾥设置证书的有效期为500天:
$ openssl x509 -req -in haimaxy.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out haimaxy.crt -days 500
- 现在查看我们当前⽂件夹下⾯是否⽣成了⼀个证书⽂件:
$ ls
haimaxy.csr haimaxy.key haimaxy.crt
- 现在我们可以使⽤刚刚创建的证书⽂件和私钥⽂件在集群中创建新的凭证和上下⽂(Context):
$ kubectl config set-credentials haimaxy --client-certificate=haimaxy.crt --client-key=haimaxy.key
我们可以看到⼀个⽤户 haimaxy 创建了,然后为这个⽤户设置新的 Context:
$ kubectl config set-context haimaxy-context --cluster=kubernetes --namespace=kube-system--user=haimaxy
到这⾥,我们的⽤户 haimaxy 就已经创建成功了,现在我们使⽤当前的这个配置⽂件来操作 kubectl 命令的时候,应该会出现错误,因为我们还没有为该⽤户定义任何操作的权限呢:
$ kubectl get pods --context=haimaxy-context
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"
第2步:创建⻆⾊
⽤户创建完成后,接下来就需要给该⽤户添加操作权限,我们来定义⼀个 YAML ⽂件,创建⼀个允许⽤户操作 Deployment、Pod、ReplicaSets 的⻆⾊,如下定义:(haimaxy-role.yaml)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: haimaxy-role
namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
resources: ["deployments", "replicasets", "pods"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使⽤['*']
其中 Pod 属于 core 这个 API Group,在 YAML 中⽤空字符就可以,⽽ Deployment 属于 apps 这个API Group, ReplicaSets 属于 extensions 这个 API Group(我怎么知道的?点这⾥查⽂档),所以rules 下⾯的 apiGroups 就综合了这⼏个资源的 API Group:[“”, “extensions”, “apps”],其中 verbs 就是我们上⾯提到的可以对这些资源对象执⾏的操作,我们这⾥需要所有的操作⽅法,所以我们也可以使⽤[‘*’]来代替。
然后创建这个 Role :
$ kubectl create -f haimaxy-role.yaml
注意这⾥我们没有使⽤上⾯的 haimaxy-context 这个上下⽂了,因为⽊有权限啦
第3步:创建⻆⾊权限绑定
Role 创建完成了,但是很明显现在我们这个 Role 和我们的⽤户 haimaxy 还没有任何关系,对吧?这⾥我就需要创建⼀个 RoleBinding 对象,在 kube-system 这个命名空间下⾯将上⾯的 haimaxy-role ⻆⾊和⽤户 haimaxy 进⾏绑定:(haimaxy-rolebinding.yaml)
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: haimaxy-rolebinding
namespace: kube-system
subjects:
- kind: User
name: haimaxy
apiGroup: ""
roleRef:
kind: Role
name: haimaxy-role
apiGroup: ""
上⾯的 YAML ⽂件中我们看到了 subjects 关键字,这⾥就是我们上⾯提到的⽤来尝试操作集群的对象,这⾥对应上⾯的 User 帐号 haimaxy,使⽤ kubectl 创建上⾯的资源对象:
$ kubectl create -f haimaxy-rolebinding.yaml
第4步:测试
现在我们应该可以上⾯的 haimaxy-context 上下⽂来操作集群了:
$ kubectl get pods --context=haimaxy-context
....
我们可以看到我们使⽤ kubectl 的使⽤并没有指定 namespace 了,这是因为我们已经为该⽤户分配了权限了,如果我们在后⾯加上⼀个-n default
试看看呢?
$ kubectl --context=haimaxy-context get pods --namespace=default
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the n
amespace "default"
是符合我们预期的吧?因为该⽤户并没有 default 这个命名空间的操作权限。
下篇文章将向大家演示“创建⼀个只能访问某个 namespace 的ServiceAccount”