Declaring Task specific Volumes vs Workspaces

[jlpettersson]

Expected Behavior

That Tasks are reusable — independent of runtime environment

Actual Behavior

I proposed an alternative git-clone Task with more "Kubernetes native" use of Secrets in tektoncd/catalog#309 — mounting Secrets from a Projected volume.

spec:
  workspaces:
    - name: output
      description: The git repo will be cloned onto the volume backing this workspace
  params:
    - name: url
      type: string
      description: git url to clone
  steps:
    - name: git-clone
      image: bitnami/git:2.26.2
      command: ['git', '-c', 'core.sshCommand=ssh -i /etc/ssh/id_rsa', 'clone', '$(params.url)', '$(workspaces.output.path)']
      volumeMounts:
        - mountPath: /etc/ssh
          name: ssh-auth
  volumes:
    - name: ssh-auth
      projected:
        defaultMode: 0400
        sources:
          - secret:
              name: github-known-hosts
          - secret:
              name: github-private-key

There is also a git-clone Task example in #2642 that is using secrets from Azure Key Vault with examples — using Secrets mounted from a PersistentVolumeClaim volume.

spec:
  stepTemplate:
    image: alpine/git:v2.24.3
    command: ["git"]
    volumeMounts:
      - name: "secrets"
        mountPath: "/mnt/secrets-store"
        readOnly: true
  params:
    - name: "git-url"
    - name: "secret-provider"
    - name: "store-cred"
  steps:
    - name: "git-config"
      command: ["sh", "-c", "git config --global credential.helper store"]
    - name: "set-credential"
      command:
        - "sh"
        - "-c"
        - |-
            user=`cat /mnt/secrets-store/git-username`
            pass=`cat /mnt/secrets-store/git-password`
            url=`cat /mnt/secrets-store/url`
            echo "https://$user:$pass@$url" > ~/.git-credentials
    - name: "git-checkout"
      args: ["clone", "$(params.git-url)"]
      workingDir: "/workspace"for
  volumes:
    - name: "secrets"
      persistentVolumeClaim:
        name: "$(params.claimName)"

The two examples above are almost an identical Task - but is mounting Secrets from different types of volumes. This shows that a volume really is a runtime consideration - and we usually declare runtime considerations in PipelineRun and TaskRun.

Volumes, may be mounted to Tasks in a Pipeline using a workspace. Tasks may also mount volumes individually.

Nature of Workspaces

I see workspaces as volumes to share files between Tasks. It is a very useful abstraction since many tasks in a CI-pipeline typically is file-operations.

Volumes specific to a Task

The above two Tasks shows examples of "private" volume-mounts. It would be more natural to declare these volumes - as a runtime consideration - but specific for the Task.

It is possible to declare a workspace intended for a specific Task in a PipelineRun, but that workspace must be carefully mapped in the correct PipelineTask by workspace name. With #2389 there is an alternative way to declare a volume specific Task in a PipelineRun - proposed in #2362. This is an implemented feature that we probably should use and document for these cases. I also may revert my #2601 (not in any release yet).

An example of setting Volume for a specific PipelineTask using the TaskRunSpec:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: git-clone-ssh-
spec:
  pipelineRef:
    name: pipeline-with-git-clone
  taskRunSpecs:
  - pipelineTaskName: git-clone         # name of task in the Pipeline
    taskPodTemplate:
      volumes:
      - name: ssh-auth                  # name of volume - matching name in Task
        projected:
          defaultMode: 0400
          sources:
          - secret:
              name: github-known-hosts  # name of Secret from Auth setup
          - secret:
              name: github-private-key  # name of Secret from Auth setup

/kind design
/kind documentation

[jlpettersson]

This was discussed in the API WG today. I am closing this now, when it has been discussed.