Affinity Assistant doesn't run with PipelineRun's ServiceAccount

[ewolak-sq]

Expected Behavior

If I specify spec.serviceAccountName in a PipelineRun definition, then all tasks and the affinity-assistant pod should run with the specified service account. When I run the below PipelineRun in our fairly locked-down Kubernetes cluster, it fails to execute because the affinity-assistant pod runs as the default service account, which doesn't have permissions to mount PersistentVolumeClaims.

---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: do-a-namespace
  # namespace: RUN_IN_NAMESPACE_Z
  namespace: cloud-cd-demo
spec:
  serviceAccountName: cloud-cd
  pipelineRef:
    # name: SOURCE_FROM_NAMESPACE_Y
    name: do-a-namespace
  podTemplate:
    nodeSelector:
      workload: normal
    tolerations:
      - key: workload
        operator: Equal
        value: normal
        effect: NoSchedule
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
  workspaces:
    - name: repo
      volumeClaimTemplate:
        spec:
          storageClassName: gp2
          accessModes:
            - ReadWriteOnce     # todo: reevaluate for parallel
          resources:
            requests:
              storage: 1Gi

Actual Behavior

Affinity Assistant pod always runs as default ServiceAccount.

Additional Info

• Kubernetes version:

  Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.12", GitCommit:"17c50ce2d686f4346924935063e3a431360e0db7", GitTreeState:"clean", BuildDate:"2020-06-26T03:41:29Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.15-eks-ad4801", GitCommit:"ad4801fd44fe0f125c8d13f1b1d4827e8884476d", GitTreeState:"clean", BuildDate:"2020-10-20T23:27:12Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

• Tekton Pipeline version:

Client version: 0.15.0
Pipeline version: v0.17.3
Triggers version: v0.10.2
Dashboard version: v0.13.0

Discussion

We run Kubernetes clusters with fairly restrictive PodSecurityPolicy specifications to implement the principle of least-privilege. We had to create a custom PSP for Tekton Pipelines, because it needs to perform operations few other things in our clusters also need to do. We apply that PSP to a custom ServiceAccount created specifically for Tekton. This works as expected for PipelineRun and TaskRun pods, but when we add Workspaces to the mix, it falls over. We dug in, and it's because the affinityAssistantStatefulSet doesn't copy the serviceAccountName over from the PipelineRun's podTemplate, instead falling through to the default ServiceAccount in the Namespace. This behavior was rather surprising to us, and I think it's simply an oversight.

[ewolak-sq]

I have a PR ready to go to correct this bug. Just waiting on CLA signature from our OSS team.

[vdemeester]

@ewolak-sq thanks for the report and the PR in preparation 😉
/cc @jlpettersson

[vdemeester]

/assign @ewolak-sq

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[nikhil-thomas]

the pr is not merged yet.
/remove-lifecycle rotten

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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.

[rannox]

I am experiencing the same problem. The affinity assistant pod fails to inherit the designated service account name from the associated PipelineRun. Instead the pod always uses the "default" service account.
Is there any way to override the "default" service account for the affinity assistant pod?