Using Pinniped for CI/CD cluster operations
This guide shows you how to configure Pinniped so that your CI/CD system of choice can administrate Kubernetes clusters.
Pinniped provides user authentication to Kubernetes clusters. It does not provide service-to-service (non-user) authentication. There are many other systems for service-to-service authentication in Kubernetes.
If an organization prefers to manage CI/CD access with non-human user accounts in their IDP, Pinniped can provide authentication for those non-human user accounts. Humans can also use the same steps below to log into clusters non-interactively.
Note that the guide below assumes that you are using a non-human user account within the IDP of your choice. It is never recommended to use a human’s credentials for CI/CD or other automated processes.
This how-to guide assumes that you have already configured the following Pinniped server-side components within your Kubernetes cluster(s):
- Pinniped Supervisor with a working FederationDomain and at least one IdentityProvider (LDAP, AD, or OIDC)
- The Supervisor installation could be on a completely separate cluster unrelated to your CI/CD
- Pinniped Concierge on each cluster that needs to be administrated by your CI/CD system
- A CI/CD system that meets the following conditions:
- It can handle secrets safely and provide them to tasks as environment variables
- It can run shell scripts, or at least invoke binaries (such as
- It can access Pinniped-style kubeconfigs for each cluster
- A user account (that does not represent a human) within the IDP of your choice
- This account should be granted the least amount of privileges necessary
- This account should likely be single-purposed for CI/CD use
- A CI/CD admin should generate the Pinniped-style kubeconfig for each cluster that needs to be administered by CI/CD
and make those kubeconfigs available to CI/CD
- Be sure to use
pinniped get kubeconfigwith option
--upstream-identity-provider-flow=cli_passwordto authenticate non-interactively (without a browser)
- When using OIDC, the optional CLI-based flow must be enabled by the administrator in the OIDCIdentityProvider configuration before use
allowPasswordGrantin the API docs for more details).
- Be sure to use
- A CI/CD admin should make the non-human user account credentials available to CI/CD tasks
- Each CI/CD task should set the environment variables
kubectlprocess to avoid the interactive prompts. The values should be provided from the non-human user account credentials.
At this point, your CI/CD has now authenticated into your kubernetes cluster. Be sure to set up the appropriate IDP groups and Kubernetes roles to enable your non-human user account to perform the necessary operations.