Closed astefanutti closed 4 years ago
Definitely a problem on clusters that auth primarily via oidc, like every single CoreOS tectonic cluster, or anything setup using dex for tying into enterprise LDAP auth or any other provider.
Agreed. It is possible to use an access token obtained separately, though that less than ideal.
I suppose this is why I can't login to GKE clusters? They use an auth-provider:
- name: gke_...
user:
auth-provider:
config:
access-token: ...
cmd-args: config config-helper --format=json
cmd-path: /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/gcloud
expiry: "2019-07-05T10:46:51Z"
expiry-key: '{.credential.token_expiry}'
token-key: '{.credential.access_token}'
name: gcp
@edevil while Kubebox support OIDC, it does not support the cmd-args
/ cmd-path
fields yet from the auth-provider
config for the login / token generation. We have similar work to do with EKS (#32). Would you mind creating an issue specifically for GKE as this is something we definitely want to support?
In the meaning, you should be able to connect to GKE using the access token.
@astefanutti Sure, I'll create the ticket. Thanks!
also ran into DigitalOcean auth, which uses ExecCredential
. created https://github.com/astefanutti/kubebox/issues/53
Let me close this as authentication has been improved in separate issues.
Documentation for OpenShift can be found at: