简体   繁体   English

RoleBinding和ClusterRoleBinding中的Kubernetes RBAC apiGroup字段

[英]Kubernetes RBAC apiGroup field in RoleBinding and ClusterRoleBinding

Why we need to write the apiGroup key in this definition again and again , if it is the same every time: 为什么我们需要一次又一次地在这个定义中编写apiGroup密钥,如果它每次都是相同的:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: web-rw-deployment
 namespace: some-web-app-ns
subjects:
- kind: User
 name: "joesmith@example.com"
 apiGroup: rbac.authorization.k8s.io
- kind: Group
 name: "webdevs"
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: web-rw-deployment
 apiGroup: rbac.authorization.k8s.io
  • this looks so redudant , that is repeating for everything 这看起来如此减少,这是重复一切
  • if we need to write it , what are the other values 如果我们需要写它,其他值是什么
  • if there are not other values for the field RBAC apiGroup , then k8s should assume that value automatically apiGroup: rbac.authorization.k8s.io 如果字段RBAC apiGroup没有其他值,那么k8s应该自动假设该值为apiGroup: rbac.authorization.k8s.io

this makes the yaml too redundant , is there any way to work around this. 这使得yaml过于冗余,有没有办法解决这个问题。 can we just skip this key? 我们可以跳过这个键吗? OR can we declare this somewhere globally. 或者我们可以在全球范围内宣布这个。

Good question. 好问题。 The rationale that I can think of is that there may be different APIs in the future that could be supported, for example, rbacv2.authorization.k8s.io and you wouldn't like to restrict references and subjects to just one for compatibility reasons. 我能想到的基本原理是,将来可能会支持不同的API,例如rbacv2.authorization.k8s.io ,出于兼容性原因,您不希望将引用和主题限制为仅一个。

My take on this is that it would be nice to have yet another optional global field for RoleBinding besides 'subjects' called something like 'bindingApigroup'. 我对此的看法是,除了名为'bindingApigroup'之类的' RoleBinding '之外,还有另一个可选的RoleBinding全局字段。 Feel free to open an issue : kind/feature, sig/auth and/or sig/api-machinery. 随意打开一个问题 :kind / feature,sig / auth和/或sig / api-machinery。

Also, there might be more rationale/details in the sig-auth design proposals. 此外, sig-auth设计方案中可能还有更多的基本原理/细节。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 Kubernetes:RoleBinding 和 ClusterRoleBinding 之间的差异 - Kubernetes: Diffrerence between RoleBinding and ClusterRoleBinding Kubernetes RBAC“由 RoleBinding 允许”但“无法列出资源” - Kubernetes RBAC "Allowed by RoleBinding" but "cannot list resource" 尽管有 RoleBinding(与 ClusterRoleBinding 相同),为什么在调用 Kubernetes API 时此 pod 会得到 403 Forbidden? - Why does this pod get a 403 Forbidden when calling the Kubernetes API despite a RoleBinding (same with ClusterRoleBinding)? kubernetes apigroup 子资源概览 - Overview of kubernetes apigroup subresources 有没有办法找到与 serviceAccount 相关的 RoleBinding/ClusterRoleBinding? - Is there a way to find the RoleBinding/ClusterRoleBinding related to a serviceAccount? 无法在 RoleBinding 和 ClusterRoleBinding 中拥有多个 ServiceAccount 主题? - Unable to have multiple ServiceAccount subjects in RoleBinding & ClusterRoleBinding? 关于在创建 ClusterRoleBinding 时使用 apiGroup 和 RoleRef 的问题 - Question about using apiGroup with RoleRef when creating ClusterRoleBinding AKS RBAC - 角色绑定无效 - AKS RBAC - Rolebinding has no effect 将 `ClusterRoleBinding` 转换为 `RoleBinding` 并为其设置命名空间以及使用 `kustomize` 的附加 `Deployment` 资源 - Converting `ClusterRoleBinding` to `RoleBinding` and setting namespace for it and an additional `Deployment` resource using `kustomize` 无法将ClusterRoleBinding附加到Kubernetes ServiceAccount - Unable to attach a ClusterRoleBinding to a Kubernetes ServiceAccount
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM