80a520390b
New resource naming conventions: - Do not repeat the Kind in the name, e.g. do not call it foo-cluster-role-binding, just call it foo - Names will generally start with a prefix to identify our component, so when a user lists all objects of that kind, they can tell to which component it is related, e.g. `kubectl get configmaps` would list one named "pinniped-config" - It should be possible for an operator to make the word "pinniped" mostly disappear if they choose, by specifying the app_name in values.yaml, to the extent that is practical (but not from APIService names because those are hardcoded in golang) - Each role/clusterrole and its corresponding binding have the same name - Pinniped resource names that must be known by the server golang code are passed to the code at run time via ConfigMap, rather than hardcoded in the golang code. This also allows them to be prepended with the app_name from values.yaml while creating the ConfigMap. - Since the CLI `get-kubeconfig` command cannot guess the name of the CredentialIssuerConfig resource in advance anymore, it lists all CredentialIssuerConfig in the app's namespace and returns an error if there is not exactly one found, and then uses that one regardless of its name |
||
|---|---|---|
| .github | ||
| apis | ||
| cmd | ||
| deploy | ||
| deploy-local-user-authenticator | ||
| doc | ||
| generated | ||
| hack | ||
| internal | ||
| pkg/config | ||
| test | ||
| tools | ||
| .gitattributes | ||
| .gitignore | ||
| .golangci.yaml | ||
| .pre-commit-config.yaml | ||
| ADOPTERS.md | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| README.md | ||
| SECURITY.md | ||
Pinniped
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
Pinniped offers credential exchange to enable a user to exchange an external IDP credential for a short-lived, cluster-specific credential. Pinniped supports various IDP types and implements different integration strategies for various Kubernetes distributions to make authentication possible.
To learn more, see architecture.md.
Trying Pinniped
Care to kick the tires? It's easy to install and try Pinniped.
Installation
Currently, Pinniped supports self-hosted clusters where the Kube Controller Manager pod is accessible from Pinniped's pods. Support for other types of Kubernetes distributions is coming soon.
To try Pinniped, see deploy/README.md.
Contributions
Contributions are welcome. Before contributing, please see the Code of Conduct and 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 file.
Copyright 2020 the Pinniped contributors. All Rights Reserved.