Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Kubernetes 有一个 名为基于角色的访问控制 (RBAC) 的授权模块,帮助设置 API 服务器的使用权限。
RBAC 的权限模型由 三个独立部分 构成:
Subject (用户、组或服务账户) – 将接收权限的对象。
RoleBinding\ClusterRoleBinding – Role\ClusterRole 和主体之间的连接。
“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" 用于单个资源。
(此信息来自 文档)
POST
create
GET, HEAD
get(针对单个资源),list(针对集合,包括完整对象内容),watch(用于监视单个资源或资源集合)
PUT
update
PATCH
patch
DELETE
delete(针对单个资源),deletecollection(针对集合)
Kubernetes 有时会使用专门的动词检查额外的权限。例如:
use
动词在 policy
API 组中的 podsecuritypolicies
资源上。
bind
和 escalate
动词在 rbac.authorization.k8s.io
API 组中的 roles
和 clusterroles
资源上。
impersonate
动词在核心 API 组中的 users
、groups
和 serviceaccounts
以及在 authentication.k8s.io
API 组中的 userextras
上。
您可以通过执行 kubectl api-resources --sort-by name -o wide
找到 每个资源支持的所有动词。
例如,您可以使用 ClusterRole 允许特定用户运行:
来自文档: 角色绑定将角色中定义的权限授予用户或用户集。它包含一个主题列表(用户、组或服务账户)和对被授予角色的引用。RoleBinding 在特定 命名空间 内授予权限,而 ClusterRoleBinding 则在 集群范围 内授予该访问权限。
权限是累加的,所以如果你有一个 clusterRole 具有“列出”和“删除”秘密的权限,你可以将其与一个具有“获取”权限的 Role 结合使用。因此,请始终注意并测试你的角色和权限,并指定允许的内容,因为默认情况下所有内容都是被拒绝的。
学习和实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE) 学习和实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)