auth/gcp: configurable scopes for gcp default credentials

[ahmetb]

What this PR does / why we need it:

• add config.scopes field comma-separated scope URLs, to be used with Google
  Application Default Credentials (i.e. GOOGLE_APPLICATION_CREDENTIALS env)
• users now should be able to set a gserviceaccount key in GOOGLE_APPLICATION_CREDENTIALS
  env, craft a kubeconfig file with GKE master IP+CA cert and should be able to authenticate
  to GKE in headless mode without requiring gcloud CLI, and they can now use the
  email address of the gserviceaccount in RBAC role bindings and not use Google Cloud IAM at all.
• gcp default scopes now include userinfo.email scope, so authenticating to GKE
  using gserviceaccount keys can now be done without gcloud as well.
• since userinfo.email scope is now a default, users who have existing RBAC bindings
  that use numeric uniqueID of the gserviceaccount will be broken (this behavior was
  never documented/guaranteed). from now on email address of the service account
  should be used as the subject in RBAC Role Bindings.

Release note:

Google Cloud Service Account email addresses can now be used in RBAC
Role bindings since the default scopes now include the "userinfo.email"
scope. This is a breaking change if the numeric uniqueIDs of the Google
service accounts were being used in RBAC role bindings. The behavior
can be overridden by explicitly specifying the scope values as
comma-separated string in the "users[*].config.scopes" field in the
KUBECONFIG file.

/assign @cjcullen
/sig gcp

[ahmetb]

I think type gcpAuthProvider godoc in this file needs updating to talk about this new "scopes" field.
/hold

[ahmetb]

/hold cancel

[cjcullen]

FYI @ericchiang
This only applies to the "old" GCP auth-provider, not the command-based one.

[cjcullen]

Can you add a unittest that checks that:

1. No scopes in the gcpConfig produces a google.TokenSource with the correct default scopes.
2. The scopes in the gcpConfig are correctly passed into the google.TokenSource.
3. Scopes in a gcpConfig when useCmd is true results in an error.

[ahmetb]

@cjcullen Methods in gcp.go were not well testable. So I split it into multiple methods, and wrote tests for them.

Please take a look at ad4fdc7.

1. No scopes in the gcpConfig produces a google.TokenSource with the correct default scopes.

See Test_parseScopes method.

2. The scopes in the gcpConfig are correctly passed into the google.TokenSource.

I'm having trouble inspecting the google.TokenSource, as the method returns oauth2.reuseTokenSource which I cannot dig in without using reflection. But I'm now testing the parsing of scopes field. (see func parseScopes.)

3. Scopes in a gcpConfig when useCmd is true results in an error.

See Test_tokenSource_cmdCannotBeUsedWithScopes method.

[cjcullen]

I like the refactor.
/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ahmetb, cjcullen

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

• staging/src/k8s.io/client-go/plugin/pkg/client/auth/gcp/OWNERS [cjcullen]

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[ericchiang]

/test pull-kubernetes-e2e-kops-aws

[k8s-github-robot]

/test all [submit-queue is verifying that this PR is safe to merge]

[fejta-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel comment for consistent failures.

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 58903, 58141, 58900). If you want to cherry-pick this change to another branch, please follow the instructions here.

[mattnworb]

For anyone else who finds this in the future and is confused like me as to how some gserviceaccount's can successfully be referred to in a RoleBinding before this change and some other's can't, I've traced it down to this:

if you use gcloud container clusters get-credentials to populate the KUBECONFIG with credentials related to the service account configured in gcloud, then if that service account was added to gcloud via gcloud auth activate-service-account, then the token returned by gcloud seems to already have access to the userinfo.email scope. This then allows the token passed by kubectl to a GKE cluster to have the email retrieved for it, which allows the token to be correlated to a gserviceaccount email address in your RoleBinding.

If instead the active service account in gcloud is the GCE instance's default service account, this does not have access to the userinfo.email scope, so the RoleBinding (today, before this PR) has to refer to the numeric ID (which can be found via gcloud iam service-accounts describe <email/ID>).

[mattnworb]

also - @ahmetb thanks for making the behavior consistent going forward 😄

[ahmetb]

@mattnworb thanks for the clarification!

Yes, if your [Cluster]RoleBinding object previously used a subject name like 105883778249443408408, starting from kubectl 1.10, you just need to use the full service account email foo@PROJECT-NAME.iam.gserviceaccount.com.

This is a breaking change, if it interrupts you, you can go back to using kubectl 1.9 or better: you can edit ~/.kube/config file to manually add a users[*].config.scopes field that has value "https://www.googleapis.com/auth/cloud-platform". This way the email won't work and you'll get the old behavior.

The numeric account name behavior was never documented and meant to be used that way, so hopefully addressing this early on before this use case gets popular will prevent us from dealing with this down the road!