Kubernetes Role-Based Access Control(RBAC)
基于角色的访问控制(RBAC)
Kubernetes有一个名为基于角色的访问控制(RBAC)的授权模块,可帮助设置对API服务器的使用权限。
RBAC的权限模型由三个独立部分构成:
Subject(用户、组或ServiceAccount) – 将接收权限的对象。
RoleBinding\ClusterRoleBinding – Role\ClusterRole和Subject之间的连接。
“Roles”和“ClusterRoles”之间的区别仅在于角色将应用的位置 – “Role”将仅授予对一个特定命名空间的访问权限,而“ClusterRole”可用于集群中的所有命名空间。此外,ClusterRoles还可以授予对以下内容的访问权限:
集群范围资源(如节点)。
非资源端点(如/healthz)。
命名空间资源(如Pods),跨所有命名空间。
从Kubernetes 1.6开始,RBAC策略默认启用。但要启用RBAC,您可以使用类似以下内容:
模板
在Role或ClusterRole的模板中,您需要指定角色的名称,命名空间(在角色中),然后是角色的apiGroups,资源和动词:
apiGroups是一个包含此规则适用于的不同API命名空间的数组。例如,Pod定义使用apiVersion:v1。它可以具有值,如rbac.authorization.k8s.io或[*]。
资源是一个定义此规则适用于哪些资源的数组。您可以使用以下命令找到所有资源:
kubectl api-resources --namespaced=true
动词是一个包含允许的动词的数组。Kubernetes中的动词定义了您需要对资源应用的操作类型。例如,list动词用于集合,而"get"用于单个资源。
规则动词
(此信息摘自 文档)
HTTP动词 | 请求动词 |
---|---|
POST | create |
GET, HEAD | get(用于单个资源),list(用于集合,包括完整对象内容),watch(用于监视单个资源或资源集合) |
PUT | update |
PATCH | patch |
DELETE | delete(用于单个资源),deletecollection(用于集合) |
有时Kubernetes使用专门的动词检查附加权限的授权。例如:
在
policy
API组中对podsecuritypolicies
资源使用use
动词。在
rbac.authorization.k8s.io
API组中对roles
和clusterroles
资源使用bind
和escalate
动词。在核心API组中对
users
,groups
和serviceaccounts
使用impersonate
动词,并在authentication.k8s.io
API组中对userextras
使用。
您可以通过执行kubectl api-resources --sort-by name -o wide
找到每个资源支持的所有动词
示例
例如,您可以使用ClusterRole来允许特定用户运行:
RoleBinding和ClusterRoleBinding
来自文档: 一个role binding授予了在一个角色中定义的权限给一个用户或一组用户。它包含了一组主体(用户、组或服务账户)以及被授予的角色的引用。RoleBinding在特定的命名空间内授予权限,而ClusterRoleBinding则在整个集群范围内授予权限。
权限是可累加的,因此如果您有一个具有“list”和“delete” secrets 的 clusterRole,您可以将其与一个具有“get”的 Role 结合使用。因此,请注意并始终测试您的角色和权限,并指定允许的操作,因为默认情况下一切都被拒绝。
枚举 RBAC
滥用角色/ClusterRoles 进行特权升级
Abusing Roles/ClusterRoles in KubernetesLast updated