前言
在之前的文章中介绍了k8s如何生成一个完整的kubeconfig文件，单纯的生成kubeconfig文件，不对user或group进行权限绑定是无法访问k8s集群的，今天就介绍一下k8s中RBAC鉴权相关的内容
RBAC介绍
基于角色的权限控制，在k8s为了实现这种机制，RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding
k8s的RBAC是白名单机制，想让他具备什么权限，就先创建某个角色Role然后定制rules，再将某个用户user与该role进行绑定bind得到这种绑定关系为RoleBind
ROLE
role 是用来在某个namespace内设置访问权限； 在创建 Role 时，必须指定该 Role 所属的namespace，可以为namespaced级别的资源设置权限，如pods,statefulsets,deployments等
示例
- 通过命令行创建
--resource: 资源，多个资源以,分割--verb: 对资源的操作权限，包括get,list,watch等等
kubectl create role pod-reader --resource=pods --verb=get,list,watch -n default
- 通过yml创建
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
resources: ["pods"]
verbs: ["get", "watch", "list"]
ClusterRole
ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围，所以它还可以为集群级别的资源设置权限，如Node。
role和clusterrole功能类似，如果需要在namespace内定义角色，应该使用 Role； 如果希望定义集群范围的角色，应该使用 ClusterRole
示例
- 通过命令行创建
参数与Role是一致的，与Role同的是clusterrole是控制集群资源的权限访问
kubectl create clusterrole secret-reader --resource=secrets --verb=get,watch,list
- 通过yml创建
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制
name: secret-reader
rules:
- apiGroups: [""]
# 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
RoleBinding
角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体（Subject）（user、group或serviceaccount）的列表和对这些主体所获得的角色的引用。
一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。
示例
- 通过命令行创建
--user: 用户名（也可以使用–group指定用户组）、--role： 角色名
kubectl create rolebinding read-pods --user=user1 --role=pod-reader -n default
- 通过yml创建
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pod
# 你需要在该名字空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: User
name: jane # "name" 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: Role # 此字段必须是 Role 或 ClusterRole
name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup: rbac.authorization.k8s.io
- RoleBinding 也可以引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个集群定义一组通用的角色， 之后在多个名字空间中复用
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secret
# 你需要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
name: read-secrets
# RoleBinding 的名字空间决定了访问权限的授予范围。
# 这里隐含授权仅在 "development" 名字空间内的访问权限。
namespace: development
subjects:
- kind: User
name: dave # 'name' 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
ClusterRoleBinding
ClusterRoleBinding可以跨整个集群完成访问权限的授予
示例
- 通过命令行创建
kubectl create clusterrolebinding read-secrets-global --user=user1 --clusterrole=secret-reader
- 通过yaml创建
apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # 'name' 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
实战
-
生成kubeconfig文件,可执行自动生成kubeconfig文件的脚本，参考：https://blog.csdn.net/2401_86274572/article/details/14089867
-
k8s创建一个namespace为demo1，创建一个角色my-role1,赋予角色查看demo1中所有pod的权限
kubectl create ns demo1
kubectl create role my-role1 -n demo1 --resource=pod --verb=list
3. 创建一个rolebinding,为用户user1绑定角色my-role1
kubectl create rolebinding my-rolebind1 -n demo1 --user user1 --role my-role1
- 现在可以通过指定kubeconfig去访问k8s的pod资源了
k get pods -n demo1 --kubeconfig=./user1.config
5. 因为角色只给了查看demo1中pod的权限，所以如果查看其他资源仍然是没有权限的
如查看demo1中service资源
或者查看其他namespace中的pod资源
总结
至此如何创建kubeconfig文件和如何使用RBAC鉴权都介绍过了，这个有啥用呢？
当我们有多套k8s环境时，我们就可以使用kubeconfig合并多个k8s集群进行管理，比较方便