Create a service a service account in `k8s-infra-prow-build` cluster.

[dargudear-google]

I am working on-recreating a prow job and these prow jobs deleted during migration to community infra. Discussion ref.

I started re-creation of the Job and submitted https://github.com/kubernetes/test-infra/pull/33340/files But when Job was triggered it could not find the serviceaccount secrets-store-csi-driver-gcp job config: https://prow.k8s.io/prowjob?prowjob=3651f2a3-a736-453e-b349-9f29af4a17ce build_serviceaccounts.yaml has the config for serviceaccount secrets-store-csi-driver-gcp`

Can we create a similar account as of old account to re-create the tests?

[BenTheElder]

We usually use workload identity.

The interesting question isn't the service account, it is what resources the service account enables access to.

We need to know what resources are required so we can figure out how to manage them in the community accounts.

We are NOT permitting dependency to external resources not managed by the project within the infra/CI we operate, to prevent future headaches.

[BenTheElder]

@kubernetes/sig-k8s-infra-leads [to track this discussion about providing resources for secre-store-csi-driver testing, I suspect we will need something similar to https://github.com/kubernetes/k8s.io/pull/6924 + make sure boskos handles it]

[dargudear-google]

Service account needs to access the secrets from a project owned by google internally.

This prow job creates a kind cluster, inside kind cluster, secret driver and provider gets installed. This provider needs to access secrets. The baseline requirement is the workload identity that we usually use should be able to act as k8s-csi-test@secretmanager-csi-build.iam.gserviceaccount.com like it was earlier https://github.com/kubernetes/test-infra/blob/master/config/prow/cluster/build/build_serviceaccounts.yaml#L59-L66

[BenTheElder]

Service account needs to access the secrets from a project owned by google internally.

This is not supported. We do not permit taking dependencies on third party accounts. We have just spent years fixing this.

As previously mentioned and outlined, but again https://groups.google.com/a/kubernetes.io/g/dev/c/p6PAML90ZOU/m/11sDguoxAQAJ / https://groups.google.com/a/kubernetes.io/g/dev/c/qzNYpcN5la4

This prow job creates a kind cluster, inside kind cluster, secret driver and provider gets installed. This provider needs to access secrets.

Surely we can identify what a GCP project would need to have in order to do this with a kubernetes.io GCP project?

[dargudear-google]

What If we configure a job like this which used boskos. In the test, a new GKE cluster will be created (using gcloud) along with secret manager secret. We will test the functionality in the cluster. Since we will have our project, there won't be any permission issues.