You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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);
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?
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.
Current and expected behavior
Hello,
while using this configuration code
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:
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
The text was updated successfully, but these errors were encountered: