Handling Secrets in Pipeline-as-code

[skaegi]

One challenge we run into when using Tekton for pipeline-as-code is around handling the creation of Secrets used both by PipelineResources (which require specific type and annotations) as well as the more typical Secrets used in Steps.

A typical case has us in response to an event create a single-use namespace and laydown definitions for Pipelines, Tasks, ConfigMaps, etc. We then generate a PipelineRun and the particular set of PipelineResources that will be used as well as do some totally non-standard magic to create Secrets. So, in particular this issue is to see if there is anything we can do to standardise the process.

There are many excellent secret management tools available and I'm hoping we can find a way to use them. They typically either store secret values encrypted or else store the values externally in a secure store.

There are two approaches that I'd like to propose but am certainly looking for others...

1. Create a TektonSecret CRD very similar in spirit to SealedSecret and ExternalSecret. In particular I would like us to be able to support both the encrypted and external cases. Both these approaches generate an associated Secret and I really like the templating support in SealedSecrets.

For example:

apiVersion: apiVersion: tekton.dev/v1alpha1
kind: TektonSecret
metadata:
  name: my-secret
spec:
 # One of encryptedData or secretDescriptor
  encryptedData:
    ssh-privatekey: <encrypted data>
    known_hosts: <encrypted data>
  secretDescriptor:
   backendType: secretsManager
   data:
    - key: my-service/ssh-privatekey
      name: ssh-privatekey
    - key: my-service/known_hosts
      name: known_hosts
  template:
    metadata:
      name: ssh-key
      annotations:
        tekton.dev/git-0: github.com # Described below
    type: kubernetes.io/ssh-auth

2. Use Tekton specific annotations on standard Kubernetes Secrets. No templating needed.

For example:

apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
  annotations:
    tekton.dev/git-0: github.com # Described below
    tekton.dev/secret: encryptedData
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: <encrypted data>
  known_hosts: <encrypted data>

OR

apiVersion: v1
kind: Secret
metadata:
  name: ssh-key
  annotations:
    tekton.dev/git-0: github.com # Described below
    tekton.dev/secret: secretDescriptor
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: secretsmanager://my-service/ssh-privatekey
  known_hosts: secretsmanager://my-service/known_hosts

I've left details out on how to decrypt or access the secretsmanager however I'm hoping we could figure that out using the serviceAccount or similar. This issue is mostly for now looking at the format of secrets we could safely check-in to a git repo and then unpack at runtime.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[bobcatfish]

I wonder if the work that @sbwsg has been doing around credentials will be the solution the original problem described here #2343