In Pipeline, users are part of organizations. Users may invite other users into organizations, and a user can be part of more than one organization at once. These organizations can have different types of associated resources: Kubernetes clusters created inside organizations, object storage buckets, spotguide catalogs, etc. One feature that all of these have in common is that they require secrets to work properly. Usually, these secrets allow Pipeline to interact with your cloud provider account, in order to provision any underlying resources. Secrets may also be associated with applications running on your Kubernetes clusters, like a TLS certificate chain for MySQL, or a Kubernetes cluster’s own credentials. Secrets are stored in Vault with added layers of abstraction that allow them to be provided to applications and build pipelines.
Using secrets in build steps
At some point you'll probably be executing a build step that needs to use a credential for its job. In the CI/CD flow, which runs natively on Kubernetes, Pipeline secrets can be injected directly into Pods that represent build steps. If you need one of your secrets for a specific build step, you can specify it in the step's
secretFrom parameter. This binds the value of a secret's field to an environment variable that's supplied to your build step. For example, you can use a secret that's holding Dockerhub credentials to build and push an image:
pipeline: # ... build_container: image: plugins/docker repo: foo/bar secretFrom: DOCKER_USERNAME: name: my-docker-secret keyRef: username DOCKER_PASSWORD: name: my-docker-secret keyRef: password
To use a Pipeline secret in the steps of a specific CI/CD project, you must first attach the secret. On the web interface, go to the CI/CD page, click on the project's settings button, and attach the secret you want to use.
A plugin's documentation will specify the name of the environment variables that a plugin will expect the credentials to be in, but you have the freedom to choose how you store them in Pipeline. Generally speaking, it's possible to create a
Generic-type secret, and add fields with the same names as variables. Then the keys in the
secretFrom object will be repeated as
keyRefs, and the
name parameters will be the same for all variables. However, the docker plugin example above uses a
Password type secret, which has
password fields. These are mapped to anticipated variable names.
Installing secrets to clusters
If your application (your Helm charts) need credentials in the form of Kubernetes Secrets, you can install them to the cluster in order to let the Pods of a given namespace consume them. The following code snippet is an example configuration for installing a secret:
pipeline: install_secret: image: banzaicloud/ci-pipeline-client:0.7 action: InstallSecret clusterSecret: sourceSecretName: pipeline-secret-name name: installed-secret-name namespace: default
With the help of the Pipeline CI Client plugin, users can define how these secrets should be injected into the Kubernetes cluster their build is running on.