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)
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.
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
.
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.
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. |
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. |
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
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. |
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
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.
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.
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.