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

/hold cancel

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

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.

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

I like the refactor.
/lgtm

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

/test pull-kubernetes-e2e-kops-aws

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

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

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.

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

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

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