k8s基于RBAC的权限控制,赋予pod访问k8s API的权限
部署在k8s集群中的应用,有些需要拥有访问k8s API服务器的权限,比如说获取当前命名空间下的pod,svc等资源。k8s通过RBAC规则来赋予用户、pod、组相应的权限。其中pod使用一种称为service accounts的机制,下面我们来实践如何为pod中的应用添加权限。首先需要在命名空间中创建serviceaccount资yaml详细内容如下:接着创建role(角色),role中包含角色
部署在k8s集群中的应用,有些需要拥有访问k8s API服务器的权限,比如说获取当前命名空间下的pod,svc等资源。k8s通过RBAC规则来赋予用户、pod、组相应的权限。其中pod使用一种称为service accounts的机制,下面我们来实践如何为pod中的应用添加权限。
首先需要在命名空间中创建serviceaccount资
yaml详细内容如下:
接着创建role(角色),role中包含角色所具有的功能,yaml内容如下:
yaml中定义了角色有获取default命名空间中pods的权限。
然后定义rolebinding(角色绑定),将角色绑定到上面创建的serviceaccount,
yaml文件内容如下:
创建一个pod进行测试,yaml文件如下
文件中serviceaccountname的值为上述绑定了角色的serviceaccount。
serviceaccount关联了一个configmap,绑定到pod之后,configmap被挂载到pod中,/var/run/secrets/kubernetes.io/serviceaccount/目录下包含三个文件,分别是
pod可以通过使用ca.crt和token来访问API服务器。
进入容器中,使用curl命令来获取default命名空间下pod,在get请求中带上ca.crt和token,如下
返回结果的部分如下:
API服务器返回了pod的详细信息。
除了pod,svc等属于某个命名空间的资源外,还可以获取非命名空间级别的k8s集群,包括pv等,需要使用到clusterrole(集群角色)资源,采用clusterrolebinding(集群角色绑定)将集群角色绑定到serviceaccount上。
serviceaccount,role和rolebinding必须属于某个命名空间下。假如A命名空间下的应用想要访问到B命名空间下的资源,可以将A命名空间下的serviceaccount绑定到B命名空间下的role。也可以将A命名空间下的serviceaccount绑定到clusterrole,让其可以获取所有命名空间下的资源。
clusterrole还可以允许访问非资源型的URL,如下图所示:
为了方便使用,k8s提供了一些clusterrole,部分如下图所示:
用户可以直接使用k8s提供的集群角色,从命名中可以看出,这些集群角色包括pod,pv,pvc,job,namespace等k8s本身提供的资源,可以根据不同的需求选择不同的集群角色,还可以将多个角色绑定到一个serviceaccount上。
更多推荐
所有评论(0)