This change allows the http.Client used by the OIDC authenticator to
be overridden. This is useful when this code is being used as a
library outside of core Kubernetes. For example, a downstream
consumer may want to override the http.Client's internals such as
its TLS configuration.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: 11974cd18a685ea2f5ee25030a10787700dc8464
This change updates the oidc authenticator to allow specifying an
oidc.KeySet as an input option. This makes it possible to
synchronously initialize the KeySet instead of relying on the
asynchronous initialization that is normally done to support
self-hosted providers. This makes it easier to use this code as a
library.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: b5a1a45d48b4e90e54f512fc829b2ab9866b282e
This change updates the OIDC authenticator code to use a subset of
the dynamiccertificates.CAContentProvider interface to provide the
root CA bytes. This removes the hard dependency on a file based CA
and makes it easier to use this code as a library.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: 5dd4c89df38d4a5389c0cbf2c7fe4f6a5d5534ce
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>
Kubernetes-commit: 9b23f22472ebba899ea4c3111cdeee3cebdbe478
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
Kubernetes-commit: 954996e231074dc7429f7be1256a579bedd8344c
A distributed claim allows the OIDC provider to delegate a claim to a
separate URL. Distributed claims are of the form as seen below, and are
defined in the OIDC Connect Core 1.0, section 5.6.2.
See: https://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims
Example claim:
```
{
... (other normal claims)...
"_claim_names": {
"groups": "src1"
},
"_claim_sources": {
"src1": {
"endpoint": "https://www.example.com",
"access_token": "f005ba11"
},
},
}
```
Example response to a followup request to https://www.example.com is a
JWT-encoded claim token:
```
{
"iss": "https://www.example.com",
"aud": "my-client",
"groups": ["team1", "team2"],
"exp": 9876543210
}
```
Apart from the indirection, the distributed claim behaves exactly
the same as a standard claim. For Kubernetes, this means that the
token must be verified using the same approach as for the original OIDC
token. This requires the presence of "iss", "aud" and "exp" claims in
addition to "groups".
All existing OIDC options (e.g. groups prefix) apply.
Any claim can be made distributed, even though the "groups" claim is
the primary use case.
Allows groups to be a single string due to
https://github.com/kubernetes/kubernetes/issues/33290, even though
OIDC defines "groups" claim to be an array of strings. So, this will
be parsed correctly:
```
{
"iss": "https://www.example.com",
"aud": "my-client",
"groups": "team1",
"exp": 9876543210
}
```
Expects that distributed claims endpoints return JWT, per OIDC specs.
In case both a standard and a distributed claim with the same name
exist, standard claim wins. The specs seem undecided about the correct
approach here.
Distributed claims are resolved serially. This could be parallelized
for performance if needed.
Aggregated claims are silently skipped. Support could be added if
needed.
Kubernetes-commit: dfb527843ca1720ad64383fa5d6baea4113daa3e
Add the following flags to control the prefixing of usernames and
groups authenticated using OpenID Connect tokens.
--oidc-username-prefix
--oidc-groups-prefix
Kubernetes-commit: 1f8ee7fe13490a8e8e0e7801492770caca9f9b5c
Monis Khan
Anish Ramasekar
iutx
ruiwen-zhao
Davanum Srinivas
Tim Allclair
Mike Danese
Filip Filmar
rithu john
Eric Chiang
Dr. Stefan Schimanski