[v2.9] Add ability to specify a service account for a node pool in a GKE cluster

[yiannistri]

The gke-operator (in v2.9) now supports the ability to specify a service account for a node pool. This is an optional field that may be set to an email address of a service account that has limited permissions, for example test@test-project.iam.gserviceaccount.com.

To set this field, one needs to set the value for field .spec.nodePools[*].config.serviceAccount. If not set, the default service account will be used.

There is currently no API method that lists the service accounts for a project, that the UI could invoke to help the user pick a service account. Adding such an API is possible but it would require additional permissions for the GKE service account that Rancher uses, i.e. to include the roles/iam.serviceAccountViewer IAM role. There is actually an existing endpoint that can be used, proposed in the comments below.

Relates to rancher/gke-operator#262

[gaktive]

Will transfer this to dashboard repo for better UI tracking since I don't see direct backend work here.

[gaktive]

Internal reference: SURE-3099

@mantis-toboggan-md recently touched the GKE area and @eva-vashkevich has been looking at service accounts. However, this may require design so need to check with @nwmac and @kwwii if this is more than just a field.

[richard-cox]

There will probably (?) be a lot of service accounts, so we should avoid doing a findAll (almost all will be removed by 2.10.0). @yiannistri are there any other definitive ways to select the applicable accounts, like labels or annotations?

[yiannistri]

@richard-cox just to be clear, for this particular scenario I'm referring to GCP IAM Service Accounts (not to be confused with Kubernetes service accounts). These service accounts are assigned to node pools in order to restrict what GCP services can be accessed from a cluster.

I agree with you that potentially this would return a lot of data, however this would need a call to the GCP API from server-side. So we can't use labels or annotations.

[mantis-toboggan-md]

It looks like there may already be an endpoint for the UI to use here, as GKE provisioning v1 included the option to set service accounts for node pools, see ui code here and norman api code here - does this existing API functionality look adequate @yiannistri?

[yiannistri]

@mantis-toboggan-md yes that looks adequate 👍

[mantis-toboggan-md]

Excellent, then it sounds like we're not backend-blocked on this issue. I have a couple more questions @yiannistri:

1. That api call returns a list of these objects: https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts#ServiceAccount. Your example appears to correspond to the email field; is this what we would using in .spec.nodePools[*].config.serviceAccount?
2. When the user selects the 'use the default service account' option in the UI, can we leave .spec.nodePools[*].config.serviceAccount blank, or do we need to set the value based off the "Compute Engine default service account" I see returned from this gkeServiceAccounts API call?

[yiannistri]

1. That api call returns a list of these objects: https://cloud.google.com/iam/docs/reference/rest/v1/projects.serviceAccounts#ServiceAccount. Your example appears to correspond to the email field; is this what we would using in .spec.nodePools[*].config.serviceAccount?

Yes, please use the email field.

2. When the user selects the 'use the default service account' option in the UI, can we leave .spec.nodePools[*].config.serviceAccount blank, or do we need to set the value based off the "Compute Engine default service account" I see returned from this gkeServiceAccounts API call?

You can leave the field blank. Setting it to the "Compute Engine default service account" will have the same effect but it's probably simpler to not set it/set it to an empty string. I also think that that description may be editable by a user.