非组织成员可以利用Google客户ID和客户机密凭据吗? [英] Can Google client-id and client-secret credential be exploited by a non org member?

问题描述

假设我们有一个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:此client-id和client-secret的凭据类型为其他"，而不是带有重定向URL的"Web应用程序".

解决方案

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

Kubernetes中OpenID的流向

1. 登录到您的身份提供商
2. 您的身份提供者将为您提供一个access_token，id_token和一个refresh_token
3. 使用kubectl时，请将您的id_token与--token标志一起使用，或将其直接添加到kubeconfig中
4. kubectl在名为Authorization的标头中将您的id_token发送到API服务器
5. API服务器将通过检查配置中命名的证书来确保JWT签名有效
6. 检查以确保id_token尚未过期
7. 确保用户已获得授权
8. 获得授权，API服务器将对kubectl返回响应
9. 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

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

因此，对您的每一个问题的回答都是否"，无需担心安全性方面的问题.

希望对您有帮助.

Say we have a kubernetes cluster with Google as the OIDC provider for authentication. Every developer using that cluster has the ~/.kube/config with following configured:

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>

When the developer leaves the organisation he is removed from Google login and he can not use this ~/.kube/config to access kubernetes resources as he would need to login to Google, but he cannot do that now.

But the client id and secret is still leaked.

• client-secret leakage here can be of any security concern?
• Can it be exploited by a non org member using an org member?
• Can this client-id and client-secret be used to make a different app and be exploited to make existing organization users to sign in and gain access to the ID-token on that existing user behalf?

Please suggest.

PS: the credential type of this client-id and client-secret is "Other" and not a "Web application" with redirect url.

解决方案

First and foremost, after leaving job is forbid to use confident credentials and access account, that's why developers don't have access to such data after leaving work.

Flow of OpenID in Kubernetes:

1. Login to your identity provider
2. Your identity provider will provide you with an access_token, id_token and a refresh_token
3. When using kubectl, use your id_token with the --token flag or add it directly to your kubeconfig
4. kubectl sends your id_token in a header called Authorization to the API server
5. The API server will make sure the JWT signature is valid by checking against the certificate named in the configuration
6. Check to make sure the id_token hasn’t expired
7. Make sure the user is authorized
8. Once authorized the API server returns a response to kubectl
9. kubectl provides feedback to the user

To you most important points are 5, 6, 7. JWT of your client is not valid, so users who leave job and his account credentials (or members of other organization who have such credentials) cannot access your cluster.

The id_token can’t be revoked, it’s like a certificate so it should be short-lived. There’s no easy way to authenticate to the Kubernetes dashboard without using the kubectl proxy command or a reverse proxy that injects the id_token.

More information you can find here: kubernetes-cluster-access. So assuming you don't have to concern about leaking client_id and

You can also delete cluster/context/user entries too, e.g.:

$ kubectl config unset users.gke_project_zone_name

Client_secret is now optional for the k8s oidc config, which means that it can support public clients (with or without client_secret) and confidential clients (with client_secret, per kubectl user).

So answer for every for your questions is no, there is no need to concern about security aspect.

I hope it helps.

这篇关于非组织成员可以利用Google客户ID和客户机密凭据吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！