The Tekton Secrets Workspace allows you to securely inject credentials into your Tasks without exposing them directly in your Task definitions or logs.
Let’s see this in action. Imagine you have a Task that needs to clone a Git repository using SSH keys.
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: git-clone-with-ssh
spec:
params:
- name: repo-url
type: string
description: The Git repository URL
workspaces:
- name: ssh-creds
mountPath: /workspace/ssh
secret:
secretName: git-ssh-key
steps:
- name: clone
image: alpine/git
script: |
#!/bin/sh
echo "Cloning repository..."
# The SSH key is available at /workspace/ssh/id_rsa
# Set SSH_KEY_FILE environment variable for git to use
export SSH_KEY_FILE=/workspace/ssh/id_rsa
git clone $(params.repo-url) /workspace/repo
echo "Cloned successfully!"
In this example, the git-clone-with-ssh Task defines a workspace named ssh-creds. This workspace is configured to mount a Kubernetes Secret named git-ssh-key at /workspace/ssh inside the Task’s container. The secretName field directly references the Kubernetes Secret that holds your SSH private key.
Here’s the corresponding Kubernetes Secret:
apiVersion: v1
kind: Secret
metadata:
name: git-ssh-key
type: Opaque
data:
# Your SSH private key, base64 encoded
id_rsa: c2VjcmV0IGtleSBpbnN0YWxsYXRpb24K
When this Task runs, the contents of the git-ssh-key Secret are made available at the specified mountPath. In this case, the id_rsa key from the Secret will be accessible as /workspace/ssh/id_rsa within the clone step. The Task can then use this file as its SSH private key to authenticate with the Git server.
The key insight here is that the actual sensitive data (your SSH private key) never appears in the Task definition itself. It’s managed entirely by Kubernetes Secrets, and Tekton provides a secure mechanism to inject it into your running Tasks. This greatly improves security by reducing the attack surface and adhering to the principle of least privilege.
To use this Task, you’d create a PipelineRun that references the Task and provides the repo-url parameter. The ssh-creds workspace would be implicitly handled by Tekton, which would fetch the git-ssh-key Secret and make it available.
The secret field within the workspace definition is what tells Tekton to look for a Kubernetes Secret. You can specify secretName to point to a specific Secret. Tekton then mounts this Secret as a volume into the Task’s pod, making the keys within the Secret available as files in the specified mountPath.
What most people miss is that the keys within the Kubernetes Secret become filenames within the mountPath. So, if your Secret has keys like id_rsa, config, and known_hosts, they will appear as /workspace/ssh/id_rsa, /workspace/ssh/config, and /workspace/ssh/known_hosts respectively. This allows you to directly reference these files within your Task’s scripts or commands.
The next logical step is to explore how to use different types of secrets, like those for cloud provider authentication or image registry credentials, with Tekton workspaces.