kube icon indicating copy to clipboard operation
kube copied to clipboard

Problem when using the kube client with a GCP AuthProviderConfig using tame-oauth MetadataServerProviderInner

Open mgabriac opened this issue 2 years ago • 2 comments

Current and expected behavior

Hello, while using this configuration code

AuthInfo {
            auth_provider: Some(AuthProviderConfig{
                name: "gcp".to_string(),
                config: HashMap::from([(
                    "scopes".to_string(),
                    "https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/userinfo.email".to_string(),
             )]),
}),

the gcp oauth flow defaults to using the metadataserver for issuing access tokens, which is what I want in my case. The problem is the metadata server inside gke is accessible via http with no security. More precisely, this is the url used: http://metadata.google.internal/computeMetadata/v1/instance/service-accounts Note: google does not provide access to this via https.

The code used for getting a token expects https to be used for issuing the token, which makes this flow broken:

                #[cfg(feature = "openssl-tls")]
                let https =
                    hyper_openssl::HttpsConnector::new().map_err(Error::CreateOpensslHttpsConnector)?;
                #[cfg(all(not(feature = "openssl-tls"), feature = "rustls-tls"))]
                let https = hyper_rustls::HttpsConnectorBuilder::new()
                    .with_native_roots()
                    .https_only()
                    .enable_http1()
                    .build();


                let client = hyper::Client::builder().build::<_, hyper::Body>(https);

https://github.com/kube-rs/kube/blob/465ec9db8900ed592d017bffc3e8a6b9ee1fb06f/kube-client/src/client/auth/oauth.rs#LL113C1-L123C86

Possible solution

No response

Additional context

No response

Environment

the client is hosted inside GKE

Configuration and features

No response

Affected crates

kube-client

Would you like to work on fixing this bug?

None

mgabriac avatar Jun 09 '23 19:06 mgabriac

Hm, interesting.

When you say "inside gke" do you mean in-cluster (as in deployed inside a pod)? If so, shouldn't this be using the standard incluster configuration rather than the more advanced authentication flow?

clux avatar Jun 09 '23 19:06 clux

So indeed the code is running in a pod in a gke cluster, trying to access another gke kubernetes cluster. It uses a service account and I wanted to use this https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#applications to authenticate to the other cluster. This is a flow which is supported by tame-oauth. I think the incluster configuration is more for dealing with resources of the same cluster.

Thanks for the quick heads up !

mgabriac avatar Jun 09 '23 19:06 mgabriac