ServiceAccountName in PipelineRun is not used in TaskRuns

[jlpettersson]

Expected Behavior

That the serviceAccountName I set in a PipelineRun is used in the TaskRuns

Actual Behavior

The specified serviceAccountName is not used, but the default is used.

Steps to Reproduce the Problem

1. specify a custom serviceAccountName in PipelineRun.spec.ServiceAccountName
2. trigger a new run
3. verify what serviceAccountName was used in the pod

Additional Info

• Kubernetes version:

  Output of kubectl version:
  server 1.17.9-eks

• Tekton Pipeline version:

Pipeline version v0.17.0
Trigger version v0.8.1
Client version: 0.13.0

[jlpettersson]

There is actually the same problem with:

serviceAccountNames:
- taskName: my-task
  serviceAccountName: my-custom-service-account

in the PipelineRun - specified in a TriggerTemplate.

[vdemeester]

@jlpettersson I can't reproduce this, at least not from the pipeline side. I wrote a test trying to replicate this and… it doesn't fail 😓 See #3420

[vdemeester]

@jlpettersson should we close ? 🤔

[jlpettersson]

Yes, we can close, and I can reopen if I can reproduce it.

[jlpettersson]

This is the resources I had:

The PipelineRun with ServiceAccountName: pipeline-runner

$ kubectl get pr pipeline-ltjvz -o yaml
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  creationTimestamp: "2020-10-20T13:18:28Z"
  generateName: pipeline-
  generation: 1
  labels:
    tekton.dev/pipeline: pipeline
    triggers.tekton.dev/eventlistener: github-trigger
    triggers.tekton.dev/trigger: ""
    triggers.tekton.dev/triggers-eventid: lctk6
  name: pipeline-ltjvz
  namespace: cicd
  resourceVersion: "4380087"
spec:
  params:
  - name: git-url
    value: git@github.com:something
  - name: commit
    value: 0377b1c564e2e449934f4028e0279dccf78837ca
  pipelineRef:
    name: pipeline
  serviceAccountName: pipeline-runner
  taskRunSpecs:
  - pipelineTaskName: git-clone
    taskPodTemplate:
      volumes:
      - name: ssh-auth
        projected:
          defaultMode: 256
          sources:
          - secret:
              name: github-known-hosts
          - secret:
              name: github-private-key
  timeout: 1h0m0s
  workspaces:
  - name: ws
    volumeClaimTemplate:
      metadata:
        creationTimestamp: null
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi
      status: {}

and the TaskRun, with ServiceAccountName: default

$ kubectl get tr pipeline-ltjvz-git-clone-p4rhp -o yaml
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
    pipeline.tekton.dev/affinity-assistant: affinity-assistant-5904a5654b
    pipeline.tekton.dev/release: ""
    tekton.dev/displayName: git clone
    tekton.dev/pipelines.minVersion: 0.12.1
    tekton.dev/tags: git
  generation: 1
  labels:
    app.kubernetes.io/managed-by: tekton-pipelines
    app.kubernetes.io/version: "0.2"
    tekton.dev/pipeline: pipeline
    tekton.dev/pipelineRun: pipeline-ltjvz
    tekton.dev/pipelineTask: git-clone
    tekton.dev/task: git-clone
    triggers.tekton.dev/eventlistener: github-trigger
    triggers.tekton.dev/trigger: ""
    triggers.tekton.dev/triggers-eventid: lctk6
  name: pipeline-ltjvz-git-clone-p4rhp
  namespace: cicd
  ownerReferences:
  - apiVersion: tekton.dev/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: PipelineRun
    name: pipeline-ltjvz
    uid: 992dac4c-b632-439f-bf38-3f55cbe0c04d
  resourceVersion: "4380085"
spec:
  params:
  - name: url
    value: git@github.com:something
  - name: revision
    value: 0377b1c564e2e449934f4028e0279dccf78837ca
  podTemplate:
    volumes:
    - name: ssh-auth
      projected:
        defaultMode: 256
        sources:
        - secret:
            name: github-known-hosts
        - secret:
            name: github-private-key
  resources: {}
  serviceAccountName: default
  taskRef:
    kind: Task
    name: git-clone
  timeout: 1h0m0s
  workspaces:
  - name: output
    persistentVolumeClaim:
      claimName: pvc-5904a5654b

I was a bit surprised that this happened. But now I think it was the combination of some fields in taskRunSpecs: and ServiceAccountName: that caused this.

[vdemeester]

I was a bit surprised that this happened. But now I think it was the combination of some fields in taskRunSpecs: and ServiceAccountName: that caused this.

Oh, let's add this to the test to see, I'll re-open for now.

[vdemeester]

/assign

[vdemeester]

@afrittoli @pritidesai @sbwsg Do we want this in 0.17.2 ? (My initial thought is yes)

[ghost]

@vdemeester It makes sense to me to include it in 0.17.2, yeah.