Creating secrets for your builds

When you build your pipeline, you might want to add tasks that require secrets in order to access external resources.

Secrets can be categorized depending on when they need to be added.

  1. Before a component is added. If a secret is needed to access the source control platform like GitLab, you must create a secret before you create the component.

  2. Before a build succeeds. Some artifact build tasks need specific secrets to be able to pull all of the content to include in the final artifact. For example, you can add secrets for container registries after you create the component but they must be provided before a successful build can occur.

  3. After a component has been onboarded. These secrets are often used in tasks. The tasks included in the Konflux pipelines will not fail if a secret is not created properly. Instead, the task will just not run the code like with snyk.

Creating task input secrets

Sometimes to run the tasks properly, you may need to pass secrets to these tasks. Consult the documentation for these tasks to understand the proper specification of the secrets required, for example the required keys/values.

One such task is the sast-snyk-check task that uses the third-party service snyk to perform static application security testing (SAST) as a part of the default Konflux pipeline. Use this procedure to upload your snyk.io token. Name the secret sast_snyk_task so that the snyk task in the Konflux pipeline will recognize it and use it.
Procedure

  1. In Konflux, from the left navigation menu, select Secrets.

  2. From the Secrets page, click Add secret.

  3. For Secret type, select Key/value secret

  4. For Secret name, enter a unique name for your secret.

  5. Under Key/value secret, expand Key/value 1, then enter a key.

  6. For Upload the file with value for your key or paste its contents, do one of the following:

    • Click Upload to browse to, select, and upload the file that contains your key value.

    • Drag the file that contains your key value into the space under Upload.

    • Paste the contents of the file that contains your key value into the space under Upload. Click Clear to remove the contents of the space under Upload.

  7. Optional: Click Add another key/value.

  8. Optional: Under Labels, add a label to tag or provide more context for your secret.

  9. Click Add secret.

Creating registry pull secrets

Some container builds may use parent images from registries that require authentication, for example, registry.redhat.io. Until these credentials have been configured, the builds will continue to fail due to the system being unable to pull the required images.

Procedure

  1. Obtain the username and password login credentials for the container registry.

  2. In the correct Konflux workspace, go to Secrets.

  3. Click Add secret.

  4. For Secret type, select Image pull secret.

  5. For Authentication type, select Image registry credentials.

  6. For Registry server address enter the image registry (for example registry.redhat.io).

  7. Enter the username for the registry in Username.

  8. Enter the password for the registry in Password.

  9. Click Add secret.

Creating source control secrets

When building content from GitHub, you will need to install an application for Pipelines as Code in your repository. For supported source control management platforms that do not have an application, however, access tokens will need to be added to your Konflux workspace before creating your component.

Prerequisites
Procedure (GitLab)

  1. In GitLab click on Settings → Access Tokens on the left menu of your repository. NOTE: if you don’t see this option, you need someone with permissions to do so.

  2. Then click on Add new token.

  3. Select the following scopes: api, read_repository, and write_repository.

  4. If your GitLab instance supports setting token roles, set the role to Maintainer.

  5. Select Create project access token.

  6. Add a token to your Konflux workspace by running the kubectl create command and creating a new YAML file with a secret:

    kubectl create -f GL-secret.yaml
    apiVersion: v1
kind: Secret
metadata:
  name: pipelines-as-code-secret
  namespace: <YOUR NAMESPACE>
  labels:
    appstudio.redhat.com/credentials: scm
    appstudio.redhat.com/scm.host: <source-control-management-host> # for example, gitlab.com
type: kubernetes.io/basic-auth
stringData:
  password: <PROJECT ACCESS TOKEN>

    Using the PAT authentication requires only the password key. The username should not be set. If you set both the username and password keys, the authentication type will be considered as basic, and a basic authentication client will be created using those credentials. This client might not work or can be considered as a deprecated login method by some Source Code Management (SCM) providers.

This secret will be used by the build service to perform builds with Pipeline-as-Code.

This Project Access Tokens are scoped to a project, so you cannot use them to access resources from other projects. For more information regarding Project Access Tokens, see the Gitlab documentation.

It is also possible to have secrets for per-repository or organization access. To do this, a appstudio.redhat.com/scm.repository annotation should be added to the secret. It may either specify the full repository path or the partial path with a wildcard. For example, to create a secret for all repositories in the my-user organization, create (or add) the following YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: pipelines-as-code-secret
  namespace: <YOUR NAMESPACE>
  labels:
    appstudio.redhat.com/credentials: scm
    appstudio.redhat.com/scm.host: <source-control-management-host> # for example, gitlab.com
  annotations:
    appstudio.redhat.com/scm.repository: my-user/*
type: kubernetes.io/basic-auth
stringData:
  password: <PROJECT ACCESS TOKEN>

For a specific repository, the following secret should be created:

apiVersion: v1
kind: Secret
metadata:
  name: pipelines-as-code-secret
  namespace: <YOUR NAMESPACE>
  labels:
    appstudio.redhat.com/credentials: scm
    appstudio.redhat.com/scm.host: <source-control-management-host> # for example, gitlab.com
  annotations:
    appstudio.redhat.com/scm.repository: <repository-path> # for example, my-user/my-repo
type: kubernetes.io/basic-auth
stringData:
  password: <PROJECT ACCESS TOKEN>

  • You can have multiple repositories listed under the appstudio.redhat.com/scm.repository annotation. Separate repository names with commas when listing them. The secret will be used for all repositories that match the specified paths.

  • You can also have multiple secrets with different labels and/or annotations. In order to work, at least the additional ones, need to be named with pipeline-as-code-secret as prefix (for example pipeline-as-code-secret-xxx).

  • Secrets lookup mechanism is searching for the most specific secret first. The secret with a repository annotation will be used first if it matches the component repository path. In none found, then a lookup will try to find a secret with a wildcard, or just the host matching one.

  • If you upload a GitLab access token to a workspace, Konflux won’t use the global GitHub application when accessing GitHub repositories.
Additional resources