Role
和 ClusterRole
有什么区别?
我应该什么时候创建一个或另一个?
我不太明白它们之间的区别。
来自文档:
角色只能用于授予对单个命名空间内的资源的访问权限。
示例:列出命名空间中的所有 pod
ClusterRole 可用于授予与 Role 相同的权限,但是 因为它们是集群范围的,所以它们也可用于授予访问权限 至:
cluster-scoped resources (like nodes) non-resource endpoints (like “/healthz”) namespaced resources (like pods) across all namespaces (needed to run kubectl get pods --all-namespaces, for example)
示例:列出所有命名空间中的所有 Pod。获取所有节点的列表及其公共 IP。
Kubernetes 中角色和集群角色的区别:
属性 | 角色 | 集群角色 |
---|---|---|
目的 | 定义特定命名空间内的权限 | 定义集群范围的权限 |
范围 | 命名空间范围 | 集群范围 |
资源类型 | 可以为命名空间内的资源定义规则(例如,pod、服务、部署) | 可以为集群范围的资源(例如节点、持久卷)和跨所有命名空间 + 非资源 URL (/healthz) 的命名空间资源定义规则 |
绑定 | 绑定到同一命名空间内的 RoleBinding 对象 | 绑定到 ClusterRoleBinding 对象 |
示例用例 | 授予管理特定命名空间内资源的权限 | 授予管理集群范围资源或跨多个命名空间的资源的权限 |
最佳实践 | 使用角色在命名空间内进行细粒度的访问控制 | 谨慎使用 ClusterRoles,因为它们在整个集群中授予广泛的权限 |
让我们看看您为什么需要它们
1. 常规角色仅允许访问该角色所在同一命名空间中的资源。如果您希望允许某人跨不同命名空间访问资源,则必须在每个命名空间中创建一个 Role 和 RoleBinding。
2. 如果您想将其扩展到所有命名空间,那么您需要在每个命名空间中创建相同的 Role 和 RoleBinding。创建附加命名空间时,您还必须记住在那里创建两个资源。
3. 许多资源都没有命名空间(例如节点、持久卷、命名空间、存储类、PodSecurityPolicy 等)。因此,常规角色无法授予对这些资源或非资源 URL 的访问权限,但 ClusterRoles 可以。
参考:Kubernetes 的实际应用。希望这对您有帮助!
集群角色还允许跨命名空间重用公共权限集(通过角色绑定)。 引导管理、编辑和查看集群角色是典型的示例。