ab9f64afa9
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Implements OIDC distributed claims. Next step to enable this feature is to enable claim caching. 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. **What this PR does / why we need it**: Makes it possible to retrieve many group memberships by offloading to a dedicated backend for groups resolution. **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes #62920 **Special notes for your reviewer**: There are a few TODOs that seem better handled in separate commits. **Release note**: ```release-note Lays groundwork for OIDC distributed claims handling in the apiserver authentication token checker. 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. For details, see: http://openid.net/specs/openid-connect-core-1_0.html#AggregatedDistributedClaims ``` |
||
|---|---|---|
| .github | ||
| api | ||
| build | ||
| cluster | ||
| cmd | ||
| docs | ||
| Godeps | ||
| hack | ||
| logo | ||
| pkg | ||
| plugin | ||
| staging | ||
| test | ||
| third_party | ||
| translations | ||
| vendor | ||
| .bazelrc | ||
| .generated_files | ||
| .gitattributes | ||
| .gitignore | ||
| .kazelcfg.json | ||
| BUILD.bazel | ||
| CHANGELOG-1.2.md | ||
| CHANGELOG-1.3.md | ||
| CHANGELOG-1.4.md | ||
| CHANGELOG-1.5.md | ||
| CHANGELOG-1.6.md | ||
| CHANGELOG-1.7.md | ||
| CHANGELOG-1.8.md | ||
| CHANGELOG-1.9.md | ||
| CHANGELOG-1.10.md | ||
| CHANGELOG-1.11.md | ||
| CHANGELOG.md | ||
| code-of-conduct.md | ||
| CONTRIBUTING.md | ||
| labels.yaml | ||
| LICENSE | ||
| Makefile | ||
| Makefile.generated_files | ||
| OWNERS | ||
| OWNERS_ALIASES | ||
| README.md | ||
| SUPPORT.md | ||
| WORKSPACE | ||
Kubernetes
Kubernetes is an open source system for managing containerized applications across multiple hosts; providing basic mechanisms for deployment, maintenance, and scaling of applications.
Kubernetes builds upon a decade and a half of experience at Google running production workloads at scale using a system called Borg, combined with best-of-breed ideas and practices from the community.
Kubernetes is hosted by the Cloud Native Computing Foundation (CNCF). If you are a company that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details about who's involved and how Kubernetes plays a role, read the CNCF announcement.
To start using Kubernetes
See our documentation on kubernetes.io.
Try our interactive tutorial.
Take a free course on Scalable Microservices with Kubernetes.
To start developing Kubernetes
The community repository hosts all information about building Kubernetes from source, how to contribute code and documentation, who to contact about what, etc.
If you want to build Kubernetes right away there are two options:
You have a working Go environment.
$ go get -d k8s.io/kubernetes
$ cd $GOPATH/src/k8s.io/kubernetes
$ make
You have a working Docker environment.
$ git clone https://github.com/kubernetes/kubernetes
$ cd kubernetes
$ make quick-release
For the full story, head over to the developer's documentation.
Support
If you need support, start with the troubleshooting guide, and work your way through the process that we've outlined.
That said, if you have questions, reach out to us one way or another.