Better to be explicit about what a token with multiple audiences means? E.g.

A token issued for multiple audiences may be used to authenticate against any of the audiences listed. This
implies a high degree of trust between the target audiences.

nit: add an error field?

Why not just return an error? What other APIs have error fields in status?

TokenReview, but yeah that's so we can surface authentication errors. You're right. Disregard.

https://godoc.org/k8s.io/api/authentication/v1#TokenReviewStatus

@liggitt mentioned service account tokens which are explicitly tied to pods. E.g. service account tokens that never expire, but are implicitly revoked when the pod they're tied to is deleted from the API.

I don't know if this is "sub" or a custom claim, but that seems appealing as a way of phasing out the current service account tokens without forcing the client (or the kubelet) to handle rotation.

I think that's important - would like to see it referenced or called out here.

How does a pod or node determine the audience of the API server they're talking to?

and how does an API server determine the valid audiences it should accept for itself?

I think this should be either kubernetes.default.svc or the ClusterIP of the kubernetes service or both.

Isn't "a later design" just this: kubernetes/kubernetes#55019 ?

Yes plus a bit more. I was going to group this authorization bit into part 2) how kubelet or other node agent hands jwts to workloads. I think it is separable from this proposal though.

Would be easy-ish to plumb this through the oidc plugin (if aud != clientid -> reject). Don't know what this would look like for the wehbook authenticator or how we'd roll it out. If a webhook authentication backend didn't consider this field you could get in some dangerous situations, right?

passing a token intended for someone other than the apiserver to the apiserver for verification seems a little weird

Don't know what this would look like for the wehbook authenticator or how we'd roll it out. If a webhook authentication backend didn't consider this field you could get in some dangerous situations, right?

Is this any different from webhook authenticator and svcacct id_tokens today?

passing a token intended for someone other than the apiserver to the apiserver for verification seems a little weird

This is true of all usage of TokenReview API endpoint though, isn't it? In this case, it is less weird since the apiserver is the thing creating the tokens in the first place. An API to correctly and opaquely verify these tokens is valuable for integrations.

non-expiring tokens can be revoked by removing the associated Secret or ServiceAccount object.

I think we'd still want some form of this in order to be able to generate legacy-compatible tokens out of the API. What about this:

• a non-expiring token must be bound to a deletable object name+uid (like a pod or secret)
• non-expiring tokens can only be for the apiserver audience (since only the apiserver can be counted on to verify the bound object still exists)
• the API server must verify the object+uid still exists before verifying the token

This gets the confidential and bulky portion of unexpiring service account tokens out of the API, and still lets them be revocable. It also lets us move to this new model for both legacy and expiring/rotating cases, which is desirable.

Not only desirable, required. I think we want to completely supplant the old model.

This makes OIDC signing key rotation difficult or impossible. Do we need to support non-expiring forever or just for some number of releases (in accordance to our GA deprecation policy)?

This makes key OIDC signing key rotation difficult or impossible.

How so? A non-expiring token doesn't mean it can't be revoked or made invalid, it just doesn't have an inherent expiration time.

It means you could never remove a public key form the JWKS_URI since it could potentially need to exist forever to verify a token.

I'd consider that working as intended. No inherent expiration, but an admin decision to revoke or rotate signing keys could invalidate it.

The point is that it's not easy to maintain compatibility with the current client-go while also rotating SA signing keys. If we rotate signing keys every 4 days, how is a non-expiring token useful?

Would the tokenreview API only support the apiserver audience?

No, I don't think so. I hope that it will support any audience so integrators can easily validate tokens.

what audience would the apiserver use when making a TokenReview request to an authentication webhook?

Last question is still outstanding

Sorry, missed this. I expect that the apiserver would populate audience with every name that it identifies itself as. Initially that would be ["https://kubernetes.default.svc"] but we could add configuration to override or add more identifiers to that list. This would be the same list of audiences that the apiserver would validate service account id tokens against in the service account id token authenticator.

Yes, that seems like the correct semantics to me. If you agree, I'll add that to this proposal

Thinking through the audience implications on TokenReview for the following cases:

• kubelets verifying presented bearer tokens against kube-apiserver's TokenReview
  • old kubelets won't specify an audience... default should mean "valid against kube-apiserver" as it does today
  • what audience(s) should new kubelets specify?
• extension API servers verifying bearer tokens against kube-apiserver's TokenReview
  • old extension servers won't specify an audience... default should mean "valid against kube-apiserver" as it does today
  • what audience(s) should new extension API servers specify?
• kube-apiserver verifying bearer tokens against the authentication webhook TokenReview endpoint
  • old webhooks won't be audience-aware and will just verify the token
  • what audience(s) should new webhooks expect/verify?

Also, the kube-apiserver doesn't have the plumbing needed to verify tokens for arbitrary audiences (which would be required for it to handle an Audiences field in TokenReview). The way kube-apiserver implements TokenReview today is to pass a constructed http request containing Authorization: Bearer <token> to the request authenticator:

https://github.com/kubernetes/kubernetes/blob/c17b418f89e056bea272ed46ca9f63f8b1e37589/pkg/registry/authentication/tokenreview/storage.go#L61-L69

I'm afraid adding arbitrary audience support would mean expanding the AuthenticateRequest, AuthenticateToken, and AuthenticatePassword interface signatures to include Audiences []string.

kubelets verifying presented bearer tokens against kube-apiserver's TokenReview

• old kubelets won't specify an audience... default should mean "valid against kube-apiserver" as it does today
• what audience(s) should new kubelets specify?

When configured to have individual audiences, the identifiers that they request as SANs seems reasonable.

https://github.com/kubernetes/kubernetes/blob/9847c8ee0a2c71fc4e9e1665017f05de7c9f815e/pkg/kubelet/kubelet.go#L745-L746

extension API servers verifying bearer tokens against kube-apiserver's TokenReview

• old extension servers won't specify an audience... default should mean "valid against kube-apiserver" as it does today
• what audience(s) should new extension API servers specify?

Extension apiservers are rarely accessed directly today. In the cases where they are, a security conscious operator may want to configure a separate audience for the extension apiserver.

kube-apiserver verifying bearer tokens against the authentication webhook TokenReview endpoint

• old webhooks won't be audience-aware and will just verify the token
• what audience(s) should new webhooks expect/verify?

I would not expect an google access token with scope "cloudplatform" to be valid against vault. I would not expect a google oidc id token (where the audience is the client_id) to be valid against vault. Moving forward, I would expect TokenReview webhooks to become aware of the new field.

I'm afraid adding arbitrary audience support would mean expanding the AuthenticateRequest, AuthenticateToken, and AuthenticatePassword

It seems like it's this or some hacky side channel.

I would expect TokenReview webhooks to become aware of the new field.

We could also not forward TokenReviews with non-apiserver audiences for some period of time.

I think those make sense, though I'm unsure how we'd automatically transition to the "use individual audience" option over time. Would be unfortunate for that to be a off-by-default option that never gets used

Can token ever be data that isn't unicode data? I.e. do we need to deal with binary tokens? Or will we hardcode and assume all tokens are safe for HTTP header values and for strings?

Can token ever be data that isn't unicode data? I.e. do we need to deal with binary tokens?

I would not expect that. Every spec I've seen gives bearer tokens a really limited character set

b64token    = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token

TokenReviewSpec has Token string as well

This is a duplicate of the struct on Line 98?

need to include the actual duration in the response, so the receiver knows how long the token is valid for

I'd expect the cluster admin to be able to configure:

• whether non-expiring tokens are allowed
• max validity duration for expiring tokens

Token requesters should be able to tell from the status:

• whether they were issued an expiring or non-expiring token
• for expiring tokens, how long the token is valid for

all the use cases I can think of for token requests benefit from including resource+name+uid of at least one object as a claim in the token:

• a token requested by node n for service account sa should be bound to a pod with serviceAccountName=sa and nodeName=n (and stop working against the apiserver when that pod goes away)
• a non-expiring token should be bound to some object in the namespace that indicates the existence of the token, and can be deleted in order to revoke the token (just like a service account token secret behaves today)

What if the TokenRequestSpec included an object reference (or list of object references) that the requester wanted the token bound to, and the TokenRequestStatus include the object reference (or list of references) the token was actually bound to.

Immediately, that would let the NodeRestriction plugin limit nodes to requesting tokens bound to pods scheduled to themselves and referencing the correct serviceaccount.

Longer term, it would let the API provision an object purpose-built for recording the existence of a service account token without containing any confidential info (e.g. a ServiceAccountToken object) in response to an otherwise unbound token request, and returning the reference to the requester.

Should this be an ObjectReference or LocalObjectReference (would have to add a few fields to LocalObjectReference) or should I create a new type for this?

Added a section on object binding.

s/objet/object/g

Couldn't a token be bounded to multiple objects? A token given to a node for a pod running a service account could be tied to:

• The node
• The pod
• The service account

A token should always be bound to a service account i.e. the service account needs to exist for the service account token to be valid. I consider these bindings to be extras (e.g. pod, node, secret). I don't think N bindings over 1 binding adds extra value to warrant the complexity. Deleting a node today should cause all pods on the node to be deleted almost instantaneously. Are there any other usecases for multiple bound objects?

I don't think N bindings over 1 binding adds extra value to warrant the complexity.

I tend to agree (and also don't want unbounded items to resolve at validation time)

Note: I've opted to require time binding on all JWTs issued by this API. It eliminates the need to support two styles of token and can still support everything we want to support.

typo: s/it's/its

let's pull this bit into a follow-up PR so the proposal can be merged

can update this to describe the node authorizer bits, and defer the self-token-request bit for a follow up

harmonize with the initial alpha impl

Hi @mikedanese , do you mean Subject here? Why is it removed from API definition now?😅

this is a claim in the generated service account JWT. it is still present.