Support ID providers that don't support obtaining an API token via WWW-Authenticate challenge

[astefanutti]

Documentation for OpenShift can be found at:

• https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html#oauth
• https://docs.openshift.com/container-platform/latest/install_config/configuring_authentication.html#install-config-configuring-authentication

[SEJeff]

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.

[astefanutti]

Agreed. It is possible to use an access token obtained separately, though that less than ideal.

[edevil]

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

[astefanutti]

@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.

[edevil]

@astefanutti Sure, I'll create the ticket. Thanks!

[andycmaj]

also ran into DigitalOcean auth, which uses ExecCredential. created https://github.com/astefanutti/kubebox/issues/53

[astefanutti]

Let me close this as authentication has been improved in separate issues.