Kubernetes Role-Based Access Control(RBAC)
Last updated
Last updated
Learn & practice AWS Hacking: Learn & practice GCP Hacking:
Kubernetes 有一个 名为基于角色的访问控制 () 的授权模块，帮助设置 API 服务器的使用权限。
RBAC 的权限模型由 三个独立部分 构成：
Role\ClusterRole – 实际的权限。它包含 规则，表示一组权限。每个规则包含 和 。动词是将应用于资源的操作。
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" 用于单个资源。
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 允许特定用户运行：
权限是累加的，所以如果你有一个 clusterRole 具有“列出”和“删除”秘密的权限，你可以将其与一个具有“获取”权限的 Role 结合使用。因此，请始终注意并测试你的角色和权限，并指定允许的内容，因为默认情况下所有内容都是被拒绝的。
(此信息来自 )
角色绑定将角色中定义的权限授予用户或用户集。它包含一个主题列表（用户、组或服务账户）和对被授予角色的引用。RoleBinding 在特定 命名空间 内授予权限，而 ClusterRoleBinding 则在 集群范围 内授予该访问权限。
学习和实践 AWS 黑客技术： 学习和实践 GCP 黑客技术：
查看 !
加入 💬 或 或 在 Twitter 上关注 🐦 .
通过向 和 GitHub 仓库提交 PR 分享黑客技巧。
POST
create
GET, HEAD
get（针对单个资源），list（针对集合，包括完整对象内容），watch（用于监视单个资源或资源集合）
PUT
update
PATCH
patch
DELETE
delete（针对单个资源），deletecollection（针对集合）
