Authenticating pipelines using git secret | Securing OpenShift Pipelines

Credential selection
Configuring basic authentication for Git
Configuring SSH authentication for Git
Using SSH authentication in git type tasks
Using secrets as a non-root user
Limiting secret access to specific steps

A Git secret consists of credentials to securely interact with a Git repository, and is often used to automate authentication. In Red Hat OpenShift Pipelines, you can use Git secrets to authenticate pipeline runs and task runs that interact with a Git repository during execution.

A pipeline run or a task run gains access to the secrets through the associated service account. OpenShift Pipelines support the use of Git secrets as annotations (key-value pairs) for basic authentication and SSH-based authentication.

Credential selection

A pipeline run or task run might require multiple authentications to access different Git repositories. Annotate each secret with the domains where OpenShift Pipelines can use its credentials.

A credential annotation key for Git secrets must begin with tekton.dev/git-, and its value is the URL of the host for which you want OpenShift Pipelines to use that credential.

In the following example, OpenShift Pipelines uses a basic-auth secret, which relies on a username and password, to access repositories at github.com and gitlab.com.

Example: Multiple credentials for basic authentication

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: github.com
    tekton.dev/git-1: gitlab.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> (1)
  password: <password> (2)

1	username for the repository
2	Password or personal access token for the repository

You can also use an ssh-auth secret (private key) to access a Git repository.

Example: Private key for SSH based authentication

apiVersion: v1
kind: Secret
metadata:
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: (1)

1	The content of the SSH private key file.

Configuring basic authentication for Git

For a pipeline to retrieve resources from password-protected repositories, you must configure the basic authentication for that pipeline.

To configure basic authentication for a pipeline, update the secret.yaml, serviceaccount.yaml, and run.yaml files with the credentials from the Git secret for the specified repository. When you complete this process, OpenShift Pipelines can use that information to retrieve the specified pipeline resources.

For GitHub, authentication using plain password is deprecated. Instead, use a personal access token.

Procedure

In the secret.yaml file, specify the username and password or GitHub personal access token to access the target Git repository.

apiVersion: v1
kind: Secret
metadata:
  name: basic-user-pass (1)
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: <username> (2)
  password: <password> (3)

1	Name of the secret. In this example, `basic-user-pass`.
2	username for the Git repository.
3	Password for the Git repository.

In the serviceaccount.yaml file, associate the secret with the appropriate service account.
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot (1)
secrets:
  - name: basic-user-pass (2)
```
1 Name of the service account. In this example, build-bot.

2 Name of the secret. In this example, basic-user-pass.
In the run.yaml file, associate the service account with a task run or a pipeline run.
- Associate the service account with a task run:
  apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: build-push-task-run-2 (1) spec: serviceAccountName: build-bot (2) taskRef: name: build-push (3)
  1 Name of the task run. In this example, build-push-task-run-2.
  
  2 Name of the service account. In this example, build-bot.
  
  3 Name of the task. In this example, build-push.
- Associate the service account with a PipelineRun resource:
  apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: demo-pipeline (1) namespace: default spec: serviceAccountName: build-bot (2) pipelineRef: name: demo-pipeline (3)
  1 Name of the pipeline run. In this example, demo-pipeline.
  
  2 Name of the service account. In this example, build-bot.
  
  3 Name of the pipeline. In this example, demo-pipeline.

Apply the changes.

$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

Configuring SSH authentication for Git

For a pipeline to retrieve resources from repositories configured with SSH keys, you must configure the SSH-based authentication for that pipeline.

To configure SSH-based authentication for a pipeline, update the secret.yaml, serviceaccount.yaml, and run.yaml files with the credentials from the SSH private key for the specified repository. When you complete this process, OpenShift Pipelines can use that information to retrieve the specified pipeline resources.

Consider using SSH-based authentication rather than basic authentication.

Procedure

Generate an SSH private key, or copy an existing private key, which is usually available in the ~/.ssh/id_rsa file.
In the secret.yaml file, set the value of ssh-privatekey to the content of the SSH private key file, and set the value of known_hosts to the content of the known hosts file.
```
apiVersion: v1
kind: Secret
metadata:
  name: ssh-key (1)
  annotations:
    tekton.dev/git-0: github.com
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: (2)
  known_hosts: (3)
```
1 Name of the secret containing the SSH private key. In this example, ssh-key.

2 The content of the SSH private key file.

3 The content of the known hosts file.

If you omit the private key, OpenShift Pipelines accepts the public key of any server.
Optional: To specify a custom SSH port, add :<port number> to the end of the annotation value. For example, tekton.dev/git-0: github.com:2222.
In the serviceaccount.yaml file, associate the ssh-key secret with the build-bot service account.
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: build-bot (1)
secrets:
  - name: ssh-key (2)
```
1 Name of the service account. In this example, build-bot.

2 Name of the secret containing the SSH private key. In this example, ssh-key.
In the run.yaml file, associate the service account with a task run or a pipeline run.
- Associate the service account with a task run:
  apiVersion: tekton.dev/v1beta1 kind: TaskRun metadata: name: build-push-task-run-2 (1) spec: serviceAccountName: build-bot (2) taskRef: name: build-push (3)
  1 Name of the task run. In this example, build-push-task-run-2.
  
  2 Name of the service account. In this example, build-bot.
  
  3 Name of the task. In this example, build-push.
- Associate the service account with a pipeline run:
  apiVersion: tekton.dev/v1beta1 kind: PipelineRun metadata: name: demo-pipeline (1) namespace: default spec: serviceAccountName: build-bot (2) pipelineRef: name: demo-pipeline (3)
  1 Name of the pipeline run. In this example, demo-pipeline.
  
  2 Name of the service account. In this example, build-bot.
  
  3 Name of the pipeline. In this example, demo-pipeline.

Apply the changes.

$ oc apply --filename secret.yaml,serviceaccount.yaml,run.yaml

Using SSH authentication in git type tasks

When invoking Git commands, you can use SSH authentication directly in the steps of a task. SSH authentication ignores the $HOME variable and only uses the user’s home directory specified in the /etc/passwd file. So each step in a task must symlink the /tekton/home/.ssh directory to the home directory of the associated user.

However, explicit symlinks are not necessary when you use a pipeline resource of the git type, or the git-clone task available in the Tekton catalog.

As an example of using SSH authentication in git type tasks, refer to authenticating-git-commands.yaml.

Using secrets as a non-root user

You might need to use secrets as a non-root user in certain scenarios, such as:

The users and groups that the containers use to execute runs are randomized by the platform.
The steps in a task define a non-root security context.
A task specifies a global non-root security context, which applies to all steps in a task.

In such scenarios, consider the following aspects of executing task runs and pipeline runs as a non-root user:

SSH authentication for Git requires the user to have a valid home directory configured in the /etc/passwd directory. Specifying a UID that has no valid home directory results in authentication failure.
SSH authentication ignores the $HOME environment variable. So you must or symlink the appropriate secret files from the $HOME directory defined by OpenShift Pipelines (/tekton/home), to the non-root user’s valid home directory.

In addition, to configure SSH authentication in a non-root security context, refer to the example for authenticating git commands.

Limiting secret access to specific steps

By default, the secrets for OpenShift Pipelines are stored in the $HOME/tekton/home directory, and are available for all the steps in a task.

To limit a secret to specific steps, use the secret definition to specify a volume, and mount the volume in specific steps.

1	Name of the service account. In this example, `build-bot`.
2	Name of the secret. In this example, `basic-user-pass`.

1	Name of the task run. In this example, `build-push-task-run-2`.
2	Name of the service account. In this example, `build-bot`.
3	Name of the task. In this example, `build-push`.

1	Name of the pipeline run. In this example, `demo-pipeline`.
2	Name of the service account. In this example, `build-bot`.
3	Name of the pipeline. In this example, `demo-pipeline`.

1	Name of the secret containing the SSH private key. In this example, `ssh-key`.
2	The content of the SSH private key file.
3	The content of the known hosts file.