Don't mandate that the "token_reviewer_jwt" authentication token is a JWT

[seh]

Given that this plugin takes the value of the "token_reviewer_jwt" configuration parameter and stuffs it into an "Authorization" HTTP header as a bearer token, why does the plugin care at all about the format of this token?

For clusters with custom Webhook token authentication, tokens can be in any format: they can be service account tokens, or JWTs, PASETOs, or something more exotic understood by the Webhook. The API server's authentication subsystem will take any value submitted as a bearer token and pass it through all the active token-consuming authentication methods. In our clusters, we have a Webhook that can consume tokens that are not JWTs. At present, we can't allow this plugin to authenticate using such a token.

I understand that it's not tenable to change the name of the "token_reviewer_jwt" configuration parameter today, but can we at least consider relaxing the enforcement of the format? If the intended consumer of the tokens doesn't mandate a particular format, why should this plugin be an overly stringent intermediary? In the interest of trying to help catch mistakes early, it's actually cutting off otherwise valid input.

This request may overlap with the earlier #34.

[seh]

Ah, reading the code further, I now see that this plugin expects the token to authenticate as a Kubernetes service account, as it destructures the user name to glean the account name and containing namespace. Given that, still, it matters less that the input is a JWT; what's apparently important is that it maps to a user name that looks like a service account's fully-qualified name.

Note that a Webhook is free to return a user name that matches that format. It would be unusual to do so, sure, but nothing in Kubernetes prevents it.

[yesteph]

Hi @seh

Ah, reading the code further, I now see that this plugin expects the token to authenticate as a Kubernetes service account, as it destructures the user name to glean the account name and containing namespace. Given that, still, it matters less that the input is a JWT; what's apparently important is that it maps to a user name that looks like a service account's fully-qualified name.

Note that a Webhook is free to return a user name that matches that format. It would be unusual to do so, sure, but nothing in Kubernetes prevents it.

I think you mix the token usage: the token_reviewer_jwt is passed to authorize the TokenReview creation on the kube api server, to validate the Pod ServiceAccount and extract the SA name, namespace and other stuffs.

We have the same problem as you: we cannot integrate an external Vault cluster with vault agent running on a kubernetes whose API server is proxied for authent. The check to validate the format of the token_reviewer_jwt are useless because they will be done at TokenReview creation.

[seh]

I see your point, @yesteph. That strengthens my original complaint, and really splits this into two complaints:

• The bearer token used to authenticate to create TokenReview objects doesn't need to be a JWT; it just needs to be understood by an active authentication method.
• Kubernetes user names supplied by authentication methods do not need to—and rarely will—match the service account user name format.

[seh]

4.5 years later, I am still happy to see this addressed. Thank you.