Open ElSamhaa opened 1 month ago
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?
/assign
Hi @chengjoey, thank you for your quick response. I'd suggest one or all of the following:
serviceAccountName
under the pipelineSpec
. This can be overridden by the current serviceAccountName
of the pipelineRun
serviceAccountName
under both taskSpec
and taskRef
(can be a sibling field to both of them).Hey @ElSamhaa @chengjoey,
The dynamic parameters live in the
pipelinerun
while the more often usable config lives in thepipeline
.
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:
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.PipelineRun
for them. tektoncd/triggers
could be use for this (or something even simpler).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 apipelinerun
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 😓 ).
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.
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.Thanks again for the active engagement from your side and for the great project :slightly_smiling_face:
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-livedpipeline
and the runtimepipelineruns
resources. The dynamic parameters live in thepipelinerun
while the more often usable config lives in thepipeline
. That said, I see some limitations that seem counter-intuitive, to say the least:workspace
bindings in thepipeline
(I understand that this is on the roadmap already)serviceAccounts
in thepipeline
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 apipelinerun
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 wholepipeline
to use a certain fixedserviceaccount
for all its builds. Intuitively, I was expecting aserviceAccountName
under thepipeline
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 theserviceAccountName
can still be treated the same way as it is currently (the same current behavior).