Tekton does not store secrets itself. It reads Kubernetes Secrets, attaches them to Steps through a ServiceAccount, volumes or environment variables, and leaves protection to the cluster. Good handling means narrow ServiceAccounts, per-pipeline Secrets, no secrets in parameters, and short-lived credentials wherever the target system allows them.
How does Tekton get credentials into a Step?
For Git and container registry access, Tekton has built-in support. You create a Kubernetes Secret of a supported type, add an annotation that starts with tekton.dev/git- or tekton.dev/docker- whose value is the host the credential applies to, and list the Secret under a ServiceAccount. Tekton ignores Secrets that lack the annotation. When a TaskRun uses that ServiceAccount, Tekton writes a Git config or SSH directory, or a Docker config, into the Step container.
For everything else (cloud API keys, signing keys, deploy tokens), you mount the Secret as a volume or inject a key as an environment variable with secretKeyRef. Workspaces can also be backed by a Secret.
Where do teams usually go wrong?
Picture a constructed example. A shared namespace holds one ServiceAccount named pipeline that carries the Git deploy key, the registry push credential and the production kubeconfig. Every pipeline in the namespace runs as it. A contributor adds a Task that runs a test script from a pull request branch. That script now executes with production deploy rights.
The mistakes behind that picture are common:
- One ServiceAccount for everything, so any Task can reach every credential.
- Secrets passed as Task parameters. Parameters appear in the TaskRun object, in the dashboard and in
kubectl describeoutput, so they are not secret. - Environment variables printed by a debugging command, then kept in logs.
- Long-lived tokens with broad scope, never rotated.
- Third-party Tasks from a catalog run with the same ServiceAccount as trusted code.
How do you shrink the blast radius?
Split ServiceAccounts by job. A build pipeline that pushes an image needs a registry write credential and nothing else. A deploy pipeline needs cluster access and no source credential beyond a read-only one. Use separate namespaces where the cost is acceptable, so Kubernetes RBAC does the separating for you.
Mount secrets into the single Step that needs them rather than the whole Task. Steps run as containers in one Pod, and a Step only sees a volume if it declares a mount for it, so declare the mount on that Step alone. Put the sensitive command in its own Step and keep test and lint Steps away from it.
Control who may create TaskRuns and PipelineRuns. Whoever can create a run with a given ServiceAccount can use its credentials. Restrict that permission in RBAC and avoid triggers that run unreviewed branch code with production identity.
Can secrets be avoided entirely?
Often yes. Where the cloud provider supports workload identity, bind the Kubernetes ServiceAccount to a cloud role and let the pod receive a short-lived token. Where a secrets manager exists, fetch at run time with a narrow policy and a short lease. The OWASP secrets management guidance recommends short-lived, automatically rotated credentials and auditing of access for this reason: a stolen token that expires in minutes is a small incident.
Also enable encryption at rest for Secrets in the cluster and check that your log pipeline masks or drops known secret patterns.
What to do
- List every Secret each pipeline touches and delete the ones nobody can explain.
- Create one ServiceAccount per pipeline purpose and attach only its Secrets.
- Move any secret out of Task parameters into a Secret reference.
- Isolate the sensitive command in its own Step and mount the Secret only there.
- Restrict RBAC for creating TaskRuns and PipelineRuns per ServiceAccount.
- Replace static tokens with workload identity or leased credentials where possible.
- Scan repositories and logs for leaked tokens, and rotate anything found.
Secret scanning is a good fit for the Safeguard CLI and IDE extensions, which can catch a token before it lands in a pipeline definition.
Quick check
Does a Tekton Secret annotation make a credential safer?
No. The annotation tells Tekton which host a credential applies to. Safety comes from RBAC, narrow ServiceAccounts and how short-lived the credential is.
Are Task parameters a safe place for a password?
No. Parameters are stored in the run objects and shown in tooling. Use a Secret reference instead.
Sources
- Tekton Pipelines: Authentication
- OWASP Secrets Management Cheat Sheet
- OWASP CI/CD Security Cheat Sheet
Last reviewed: 18 October 2026.
