This change updates the generic webhook logic to use a rest.Config
as its input instead of a kubeconfig file. This exposes all of the
rest.Config knobs to the caller instead of the more limited set
available through the kubeconfig format. 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 webhook's
internals such as its TLS configuration.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: fef7d0ef1e1fbff65e8d445256036704bb9dbcbd
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
it turns out that setting a timeout on HTTP client affect watch requests made by the delegated authentication component.
with a 10 second timeout watch requests are being re-established exactly after 10 seconds even though the default request timeout for them is ~5 minutes.
this is because if multiple timeouts were set, the stdlib picks the smaller timeout to be applied, leaving other useless.
for more details see a937729c2c/src/net/http/client.go (L364)
instead of setting a timeout on the HTTP client we should use context for cancellation.
Kubernetes-commit: d690d71d27c78f2f7981b286f5b584455ff30246
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
webhook.WithExponentialBackoff returns an error, and the priority is:
- A: if the last invocation of the webhook function returned an error
that error should be returned, otherwise
- B: the error associated with the context if it has been canceled or
it has expired, or the ErrWaitTimeout returned by the wait package
once all retries have been exhausted.
caller should check the error returned by webhook.WithExponentialBackoff
to handle both A and B. Currently, we only handle A.
Kubernetes-commit: ae2b353fbf519b29d168c534f88c373fd67a1c31
This change updates the OIDC authenticator to not wait 10 seconds
before attempting to fetch the /.well-known/openid-configuration
metadata from the OIDC issuer. In most situations this results in
the API server being able to verify ID tokens sooner.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: be99f37a6861f885c263a447656b9470ba4f720f
Currently webhook retry backoff parameters are hard coded, we want
to have the ability to configure the backoff parameters for webhook
retry logic.
Kubernetes-commit: 53a1307f68ccf6c9ffd252eeea2b333e818c1103
This change removes support for basic authn in v1.19 via the
--basic-auth-file flag. This functionality was deprecated in v1.16
in response to ATR-K8S-002: Non-constant time password comparison.
Similar functionality is available via the --token-auth-file flag
for development purposes.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: df292749c9d063b06861d0f4f1741c37b815a2fa
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
1024 seems absurdly small for any normal deployment. At our 10000 byte
entry size limit, this will consume max ~80 MB of memory. More realistic
entry sizes are going to be less than a kB.
Kubernetes-commit: fb33b2f42a9621e65883c92a3cb49a278d14c6cc
stopAllDelegates will signal other functions to stop updating, instead of acquiring a Mutex and never unlock it
Signed-off-by: Ziheng Liu <zxl381@psu.edu>
Kubernetes-commit: b1c9ae5499b49b5630768050d92bc8ac3553d830
- 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
The striped cache used by the token cache is slightly more sophisticated
however the simple cache provides about the same exact behavior. I used
the striped cache rather than the simple cache because:
* It has been used without issue as the primary token cache.
* It preforms better under load.
* It is already exposed in the public API of the token cache package.
Kubernetes-commit: 0ec4d6d396f237ccb3ae0e96922a90600befb83d
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
experimental-keystone-url and experimental-keystone-ca-file were always
experimental. So we don't need a deprecation period.
KeystoneAuthenticator was on the server side and needed userid/password
to be passed in and used that to authenticate with Keystone. We now
have authentication and authorization web hooks that can be used. There
is a external repo with a webook for keystone which works fine along
with the kubectl auth provider that was added in:
a0cebcb559c5c0ab8a2e50b1ee11cc62f9ebb3a8
So we don't need this older style / hard coded / experimental code
anymore.
Kubernetes-commit: 18590378c4491eacdea5cd05f98c92fe84020263
Tim Allclair
Monis Khan
carlory
Davanum Srinivas
tanjing2020
Lukasz Szaszkiewicz
xiaofei.sun
Abu Kashem
ruiwen-zhao
David Eads
JoshVanL
Jefftree
Mike Danese
Asalle
Jordan Liggitt
Ziheng Liu
shturec
wojtekt
Ted Yu
Joe Betz
Xiang Dai
Roy Lenferink
danielqsj
Patrick Barker
Daniel Kłobuszewski
Patrick Barker
包梦江
Christoph Blecker
Cao Shufeng
xuzhonghu
Mikhail Mazurskiy
Marian Lobur
Filip Filmar
Matthias Bertschy
Mik Vyatskov
Jordan Liggitt
rithu john
hangaoshuai
Kubernetes Publisher
Eric Chiang
Jeff Grafton
halfcrazy