我确实了解 RBAC，并且我能够使用规则和主题创建角色，将它们与用户绑定。
例如这个角色只能列出 pods
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: development
name: list-pods
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "list"]
现在我们为我们拥有的每个环境（dev、staging、prd）使用命名空间。现在我必须如何为不同命名空间中的用户提供这个角色？我是否必须创建一个 clusterRole 并将其与正常的角色绑定绑定，或者我必须为 dev 编写一次上述 .yaml，为 uat 编写一次，为 prd 编写一次？是否有关于如何处理这些案件的规则？
【问题讨论】：
标签： kubernetes
现在我必须如何向不同命名空间中的用户提供此角色？
如果您希望能够限制在每个 Namespace 的基础上为该 Subject 列出 Pods 的能力，您可以这样做。例如，您可能不希望人们能够在kube-system（或假设的internal-security 命名空间）中看到Pods。以列出Pods 的能力为例，这很难想象，但列出或查看Secrets 或ConfigMaps 的能力可能会使这更具体。大概Subject 可以查看Secrets 的自己的 项目——甚至可能不能——但不能查看公司内的其他项目。那种东西。
当考虑将exec 转换为任意Pods 的能力时，这一点变得更加真实——因为这是我能想到的对集群中应用程序的安全性和机密性的最大风险。
我是否必须创建一个 clusterRole 并将其与普通角色绑定绑定
不，有人为此目的使用ClusterRoleBinding。 “必须”不是正确的问题；这取决于您是否希望绑定应用于所有命名空间，当前和未来。
还是我必须为 dev 编写一次上述 .yaml，为 uat 编写一次，为 prd 编写一次？
这还取决于访问它们的Namespaces 是否具有相同的风险和相同的Subjects。
是否有关于如何处理这些情况的规则？
绝对不是；集群安全没有万能的。这完全取决于人们试图降低的风险类型。
作为您的考虑，您没有义务使用 RBAC 约束：您当然可以为每个 Subject 创建一个 ClusterRoleBinding 到 cluster-admin ClusterRole 和瞧，没有更多的权限管理.也没有更多的保障措施，但这就是范围。
【讨论】：
在您的具体情况下，我将创建一个具有所需权限的单个集群角色，然后通过角色绑定将其绑定到相关命名空间中的适当主题。
【讨论】：