This change removes the audience logic from the oidc authenticator
and collapses it onto the same logic used by other audience unaware
authenticators.
oidc is audience unaware in the sense that it does not know or
understand the API server's audience. As before, the authenticator
will continue to check that the token audience matches the
configured client ID.
The reasoning for this simplification is:
1. The previous code tries to make the client ID on the oidc token
a valid audience. But by not returning any audience, the token is
not valid when used via token review on a server that is configured
to honor audiences (the token works against the Kube API because the
audience check is skipped).
2. It is unclear what functionality would be gained by allowing
token review to check the client ID as a valid audience. It could
serve as a proxy to know that the token was honored by the oidc
authenticator, but that does not seem like a valid use case.
3. It has never been possible to use the client ID as an audience
with token review as it would have always failed the audience
intersection check. Thus this change is backwards compatible.
It is strange that the oidc authenticator would be considered
audience unaware when oidc tokens have an audience claim, but from
the perspective of the Kube API (and for backwards compatibility),
these tokens are only valid for the API server's audience.
This change seems to be the least magical and most consistent way to
honor backwards compatibility and to allow oidc tokens to be used
via token review when audience support in enabled.
Signed-off-by: Monis Khan <mok@vmware.com>
* Extend --dry-run to support string values for dry run strategies
'client', 'server', and 'none'
* Ensure --dry-run is set and accessed via cmdutil
* Deprecate --dry-run (unset), --dry-run=true, and --dry-run=false
In other parts of the system (notably in RBAC rules), the "resource/subresource" notation is common to specify an explicit subresource. This makes this notation available to tests that use the `Matches` function on client actions as well.
Backwards compatibility is kept by ignoring the `Subresource` field if no specific subresource is defined in the resource string itself.
We were occasionally seeing
```
[SHOULD NOT HAPPEN] failed to create typed new object: .spec.rules: element 0: associative list without keys has an element that's a map type
```
So I changed all the listType annotations to `atomic` except when the
element type is a scalar, which is the only case supported right now.
