This page is outdated. Please check for up-to-date documentation.


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.

Pipeline Secrets

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:

  # ...
    image: plugins/docker
    repo: foo/bar
        name: my-docker-secret
        keyRef: username
        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.

Attaching Pipeline Secrets

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 username and 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:

    image: banzaicloud/ci-pipeline-client:0.7
    action: InstallSecret
      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.