434e3fe435
This change replaces our previous test helpers for checking cluster capabilities and passing external test parameters. Prior to this change, we always used `$PINNIPED_*` environment variables and these variables were accessed throughout the test code. The new code introduces a more strongly-typed `TestEnv` structure and helpers which load and expose the parameters. Tests can now call `env := library.IntegrationEnv(t)`, then access parameters such as `env.Namespace` or `env.TestUser.Token`. This should make this data dependency easier to manage and refactor in the future. In many ways this is just an extended version of the previous cluster capabilities YAML. Tests can also check for cluster capabilities easily by using `env := library.IntegrationEnv(t).WithCapability(xyz)`. The actual parameters are still loaded from OS environment variables by default (for compatibility), but the code now also tries to load the data from a Kubernetes Secret (`integration/pinniped-test-env` by default). I'm hoping this will be a more convenient way to pass data between various scripts than the local `/tmp` directory. I hope to remove the OS environment code in a future commit. Signed-off-by: Matt Moyer <moyerm@vmware.com> |
||
|---|---|---|
| .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 | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| README.md | ||
| SECURITY.md | ||
| go.mod | ||
| go.sum | ||
README.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
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.