一、简介
(1)Kubernetes的授权是基于插件形式的,常用的授权插件有以下几种:
- Node:node节点授权
- ABAC:基于属性的访问控制
- RBAC:基于角色的访问控制
- Webhook:自定义http回调方法
基于角色的访问控制:如图,先让一个用户(Users)
扮演一个角色(Role)
,让角色(Role)拥有权限
,从而让用户拥有这样的权限
,然后在授权机制当中,只需要将权限授予某个角色
,此时用户将获取对应角色的权限
,从而实现角色的访问控制
(2)Role和ClusterRole
Role是一系列的权限的集合
,例如一个Role可以包含读取 Pod 的权限和列出 Pod 的权限, ClusterRole 跟 Role 类似,但是ClusterRole可以在集群中全局使用。
-
Role
:
只能授予单个namespace 中资源的访问权限 -
ClusterRole
:
所有namespaces 中的namespaced 资源
(3)RoleBinding和ClusterRoleBinding
RoleBinding是将Role中定义的权限授予给用户或用户组
。它包含一个subjects列表(users,groups ,service accounts)
,并引用该Role,Role有了权限,用户也就有了权限。
RoleBinding在某个namespace 内授权,ClusterRoleBinding适用在集群范围内使用
二、RBAC 应用实验
接着上次实验进行操作: kubernetes 集群的访问
删除掉集群权限
kubectl delete -f dengm.yaml
再次访问
OK,权限已经失去。 开始本章的实验
角色绑定:
(1)Role --> User -->Rolebinding
命令创建帮助:
kubectl create role -h |grep -A 3 Usage
--verb: 指定权限
--resource: 指定资源或者资源组
--dry-run:此模式不会运行(调试模式)
1、生成资源清单默认名称空间查看Pod的权限
kubectl create role role-Pod --verb=get,list,watch --resource=pod --dry-run=client -o yaml > role.yaml
2、生成允许Pod权限
kubectl apply -f role.yaml
Role此时已经生成,用户我们也有,接下来就是
角色绑定
3、生成角色绑定资源清单
- 帮助命令
kubectl create rolebinding -h |grep Usage -A 3
-clusterrole: 集群角色名称
--role: 角色名称
--user: 绑定用户
--group: 绑定组
--serviceaccount=namespace:serviceaccountname: sa名称
--dry-run: 此模式不会运行(调试模式)
- 生成绑定资源清单
kubectl create rolebinding rolebing-readPod --role=role-Pod --user=dengm --dry-run=client -o yaml > rolebinding.yaml
4、生成角色绑定清单
kubectl apply -f rolebinding.yaml
5、dengm用户登录
su - dengm
6、查看是否允许查看Pod
7、访问其他名称空间资源(访问失败)
kubectl get pod -n kube-system
OK,角色绑定简单测试目前就这些。 结论:role和只对当前名称空间生效。
集群角色绑定:
(2)ClusterRole–>ClusterRoleBinding–>User
ClusterRole命令创建帮助:
kubectl create clusterrole -h |grep Usage -A 3
--verb: 指定权限
--resource: 指定资源或者资源组
--dry-run:此模式不会运行(调试模式)
1、生成资源清单任意名称空间
Pod的权限与日志权限
kubectl create clusterrole clusterrole-reaPod --verb=get,list,watch --resource=pods --dry-run=client -o yaml > clusterrole-reaPod.yaml
2、生成集群角色资源清单
kubectl apply -f clusterrole-reaPod.yaml
ClusterRole此时已经生成,接下来就是创建集群角色绑定
3、生成集群角色绑定资源清单
- clusterrolebinding帮助命令
kubectl create clusterrolebinding -h |grep -A 3 Usage
--clusterrole: 集群角色名称
--user: 用户名
--group: 组名
--serviceaccount=namespace:serviceaccountname: sa名称
--dry-run: 此模式不会运行(调试模式)
4、生成集群角色绑定资源清单
kubectl create clusterrolebinding clusterrolebinding-readPod \
--clusterrole=clusterrole-reaPod \
--user=dengm \
--dry-run=client \
-o yaml > clusterrolebinding-readPod.yaml
5、生成集群权限绑定
kubectl apply -f clusterrolebinding-readPod.yaml
6、登录dengm用户
su - dengm
7、查看是否允许任意名称空间Pod资源
kubectl get pod -n kube-system
测试完毕, 已经允许访问Pod资源,这里我们只是做了dengm用户访问Pod的资源,如果查看当前拥有的名称空间肯定不行的。
删除全部yaml文件,接着下面的实验。
三、角色指定名称空间绑定集群权限
1、允许开发人员查看Pod的日志并且局限在默认的名称空间下
cp clusterrole-reaPod.yaml clusterrole-reaPod2.yaml && cp rolebinding.yaml rolebinding2.yaml
修改rolebinding2.yaml:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rolebinding-clusterrole
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: clusterrole-reaPod
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: dengm
修改clusterrole-reaPod2.yam:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: clusterrole-reaPod
rules:
- apiGroups:
- ""
resources:
- pods
- pods/log
verbs:
- get
- list
- watch
2、生成集群角色绑定与查看日志的权限
kubectl apply -f clusterrole-reaPod2.yaml -f rolebinding2.yaml
结论: 角色绑定集群权限,如果角色绑定指定名称空间则只允许该名称空间下拥有集群权限。
a