auth-provider-gcp: support using alternate credentials

[theobarberbany]

Currently, as far as I can tell,auth-provider-gcp only supports using the default gcp service account attached to the GCE VM. (https://github.com/kubernetes/cloud-provider-gcp/blob/master/pkg/gcpcredential/gcpcredential.go#L171-L226).

It would be great to additional authentication methods when making credentials requests, e.g support service account impersonation, or passing GOOGLE_APPLICATION_CREDENTIALS. This is because we have a use case where we don't want to provide credentials via roles attached to the default service account.

It looks like the CredentialProviderConfig allows for either passing args, or env vars: https://kubernetes.io/docs/tasks/administer-cluster/kubelet-credential-provider/

If this is something the project would be open to, I'd be happy to work on it!

[k8s-ci-robot]

This issue is currently awaiting triage.

If the repository mantainers determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[elmiko]

cc @cheftako could use your advise on this one

talking about this at sig meeting today, we agree that this sounds reasonable, @cheftako will followup with maintainers. just a note, @theobarberbany is willing to followup with a PR for this if we agree about making the changes.

[theobarberbany]

Hey @cheftako, I was wondering if there had been any progress here? If we agree on making the changes, I'm happy to follow up with a PR! :)

[elmiko]

@theobarberbany you've got a couple thumbs up on the original issue, i think it makes sense to propose a PR. we can bring this up at the next sig meeting to see if there is objection. from the sounds of your original issue, i don't think this will be too controversial as we are preserving the original behavior and adding new options. do i have that correct?

[elmiko]

we are discussing this at the SIG meeting today, a question about which specific auth workflows are needed has come up. it sounds like @theobarberbany is proposing something more general, in line with some of the other ccms.

the default service account auth is the main method of focus here for Theo's work.

@cheftako has offered to get some of the appropriate folks here for the discussion

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[theobarberbany]

/remove-lifecycle stale