How do you manage secrets and credentials in Tekton Pipelines?
Quick Answer
Tekton Pipelines access secrets through Kubernetes Secret resources mounted as environment variables or volume files in Task steps, with service account annotations providing automatic Git and Docker registry authentication, and external secret managers like HashiCorp Vault injecting credentials at runtime.
Detailed Answer
Think of managing secrets in Tekton like handling keys in a large hotel. The front desk has a master key cabinet that guests never access directly. Instead, the concierge hands each guest only the specific room key they need, and the key is collected when they check out. In Tekton, Kubernetes Secrets are the key cabinet, service accounts are the concierge, and Task steps are the guests who receive only the credentials they need for the duration of their execution.
The most fundamental approach is creating Kubernetes Secret resources and referencing them in Task step definitions. You can mount secrets as environment variables using the envFrom or env with valueFrom.secretKeyRef syntax, or as files using volume mounts with a secret volume type. For the payments-api pipeline, a database migration step needs the DATABASE_URL connection string. Rather than hardcoding it in the Pipeline definition, you create a Secret containing the connection string and reference it in the step's env block. The step container sees the credential as a normal environment variable, and the Secret value never appears in Pipeline YAML, TaskRun logs, or Tekton dashboard displays. For credentials that must be files, such as GCP service account JSON keys or TLS certificates, volume-mounting the Secret to a specific path like /etc/secrets/sa-key.json gives the step direct file access while keeping the credential managed through Kubernetes RBAC.
Tekton provides a specialized mechanism for Git and Docker registry authentication through annotated Secrets linked to service accounts. By creating a Secret of type kubernetes.io/basic-auth with a tekton.dev/git-0 annotation pointing to the Git server URL, and attaching it to the service account used by the TaskRun, Tekton automatically configures Git credential helpers inside every step container. The same pattern works for Docker registries using kubernetes.io/dockerconfigjson secrets with tekton.dev/docker-0 annotations. When the user-auth-service pipeline clones a private repository and pushes images to a private registry, the service account carries both the Git credentials for cloning and the Docker credentials for pushing, without any explicit Secret references in the Task definition. This declarative approach centralizes credential management at the service account level and decouples Task definitions from specific credential implementations.
For enterprise environments, integrating external secret managers provides dynamic credential rotation and fine-grained audit trails that Kubernetes Secrets alone cannot offer. HashiCorp Vault integration typically uses the Vault Agent sidecar injector, which adds init containers and sidecar containers to TaskRun pods that fetch secrets from Vault and write them to a shared in-memory volume. The External Secrets Operator is another popular approach that synchronizes secrets from AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager into Kubernetes Secret resources, which Tekton Tasks then consume through standard volume mounts or environment variables. For the inventory-sync service that connects to third-party supplier APIs with rotating API keys, the External Secrets Operator ensures that the Kubernetes Secret always contains the current API key, and Tekton Tasks pick up the fresh credentials on every run without pipeline changes.
Security best practices demand treating Tekton secret management as a defense-in-depth problem. Never echo secret values in step scripts, as TaskRun logs are accessible through kubectl and the Tekton dashboard. Use Kubernetes RBAC to restrict which service accounts can access which Secrets, applying the principle of least privilege so that the checkout-service pipeline cannot read Secrets belonging to the payments-api pipeline. Enable encryption at rest for etcd to protect Secret values stored in the cluster. Rotate credentials regularly and use short-lived tokens where possible, such as OIDC tokens for cloud provider authentication instead of long-lived service account keys. Tekton Chains can sign TaskRun and PipelineRun attestations, providing a verifiable record that specific credentials were used during specific pipeline executions, supporting compliance requirements for SOC 2 and PCI DSS environments.