【问题标题】:How does the GKE metadata server work in Workload IdentityGKE 元数据服务器如何在 Workload Identity 中工作
【发布时间】:2020-02-28 02:33:28
【问题描述】:

我最近一直在使用GKE Workload Identity 功能。我有兴趣更详细地了解 gke-metadata-server 组件的工作原理。

  1. GCP 客户端代码(gcloud 或其他语言 SDK)属于 GCE 元数据方法
  2. http://metadata.google.internal/path提出请求
  3. (猜测)在我的节点池上设置 GKE_METADATA_SERVER 会将其配置为解析到该节点上的 gke-metadata-server pod。
  4. (猜测)gke-metadata-server 带有 --privileged 和主机网络的 pod 可以确定源(pod IP?),然后查找 pod 及其服务帐户以检查 iam.gke.io/gcp-service-account 注释。李>
  5. (猜测)代理调用元数据服务器并使用 pod 的“伪”身份集(例如 [PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]])来获取在其 Kubernetes 服务帐户上注释的服务帐户的令牌。
  6. 如果此帐户对服务帐户具有令牌创建者/工作负载 ID 用户权限,则可能来自 GCP 的响应是成功的并包含一个令牌,然后将其打包并设置回调用 pod,以便对其他 Google API 进行经过身份验证的调用。

我想我现在的主要难题是验证调用 pod 的身份。最初我认为这将使用 TokenReview API,但现在我不确定 Google 客户端工具如何知道使用挂载到 pod 中的服务帐户令牌...

编辑后续问题:

Q1:在第 2 步和第 3 步之间,对 metadata.google.internal 的请求是否通过节点池上的设置 GKE_METADATA_SERVER 路由到 GKE 元数据代理?

Q2:为什么元数据服务器 pod 需要主机联网?

Q3:在此处的视频中:https://youtu.be/s4NYEJDFc0M?t=2243 假定 Pod 会进行 GCP 调用。 GKE 元数据服务器如何识别调用启动进程的 pod?

【问题讨论】:

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


    【解决方案1】:

    在详细介绍之前,请先熟悉这些组件:

    OIDC 提供者:在 Google 的基础架构上运行,提供集群特定的元数据并签署授权的 JWT。

    GKE 元数据服务器:它作为 DaemonSet 运行,这意味着每个节点上都有一个实例,公开 pod 特定的元数据服务器(它将提供与旧客户端库的向后兼容性),模拟现有的节点元数据服务器。

    Google IAM:颁发访问令牌、验证绑定、验证 OIDC 签名。

    Google 云:接受访问令牌,几乎可以做任何事情。

    JWT:JSON Web 令牌

    mTLS:相互传输层安全

    以下步骤解释了 GKE 元数据服务器组件的工作原理:

    第 1 步:授权用户将集群绑定到命名空间。

    第 2 步:Workload 尝试使用客户端库访问 Google Cloud 服务。

    第 3 步:GKE 元数据服务器将向控制平面请求 OIDC 签名的 JWT。该连接使用带有节点凭据的双向 TLS (mTLS) 连接进行身份验证。

    第 4 步:然后 GKE 元数据服务器将使用 OIDC 签名的 JWT 向 [identity namespace]/[Kubernetes service account] 请求访问令牌我是。 IAM 将验证身份命名空间和 OIDC 提供程序中是否存在适当的绑定。

    第 5 步:然后 IAM 验证它是否由集群的正确 OIDC 提供商签名。然后它将返回 [identity namespace]/[kubernetes service account] 的访问令牌。

    第 6 步:然后元数据服务器将刚刚获得的访问令牌发送回 IAM。然后,IAM 将在验证适当的绑定后将其交换为短期 GCP 服务帐户令牌。

    第 7 步:然后 GKE 元数据服务器将 GCP 服务帐户令牌返回给工作负载。

    第 8 步:工作负载随后可以使用该令牌调用任何 Google Cloud Service。

    我还找到了一个关于 Workload Identity 的 video,您会发现它很有用。

    编辑后续问题的答案:

    以下是您后续问题的答案:

    Q1:在第 2 步和第 3 步之间,对 metadata.google.internal 的请求是否通过在节点池上设置 GKE_METADATA_SERVER 路由到 gke 元数据代理?

    你是对的,GKE_METADATA_SERVER 设置在节点池上。这会将元数据 API 公开给与 V1 计算元数据 API 兼容的工作负载。一旦工作负载尝试访问 Google Cloud 服务,GKE 元数据服务器会执行查找(元数据服务器会检查列表中是否存在 IP 与请求的传入 IP 匹配的 pod),然后再继续从其请求 OIDC 令牌控制平面。

    请记住,只有在集群级别启用了 Workload Identity,才能启用 GKE_METADATA_SERVER 枚举功能。

    Q2:为什么元数据服务器 pod 需要主机联网?

    gke-metadata-server 会拦截所有来自 pod 的 GCE 元数据服务器请求,但不会拦截使用主机网络的 pod。

    Q3:GKE 元数据服务器如何识别发出调用以启动进程的 pod?

    使用 iptables 规则识别 pod。

    【讨论】:

    • 非常感谢这个详细的解释和有用的视频——关于这个主题的细节很难得到!我还有几个问题。所以 cmets 不允许在我的问题末尾添加新行。
    • 这是我的荣幸。我很高兴它对你有所帮助。我已通过添加您的问题的答案来更新我的答案。
    • 很好的解释,你能澄清一下第3步吗?请求 OIDC 签名的 JWT 是否意味着从与尝试进行身份验证的 Kubernetes ServiceAccount 关联的 Secret 中检索 JWT?如果不是,这是使用允许您执行此操作的特定 Kubernetes 资源吗? JWT 的声明是什么?
    • 是的,在第 3 步中,GKE 元数据服务器从 Kubernetes API 服务器请求 JSON Web Token (JWT),Kubernetes API 服务器是 Kubernetes 控制平面的前端组件。之后,Kubernetes API 服务器使用 JWT for Kubernetes 服务帐户进行回复。 (关于 JWT 声明的问题的答案将在下一条评论中,因为我用完了字符。)
    • 由于 GKE 元数据服务器正在请求 OpenID Connect (OIDC) 签名的 JWT,因此保留其声明类型。请记住,OIDC 是建立在 OAuth 2.0 之上的基于标准的身份验证协议。此link 为您提供在 ID 令牌中使用的声明,用于 OpenID Connect (OIDC) 使用的所有 OAuth 2.0 流。
    猜你喜欢
    • 2020-05-01
    • 2020-07-29
    • 2021-04-06
    • 2021-05-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-06-09
    相关资源
    最近更新 更多