Ability to add serviceAccountName per task in pipeline

[ElSamhaa]

Feature request

Hello, thanks for the great project. First, after searching the issues, I believe many people can relate to this request.

IIUC, the pipeline behavior is dictated by the definition of the long-lived pipeline and the runtime pipelineruns resources. The dynamic parameters live in the pipelinerun while the more often usable config lives in the pipeline. That said, I see some limitations that seem counter-intuitive, to say the least:

• The inability to predefine fixed workspace bindings in the pipeline (I understand that this is on the roadmap already)
• The inability to predefine fixed serviceAccounts in the pipeline

The developers don't want to feed in meaningless strings each time they trigger a build. It's pointless because it's fixed for all pipelineruns and they're not relevant to them. Besides, "fixed" means they're not parameters => we should have the option to specify them once and forget about them.

Now, adding to the above, the fact that many of the tekton pipeline users are on Openshift, we hit another limitation which is Openshift doesn't prompt for serviceAccounts for a pipelinerun on its web GUI (at least until Openshift 4.12).

Use case

I want some tasks to interact with the Kubernetes API server. For this, I need to configure certain tasks or the whole pipeline to use a certain fixed serviceaccount for all its builds. Intuitively, I was expecting a serviceAccountName under the pipeline task (each task in the list resolves to a pod, so the implementation should be simple). IMO, I would even say that adding this capability shouldn't break anything as the omission of the serviceAccountName can still be treated the same way as it is currently (the same current behavior).

[chengjoey]

Currently, you can set a default serviceAccountName or pipelineRun for all pipelines and tasks, and taskRun can also set a separate serviceAccountName. you want to add a field serviceAccountName to taskSpec so that you can define serviceAccountName for a certain type of task, and when taskref references it, it will directly inherit the serviceAccountName of this taskSpec, rigth?

pipeline/config/config-defaults.yaml

Lines 44 to 46 in 8399613

	# default-service-account contains the default service account name
	# to use for TaskRun and PipelineRun, if none is specified.
	default-service-account: "default"

[chengjoey]

/assign

[ElSamhaa]

Hi @chengjoey, thank you for your quick response. I'd suggest one or all of the following:

• Allow specifying serviceAccountName under the pipelineSpec. This can be overridden by the current serviceAccountName of the pipelineRun
• Allow specifying serviceAccountName under both taskSpec and taskRef (can be a sibling field to both of them).

[vdemeester]

Hey @ElSamhaa @chengjoey,

The dynamic parameters live in the pipelinerun while the more often usable config lives in the pipeline.

So the fact that it is not possible today is by design. Pipeline (and Task) are definition types, meant to be shareable, across different environment (cluster, teams, company, …). It's not really dynamic versus … but definition versus runtime. Any runtime specific information is on the PipelineRun. And the serviceAccount is a runtime information.

Adding serviceAccountName to a definition type make it less portable, because now, using this Pipeline (or Task) requires a specific serviceAccountName to be present — and the user has no context other than the name of the service account (what privileges or secrets the serviceAccount need, … he has to still figure it out).

How should tekton re-act if the serviceAccountName in the Pipeline is not present ? Do we fail when applying the Pipeline or do we fail when the PipelineRun is started ? Do we do a "fail to the default service account if the provided service account is not present" ?

In my opinion, there is a couple ways around this:

• If it's "per-namespace" that the default ServiceAccountName needs to be changed, the cluster-admin could ensure a configured service account is set on the namespace and let the "project admin" (the namespace owners) modify this service account at will… or this TEP could be of interest.
• Users could be exposed to an API (a small HTTP API) that does the work of creating the PipelineRun for them. tektoncd/triggers could be use for this (or something even simpler).
• Users could be exposed to another type (simpler) that would then create the PipelineRun. Or even some kustomize based solution. (tekton.dev still states "Tekton is a powerful and flexible open-source framework for creating CI/CD systems", PipelineRun are not necessarily meant to be directly exposed to users).

Now, adding to the above, the fact that many of the tekton pipeline users are on Openshift, we hit another limitation which is Openshift doesn't prompt for serviceAccounts for a pipelinerun on its web GUI (at least until Openshift 4.12).

This is a "client" limitation and should be reported here (SRVKP) (not that this is a known issue and a long-overdue one 😓 ).

[ElSamhaa]

Thanks @vdemeester for your comment. I understand this is by design as I could follow from former discussions. I hoped to provide some feedback and a different perspective nonetheless.

• I get the "definition" vs "runtime" argument, but IMO, this standpoint doesn't provide much room for other cases like when the serviceAccountName is fixed. Even resolving client limitations like Openshift doesn't tackle the fact that there is no way to set a default value per pipeline and just forget about it.
• In my experience, pipelines usually targeted niche requirements so much that they'd be hard to be portable. Tasks, on the other hand, are very good candidates for portability.
• IMHO, by-design limitations/restrictions are welcome against bad practices, but in this case, however, I'd say these only serve certain use cases and neglect other "legitimate" ones.

Thanks again for the active engagement from your side and for the great project 🙂