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
This change does three things:
1. use auditinternal for unit test in filter stage
2. add a seperate unit test for Audit-ID http header
3. add unit test for audit log backend
Kubernetes-commit: c030026b544da2dd7ef7201019bdc0ac255c2d23
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
I found some dead code in audit webhook backend.
This change do some clean work for: 2bbe72d4e0
Kubernetes-commit: 7b5c7bb711e7f15a1bf216a7a51fd40148110fba
Monis Khan
JoshVanL
Jefftree
Mike Danese
Asalle
Tim Allclair
Jordan Liggitt
Ziheng Liu
shturec
wojtekt
Ted Yu
Joe Betz
Xiang Dai
Roy Lenferink
danielqsj
Patrick Barker
Daniel Kłobuszewski
Davanum Srinivas
Patrick Barker
包梦江
Christoph Blecker
Cao Shufeng
xuzhonghu
Mikhail Mazurskiy
Marian Lobur
David Eads
Filip Filmar
Matthias Bertschy
Mik Vyatskov
Jordan Liggitt
rithu john
hangaoshuai
Kubernetes Publisher
Eric Chiang
Jeff Grafton
halfcrazy
Maciej Szulik
Chen Rong
Dr. Stefan Schimanski