【问题标题】:Forbidden after enabling Google Cloud Groups RBAC in GKE在 GKE 中启用 Google Cloud Groups RBAC 后被禁止
【发布时间】:2022-01-28 00:19:41
【问题描述】:

我们正在现有 GKE 集群中启用 Google Cloud Groups RBAC。

为此,我们首先在 Workspace 中创建了所有组,并根据文档创建了所需的“gke-security-groups@ourdomain.com”。

这些组是在 Workspace 中创建的,并与 Active Directory 集成以实现单点登录。

如文档所述,所有组都是“gke-security-groups@ourdomain”的成员。并且所有组都可以查看成员。

集群已更新以启用 Google Cloud Groups RBAC 标志,我们将值指定为“gke-security-groups@ourdomain.com”。

然后,我们将其中一个组(我们称之为 group_a@ourdomain.com)添加到 IAM 并分配了一个自定义角色,该角色只允许访问:

"container.apiServices.get",
"container.apiServices.list",
"container.clusters.getCredentials",
"container.clusters.get",
"container.clusters.list",

这只是用户能够登录到 Kubernetes 集群并从那里能够应用 Kubernetes RBAC 的最低要求。

在 Kubernetes 中,我们应用了一个角色,它提供特定命名空间中的 pod 列表,以及一个角色绑定,用于指定我们刚刚添加到 IAM 的组。

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-role
  namespace: custom-namespace
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-rolebinding
  namespace: custom-namespace
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: Group
    name: group_a@ourdomain.com

到目前为止,一切看起来都很好。但是,当尝试使用属于组“group_a@ourdomain.com”的用户列出此命名空间的 pod 时,我们得到:

来自服务器的错误(禁止):Pod 被禁止:用户 “my-user@ourdomain.com”无法列出 API 组“”中的资源“pod” 在命名空间“custom-namespace”中:需要 ["container.pods.list"] 之一 权限。

当然,如果我将 container.pods.list 赋予 group_a@ourdomain 分配的角色,我可以列出 pod,但它会为所有命名空间打开,因为 GCloud 中的此权限是全局的。

我在这里错过了什么?

不确定这是否相关,但我们在 gcloud 中的组织名为“my-company.io”,而 SSO 的组名为“...@groups.my-company.io”,并且gke-security-groups 组也是使用“groups.my-company.io”域创建的。

另外,如果我直接指定用户而不是 RoleBinding 中的组,它可以工作。

【问题讨论】:

    标签: kubernetes google-cloud-platform google-kubernetes-engine kubernetes-rbac


    【解决方案1】:

    事实证明这是一个关于区分大小写的字符串的问题,与 RBAC 中定义的实际规则无关,这些规则按预期工作。

    组的名称是在 Azure AD 中使用驼峰式模型创建的。这些组名随后在 Google Workspace 中全部小写。

    Azure AD 中的示例: thisIsOneGroup@groups.mycompany.com

    在 RBAC 中配置的示例,如 Google Workspace 中所示: thissonegroup@groups.mycompany.com

    我们从 Google Workspace 用户界面复制了所有小写的名称,并将它们放入绑定中,这导致了问题。 Kubernetes GKE 区分大小写,并且绑定中配置的名称与 Google Workspace 中配置的电子邮件不匹配。

    将 RBAC 绑定更改为具有相同格式后,一切都按预期工作。

    【讨论】:

      【解决方案2】:

      您似乎正在尝试授予对扩展程序和应用程序 API 组中的部署的访问权限。这需要用户在您的角色规则中指定扩展程序和应用程序 api 组:

      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        verbs:
        - '*'
      - apiGroups:
        - extensions
        - apps
        resources:
        - deployments
        - replicasets
        verbs:
        - '*'
      

      我也可以建议您重新创建角色和角色绑定。您也可以访问以下线程作为参考RBAC issue : Error from server (Forbidden):

      已编辑 012622:

      您能否确认您提供了凭据或配置文件(清单、YAML)?如您所知,此信息由 Kubernetes 和默认服务帐户提供。您可以通过运行来验证它:

      $ kubectl auth can-i get pods
      

      让我告诉您,您需要为您的帐户使用的帐户类型是“服务帐户”。要创建具有更广泛权限的新服务帐户,以下是 YAML 示例:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        namespace: default
        name: pod-read-role
      rules:
      - apiGroups: [""] # "" indicates the core API group
        resources: ["pods"]
        verbs: ["get", "watch", "list"]
       
      ---
      apiVersion: v1
      kind: ServiceAccount
      metadata:
      name: pod-read-sa
       
      ---
      kind: RoleBinding
      apiVersion: rbac.authorization.k8s.io/v1
      metadata:
      name: pod-read-rolebinding
      namespace: default
      subjects:
      - kind: ServiceAccount
      name: pod-read-sa
      apiGroup: ""
      roleRef:
      kind: Role
      name: pod-read-role
      apiGroup: ""
      

      请使用以下线程作为参考。

      【讨论】:

      • 您好,感谢您的建议,但这不适用于我的情况。此人的角色配置错误,他想授予对那些额外 apiGroups 的访问权限,但在我的情况下,它只是列出 pod。我在帖子中添加了一个编辑,因为我忘了说当在绑定中使用用户而不是组时,一切都会按预期工作。
      • 我刚刚编辑了答案并添加了更多信息。请检查并按照我给你的步骤操作。
      • 嗨 Nestor,原来是小写/大写的问题 -.- 在 AD 中创建的组的名称采用驼峰式格式,但在 RBAC 规则中全部写入小写,这就是问题所在,系统区分大小写。用正确的格式编写 RBAC 规则后,一切都很好。我忘了回答我的问题
      猜你喜欢
      • 2018-02-07
      • 2020-10-23
      • 1970-01-01
      • 2020-07-13
      • 2021-11-15
      • 1970-01-01
      • 2021-10-03
      • 1970-01-01
      • 2018-05-25
      相关资源
      最近更新 更多