This change is 

[APPROVALNOTIFIER] This PR is NOT APPROVED

The following people have approved this PR: liggitt

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

• OWNERS
• pkg/client/OWNERS [liggitt]
• test/OWNERS [liggitt]

We suggest the following people:
cc @smarterclayton
You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

cc @kubernetes/sig-auth-api-reviews @kubernetes/sig-auth-misc @cjcullen @deads2k

lgtm

@kubernetes/api-approvers for approval

Not sure if this needs to be hashed out in this PR, but we were looking at passing through additional headers through the TokenReviewSpec in GKE. It feels wrong and gross, but I'm not convinced there's a nicer way. I talked it through w/ @liggitt earlier today and he told me to bring it up here.

We have a temporary role-grant "token"-ish type thing that we'd like to get passed through to our webhook authorizer, which gets passed in as a "x-goog-iam-authorization-token" header in the request.

Our initial thought was we could extend TokenReview to take an Extra as an input, and then plumb it into the User object (either transparently or with some processing done in the token webhook). Then the authorizer would see the Extra in the SubjectAccessReview, and could use it to make the correct authz decision. This could be done with some kind of --authentication-webhook-extra-headers flag (i.e. we would pass --authentication-webhook-extra-headers="x-goog-iam-authorization-token" to the apiserver).

Another option is to cut out the authn middleman and pass some headers as "extra" Extra to the SubjectAccessReview (w/ a similar --authorization-webhook-extra-headers). I figured the authentication option might be more generic, but I'd love to hear if anybody else would be interested in these.

+@alexblyzn who was looking into this.

But I don't think my concerns block this from going to v1. We should be able to do what I want (if we decide it's the right thing to do) without breaking compatibility.

I can sort of understand wanting addition information the TokenReview.Spec field (I don't know that I'm fully sold, but as you noted, it could be a follow-on). But the TokenReview can return an Extra for the specified user that is already provided to the authorization webhook.

API looks ok. If there are no further comments from SIG members or others on this thread this is approved and can merge as an API change.

hearing none, tagging

Automatic merge from submit-queue (batch tested with PRs 41112, 41201, 41058, 40650, 40926)