f46de56b95
After noticing that the upstream OIDC discovery calls can hang indefinitely, I had tried to impose a one minute timeout on them by giving them a timeout context. However, I hadn't noticed that the context also gets passed into the JWKS fetching object, which gets added to our cache and used later. Therefore the timeout context was added to the cache and timed out while sitting in the cache, causing later JWKS fetchers to fail. This commit is trying again to impose a reasonable timeout on these discovery and JWKS calls, but this time by using http.Client's Timeout field, which is documented to be a timeout for *each* request/response cycle, so hopefully this is a more appropriate way to impose a timeout for this use case. The http.Client instance ends up in the cache on the JWKS fetcher object, so the timeout should apply to each JWKS request as well. Requests that can hang forever are effectively a server-side resource leak, which could theoretically be taken advantage of in a denial of service attempt, so it would be nice to avoid having them. |
||
|---|---|---|
| .github | ||
| apis | ||
| cmd | ||
| deploy | ||
| generated | ||
| hack | ||
| internal | ||
| pkg | ||
| site | ||
| test | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yaml | ||
| .pre-commit-config.yaml | ||
| .pre-commit-hooks.yaml | ||
| ADOPTERS.md | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| README.md | ||
| SECURITY.md | ||
Overview
Pinniped provides identity services to Kubernetes.
Pinniped allows cluster administrators to easily plug in external identity providers (IDPs) into Kubernetes clusters. This is achieved via a uniform install procedure across all types and origins of Kubernetes clusters, declarative configuration via Kubernetes APIs, enterprise-grade integrations with IDPs, and distribution-specific integration strategies.
Example Use Cases
- Your team uses a large enterprise IDP, and has many clusters that they
manage. Pinniped provides:
- Seamless and robust integration with the IDP
- Easy installation across clusters of any type and origin
- A simplified login flow across all clusters
- Your team shares a single cluster. Pinniped provides:
- Simple configuration to integrate an IDP
- Individual, revocable identities
Architecture
The Pinniped Supervisor component offers identity federation to enable a user to access multiple clusters with a single daily login to their external IDP. The Pinniped Supervisor supports various external IDP types.
The Pinniped Concierge component offers credential exchange to enable a user to exchange an external credential for a short-lived, cluster-specific credential. Pinniped supports various authentication methods and implements different integration strategies for various Kubernetes distributions to make authentication possible.
The Pinniped Concierge can be configured to hook into the Pinniped Supervisor's federated credentials, or it can authenticate users directly via external IDP credentials.
To learn more, see architecture.
Trying Pinniped
Care to kick the tires? It's easy to install and try Pinniped.
Discussion
Got a question, comment, or idea? Please don't hesitate to reach out via the GitHub Discussions tab at the top of this page.
Contributions
Contributions are welcome. Before contributing, please see the contributing guide.
Reporting Security Vulnerabilities
Please follow the procedure described in SECURITY.md.
License
Pinniped is open source and licensed under Apache License Version 2.0. See LICENSE.
Copyright 2020 the Pinniped contributors. All Rights Reserved.