基于角色的访问控制(RBAC) 是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。 在此上下文中,权限是单个用户执行特定任务的能力, 例如查看、创建或修改文件。
被启用之后,RBAC(基于角色的访问控制)使用 rbac.authorization.k8s.io API 组来驱动鉴权决策,从而允许管理员通过 Kubernetes API 动态配置权限策略。
要启用 RBAC,请使用 --authorization-mode = RBAC 启动 API 服务器。
查看默认配置文件的授权配置即可
cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep authorization
User Account:用户,这是有外部独立服务进行管理的,管理员进行私钥的分配,用户可以使用 KeyStone或者 Goolge 帐号,甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象,所以用户不能通过集群内部的 API 来进行管理
Group:组,这是用来关联多个账户的,集群中有一些默认创建的组,比如cluster-admin。
Service Account:服务帐号,通过Kubernetes API 来管理的一些用户帐号,和 namespace 进行关联的,适用于集群内部运行的应用程序,需要通过 API 来完成权限认证,所以在集群内部进行权限操作,都需要使用到 ServiceAccount,这也是本文的重点。
Role:包含一组代表相关权限的规则。 这些权限是纯粹累加的(不存在拒绝某操作的规则)。
RoleBinding:将角色中定义的权限赋予一个或者一组用户。 它包含若干主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权。RoleBinding 也可以引用 ClusterRole。
ClusterRole:包含一组代表相关权限的规则。 这些权限是纯粹累加的(不存在拒绝某操作的规则)。
ClusterRoleBinding:将角色中定义的权限赋予一个或者一组用户。 它包含若干 主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。 ClusterRoleBinding 在集群范围执行授权。
如果你不记得资源有哪些了,可以查看clusterrole admin的。例如,查看pod的资源。
kubectl get clusterrole admin -o yaml | grep pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
resources: ["pods"]
verbs: ["get", "watch", "list"]
下面的例子中的 RoleBinding 将 “pod-reader” Role 授予在 “default” 名字空间中的用户 “lady_killer9”。 这样,用户 “lady_killer9” 就具有了读取 “default” 名字空间中所有 Pod 的权限。
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "lady_killer9" 读取 "default" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: User
name: lady_killer9 # "name" 是区分大小写的
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: Role # 此字段必须是 Role 或 ClusterRole
name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
apiGroup: rbac.authorization.k8s.io
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"]
要跨整个集群完成访问权限的授予,你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 “manager” 组内的所有用户访问任何名字空间中的 Secrets。
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
在名字为app-team1的namespace下创建一个名为cicd-token的serviceAccount
命令
kubectl create ns app-team1
kubectl create sa cicd-token -n app-team1
结果
创建一个名为deployment-clusterrole的clusterrole,该clusterrole只允许创建Deployment、Daemonset、Statefulset的create操作。
将前面的模版改一下,deployment-clusterrole.yaml内容如下:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: deployment-clusterrole
rules:
- apiGroups: [""]
resources: ["deployments","daemonsets","statefulsets"]
verbs: ["create"]
命令
kubectl create -f deployment-clusterrole.yaml
结果
创建一个RoleBinding,名为deployment-rolebinding,将上面的clusterrole绑定到serviceaccount上。
deployment-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: deployment-rolebinding
namespace: app-team1
subjects:
- kind: ServiceAccount
name: cicd-token
namespace: app-team1
roleRef:
# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
kind: ClusterRole
name: deployment-clusterrole
apiGroup: rbac.authorization.k8s.io
命令
kubectl create -f deployment-rolebinding.yaml
结果
删除使用delete即可,例如,删除前面创建的rolebinding和clusterrole
命令
kubectl delete rolebinding deployment-rolebinding -n app-team1
kubectl delete clusterrole deployment-clusterrole
结果
k8s-鉴权概述
k8s-RBAC
阿里云-k8s安全之访问控制
更多k8s相关内容,请看文章:k8s学习-思维导图与学习笔记