Kubernetes基础:RBAC权限设置的两种方式

Kubernetes基础:RBAC权限设置的两种方式
这篇文章以给用户设定Kubernetes内置权限为例进行说明如何设定权限。

环境准备

快速环境搭建建议使用单机版Kubernetes的安装脚本,一键安装,详情可参看:

环境信息如下所示

[root@host132 ~]# kubectl get node -o wide
NAME              STATUS   ROLES    AGE   VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION          CONTAINER-RUNTIME
192.168.163.132   Ready    <none>   32m   v1.15.0   192.168.163.132   <none>        CentOS Linux 7 (Core)   3.10.0-957.el7.x86_64   docker://18.9.7
[root@host132 ~]# 

方式1: 在生成证书的csr文件中设定

以kubectl使用的管理员证书为例,只需要在O的设定中指定内置Clusterrolebinding的组system:masters即可,示例csr信息如下所示:

[root@host132 ~]# cat /etc/ssl/k8s/admin-csr.json 
{
    "CN": "admin",
    "hosts": [],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "DaLian",
            "ST": "LiaoNing",
            "O": "system:masters",
            "OU": "System"
        }
    ]
}
[root@host132 ~]# 

在使用证书认证的时候,CN和O是Kubernetes用于身份确认的重要信息,在理解上可以与用户和组进行类似比较,所以不能写错,这是刚上手的开发者最容易出错的问题点之一。
在O中指定system:masters,会允许超级用户对任何资源进行任何操作的处理,所以这个基本上就是全体权限的赋予,在使用中很方便,但是实际使用中建议还是细粒度到所有权限的最小粒度进行赋权。

方式2: 通过Clusterrolebinding进行权限关联

以将kubelet-bootstrap用户给设定上超级权限为例,可以使用如下命令直接进行关联。

[root@host132 ~]# kubectl create clusterrolebinding bootstrap --clusterrole=cluster-admin --user=kubelet-bootstrap
clusterrolebinding.rbac.authorization.k8s.io/bootstrap created
[root@host132 ~]#
  • kubelet-bootstrap用户与token的设定信息
[root@host132 ~]# cat /etc/k8s/token.csv 
00fdeedfa65384fe4dca538a54a0e8a1,kubelet-bootstrap,10001,"system:kubelet-bootstrap"[root@host132 ~]#
  • cluster-admin的信息
[root@host132 ~]# kubectl get clusterrolebinding cluster-admin
NAME            AGE
cluster-admin   5h38m
[root@host132 ~]# 

详细信息如下所示

[root@host132 ~]# kubectl describe clusterrolebinding cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind   Name            Namespace
  ----   ----            ---------
  Group  system:masters  
[root@host132 ~]# 

从这里面我们看到了其实cluster-admin所关联的也是system:masters,所以跟方式1使用的都是相同的方式。

另外可以看到这种方式引用了cluster-admin,可以算是一种复用,这也是ClusterRole或者Role存在的原因之一吧。

[root@host132 ~]# kubectl describe clusterrolebinding bootstrap
Name:         bootstrap
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind  Name               Namespace
  ----  ----               ---------
  User  kubelet-bootstrap  
[root@host132 ~]# 

总结

system:masters作为超级用户权限,在使用中还是慎用再慎用,至于为何给一个kubelet-bootstrap用户以超级权限,虽然背离了此用户的初衷,但是到是学习过程中快速体验RBAC的有效方式,就像很多安装实施上来就会systemctl stop firewalld一样,在生产环境还是按照繁琐的方式进行配置较好。

其他基础

参考内容

https://kubernetes.io/docs/reference/access-authn-authz/rbac/

上一篇:kubernetes集群的安装异常汇---docker的驱动引擎


下一篇:kubectl 服务无法启动