Question

假设我们有一个Kubernetes集群，其中Google作为OIDC提供商进行身份验证。每个使用该群集的开发人员都拥有~/.kube/config，并配置了以下内容：

user:
    auth-provider:
      config:
        client-id: <client-id>
        client-secret: <client-secret>
        id-token: <id-token>
        idp-issuer-url: https://accounts.google.com
        refresh-token: <refresh-token>

开发人员离开组织后，将其从Google登录名中删除，他无法使用此~/.kube/config来访问kubernetes资源，因为他需要登录到Google，但他现在不能这样做。

但是客户端ID和机密信息仍然泄露。

client-secret此处的泄漏可能与安全性有关吗？
非组织成员可以使用组织成员来利用它吗？
此client-id和client-secret是否可以用于制作其他应用，并可以用来使现有组织用户登录并代表该现有用户访问ID令牌？

请提出建议。

PS：此客户端ID和客户端秘密的凭据类型为“其他”，而不是具有重定向URL的“ Web应用程序”。

Answer 1

首先，下班后禁止使用可信的凭据和访问帐户，这就是为什么开发人员下班后无法访问此类数据的原因。

Kubernetes中OpenID的流向

登录到您的身份提供商

您的身份提供商将为您提供一个access_token，id_token和refresh_token

使用kubectl时，请将您的id_token与--token标志一起使用，或将其直接添加到您的kubeconfig中

kubectl在名为Authorization的标头中将您的id_token发送到API服务器

API服务器将通过检查配置中命名的证书来确保JWT签名有效

检查以确保id_token尚未过期

确保用户已获得授权

获得授权，API服务器将对kubectl返回响应

kubectl向用户提供反馈

对您来说，最重要的要点是 5 ， 6 ， 7 。您的客户的JWT无效，因此离开工作和其帐户凭据的用户（或具有此类凭据的其他组织的成员）无法访问您的集群。

id_token无法撤消，就像证书一样，因此应该是短暂的。如果不使用kubectl proxy命令或注入id_token的反向代理，就无法通过简单的方法对Kubernetes仪表板进行身份验证。

更多信息，请参见kubernetes-cluster-access。因此，假设您不必担心泄漏client_id和

您也可以删除群集/上下文/用户条目，例如：

$ kubectl config unset users.gke_project_zone_name

Client_secret现在对于k8s oidc配置是可选的，这意味着它可以支持公共客户端（有或没有client_secret）和机密客户端（对于每个kubectl用户都具有client_secret）。

因此，对您的每一个问题的回答都是“否”，无需担心安全性问题。

希望对您有帮助。

非组织成员可以利用Google客户ID和客户机密凭据吗？

1 个答案: