上一篇文章中,我们成功配置安装了kubernetes-dashboard插件,但是这里似乎来了另外一个问题:我们怎样进入到dashboard?
如上图,kubernetes-dashboard
提供了两种验证方式:kubeconfig
、token
。这两种验证方式都是怎么回事呢?诶,好像有一个skip
,我们点击看看。直接点击skip
,我们进入到了dashboard的界面,但是似乎我们什么都做不了,页面给出了提醒,我们没有权限查看和操作集群里面的资源。该怎么办呢?下面就让我们一起来看看kubernetes里面的身份认证和权限管理吧!
要了解k8s中的身份认证和权限管理我们就必须先来了解k8s中的RBAC(Role-based access control)授权模式。
RBAC in K8s
RBAC Authorization
的基本概念是Role
和RoleBinding
。Role
是一些permission
的集合;而RoleBinding
则是将Role
授权给某些User
、某些Group
或某些ServiceAccount
。K8s官方博客RBAC Support in Kubernetes一文的中的配图对此做了很生动的诠释:
从上图中我们可以看到:
Role:pod-reader
拥有Pod的get
和list
permissions;
RoleBinding:pod-reader
将Role
:pod-reader
授权给右边的User
、Group
和ServiceAccount
。
与Role
和RoleBinding
对应的是,K8s还有ClusterRole
和ClusterRoleBinding
的概念,它们不同之处在于:ClusterRole
和ClusterRoleBinding
是针对整个Cluster
范围内有效的,无论用户或资源所在的namespace
是什么;而Role
和RoleBinding
的作用范围是局限在某个k8s namespace中的。
kubernetes在安装之初就已经生成了许多role
、rolebinding
、clusterrole
和clusterrolebinding
,它们也是属于kubernetes资源的一部分,所以可以通过get
、describe
等命令查看,如下:
1 | [root@iZwz9f6pgul78p7die5tlzZ dashboard]# kc get role -n kube-system |
下面截取了kubernetes-dashboard.yml
文件的一部分:
1 | # ------------------- Dashboard Service Account ------------------- # |
上面这个yml文件做了这么一件事情:在kube-system
命名空间中创建了一个名为kubernetes-dashboard
的ServiceAccount
。同时,在kube-system
命名空间中创建了一个名为kubernetes-dashboard-minimal
的Role
,并且定义了这个Role的权限.然后同样是在kube-system
命名空间中创建了一个RoleBinding
,将上面的Role
与ServiceAccount
绑定在一起了。这样kubernetes-dashboard
就有了kubernetes-dashboard-minimal
所定义的权限了。有一点需要注意:这里的kubernetes-dashboard
这个ServiceAccount是当用户直接点击skip
进入到dashboard
时所使用的账户。
测试环境中的认证
如果是在测试环境中,我们图个简单,不考虑安全性的情况之下。可以考虑让外部用户直接点击skip
进入到dashboard,并且拥有所有的权限。这一点可以通过将cluster-admin
这个拥有全集群最高权限的ClusterRole
绑定到默认使用的ServiceAccount--kubernetes-dashboard
,具体的做法是:
创建文件:dashboard-admin.yml
,填写下列内容:
1 | apiVersion: rbac.authorization.k8s.io/v1beta1 |
执行下面的命令来创建一个ClusterRoleBinding:
1 | $ kubectl create -f dashboard-admin.yml |
这样,我们就可以直接点击skip
进入dashboard,并且拥有全部的权限。
基于token的认证
下面我们来说说token这种方式。点击选择:Token单选框,提示你输入token。token从哪里获取,我们从来没有生成过token?其实当前K8s中已经有了很多token:
1 | [root@iZwz9f6pgul78p7die5tlzZ dashboard]# kc get secret -n kube-system |
如上,这里有很多的secret
存在于系统之中,每个secret
都对应了一个token
,但是这些token
所对应的权限都不相同,所以不一定会符合我们的要求。
这里我们需要创建一个名为admin的ServiceAccount并绑定名为cluster-admin的ClusterRole角色(该角色拥有集群最高权限),使用下面的yaml文件创建admin用户并赋予他管理员权限,然后可以通过token登陆dashbaord。这种认证方式本质上是通过ServiceAccount的身份认证加上Bearer token请求API server的方式实现。
admin-token.yml
1 | kind: ClusterRoleBinding |
运行下面的命令:
1 | $ kubectl create -f admin-token.yml |
然后我们可以通过如下的命令来获取admin ServiceAccount的token:
1 | [root@iZwz9f6pgul78p7die5tlzZ ~]# kc get secret -n kube-system | grep admin |
如上,我们得到了该用户的token,注意:这里的token是进行base64编码后的结果,而我们需要的是解码之后的结果,直接获取解码之后的token可以通过下面的命令实现:
1 | $ kubectl -n kube-system get secret admin-token-whj4t -o jsonpath={.data.token}|base64 -d |
这样,我们将解码之后的token复制出来,填入dashboard认证表单中就可以进入dashboard并且获取全集群的最高权限。
基于kubeconfig的认证
如何生成kubeconfig文件请参考创建用户认证授权的kubeconfig文件。
注意参考文章中生成的kubeconfig文件中没有token字段,如果我们要使用kubeconfig
登录dashboard则需要手动添加该字段。
对于访问dashboard
时候使用的kubeconfig
文件如brand.kubeconfig
必须追到token
字段,否则认证不会通过。而使用kubectl
命令时的用的kubeconfig
文件则不需要包含token字段。
kubeconfig的认证可以让拥有该kubeconfig的用户只拥有一个或几个命名空间的操作权限,这相比与上面的token的方式更加的精确和安全。kubeconfig也可以针对kubectl
:
1 | $ cp -f brand.kubeconfig ~/.kube/config |
这样,该用户就只具有brand.kubeconfig文件所确定的命名空间的操作权限了。