One of the design behind this is to separate the runtime options from the definition spec. ServiceAccount are runtime information, and could be changed without the need for the Pipeline definition to change. And on the opposite side, having ServiceAccountName on a Pipeline definition potentially forces the user of the Pipeline to have those defined.

/kind question

/cc @bobcatfish

I understand and accept this "code"/"runtime" separation, thank you.
Below are some of my thoughts on that, sorry for too much text.

When i define task body it would be really wrong to define runtime options in it.
But by some reason i percieve pipelines as "runtime".
Tasks can be cluster scope, which makes sence to disallow runtime options in task spec.
But there is no such thing as ClusterPipeline, "pipeline definition that supposed to be used in multiple namespaces". And when i create pipeline, i create it in my namespace where i know which sa has required permissions.
If there'd be ClusterPipeline, i'd accept that it couldn't define runtime options.
So when i build my "platform", i provide my users tasks and pipelines that i developed, tested and published for them. Then they take it and build their own, namespaced pipelines, based on my pipelines/tasks plus their own, local tasks. And they rather simplify their pipelineruns as much as possible.
In such system for me there'd be 4 entities:

1. cluster-wide reusable basic blocks(tasks/mini-pipelines, like "deploy to single ns in single cluster")
2. local, namespaced basic blocks(tasks)
3. local, namespaced meta pipelines that compose basic blocks into specific way to run them(run common "build and push" pipeline, run one same common "deploy" pipeline multiple times for all my namespaces in all clusters)
4. local "run" entries that serve just as log "that pipeline has been launched yesterday with next resources: ..."
   And, common pipelines really have nothing to do with runtime configuration. But "local" pipelines are just templates for "runs", so they could have as much predefined runtime configuration as possible.

@vdemeester I was actually looking for something similar, as @dbazhal, but I don't mind if I could define different service accounts per task on the PipelineRun, rather than the Pipeline.

How do other people get around the fact that there might be a pipeline step that requires e.g. cluster-admin privileges, while a step further down still needs access to the k8s api, but not at cluster-admin level?

It seems like the only solution currently is to use a single serviceAccountName ?

@vdemeester never mind. I just found out about Mapping Service Accounts to Tasks.

Sorry for the noise. Leaving it here in case it helps someone else who stumbles upon this issue first.

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

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.

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: Closing this issue.