Monitor task with 0.8 openshift-pipelines operator picks up wrong service account name

[sthaha]

With the operator (canary channel):

adams-mbp:newappsody aroberts$ k get taskrun monitor-taskrun-22qbz -o yaml | grep service
  serviceAccount: tekton-webhooks-extension
  serviceAccountName: pipeline

I created my webhook with the SA as tekton-webhooks-extension, pipeline is a built-in SA which doesn't have the permissions I need so my monitor task gets an RBAC error

Without

adams-mbp:newappsody aroberts$ k get pod monitor-taskrun-q4mmr-pod-64d031 -o yaml | grep serviceAccount
  serviceAccount: tekton-webhooks-extension
  serviceAccountName: tekton-webhooks-extension

@dibbles spotted https://github.com/openshift/tektoncd-pipeline-operator/blob/master/pkg/flag/flag.go which is potentially a clue (notice the SA name defaulting to pipeline)

Copy of: tektoncd/experimental#388

[sthaha]

From the report it appears to me that the serviceAccountName field is empty and hence the tekton-webhook-controller uses the default service-account - pipeline.
If you have explicitly set a service-account for your task, then it should be run using that serviceAccount.

[nikhil-thomas]

@a-roberts, @dibbles
please use serviceAccountName (as the field serviceAccount is deprecated)
ref: https://github.com/tektoncd/pipeline/blob/00116034e0e4093a51a395dc715c1679565fa77a/pkg/apis/pipeline/v1alpha1/taskrun_types.go#L41

in a PipelineRun or TaskRun if a seviceAccount (serviceAccountName) is not specified, pipline-controller use the one specified in https://github.com/tektoncd/pipeline/blob/v0.8.0/config/config-defaults.yaml
ref: tektoncd/pipeline#1227

In upstream releases the confidDefaults config map is empty. However, during installation using operator on openshift the operator will check the config map, if default-service-account is not set it will be set to pipeline
ref:

tektoncd-pipeline-operator/pkg/controller/config/config_controller.go

Line 286 in 76681e8

transform.InjectDefaultSA(flag.DefaultSA),

[vdemeester]

So, I think it's upstream code that only populate the serviceAccountName and do not care at all with serviceAccount (by that I mean, do not touch it, do not read it for settings defaults)

	defaultSA := cfg.Defaults.DefaultServiceAccount
	if trs.ServiceAccountName == "" && defaultSA != "" {
		trs.ServiceAccountName = defaultSA
	}

This will be, most likely, a wontfix, as 0.9.0 is now released with serviceAccount at all (so we would fix something that… is gonna go away really soon)

[a-roberts]

I reckon this is still a won't fix and we're good using serviceAccountName so let's close this one? No problems now, all good!

[vdemeester]

Yes, this will be fixed with the bump to 0.10.1 👼