Question about best practices for service accounts GKE Autopilot

[g3289ds]

https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity has two methods to configure workload identify federation. One is to create an iam policy via a binding with a kubernetes service account. The alternative is to "link Kubernetes ServiceAccounts to IAM" which requires manually creating each iam policy to link a kubernetes service account with. We have had much better experience with the latter method and continue to use it. What I want to know is if its best practice to create an IAM account for each service and link each service account. As far as creating an IAM account for each service it looks like it is the case like it says under

https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#authenticating_to  "To let your GKE applications authenticate to Google Cloud APIs using Workload Identity Federation for GKE, you create IAM policies for the specific APIs"

But that was for method one and I am not sure it applies to the alternative method.

EDIT: Additionally, if services are in multiple clusters that perform the same action and access the same db, but should be isolated from each other, should there be an iam service account created and linked for those different services in each cluster?

[JanR]

Hi @g3289ds ,

The best practice is to create dedicated service accounts for each service, rather than IAM user accounts. 

Here's a few reasons why:

• Minimizing Potential Damage: Assigning specific permissions to each service account follows the principle of least privilege. Each service can only access the resources it needs to function, minimizing potential damage.
  
  
• Security: If one of the service accounts is compromised, the attacker's access is limited to the resources of that specific service account's permitted resources only.
  
  
• Isolation: using separate service accounts, you can isolate services across clusters.  Even if they perform similar actions, they won't be able to access each other's resources or interfere with each other's operations.

Separate IAM service accounts for those services in each cluster is the recommended approach with the same reasons above.

[g3289ds]

Can you clarify what you mean by dedicated service account? Are you referring to KSAs or dedicated IAM service account? To be clear I was talking about for each service an IAM service account and ksa pair would be created. I don't understand how binding an IAM account to more than one ksa (with the ksa binded with a workloadidentity role) would be more secure. I don't understand how a ksa could function if it didn't have the workloadidentity role.

EDIT: As an addendum I know I can add multiple roles to a ksa binding, but the reason why I put emphasis on workloadIdentityUser role was because (I am having trouble finding where I saw it) I saw it had maximum exceeded permissions and it seemed like a problem to have multiple ksa with that.

[shannduin]

1. Yeah, in both cases you create a policy in IAM. In the recommended method, the principal in the policy is a k8s service account or UID or something else. In the alternative method, the principal is the IAM service account
2. Yes, it's a good idea to create a separate account per action that needs to be taken, but if you need extra isolation sure, use separate accounts. But in that case would it be more manageable to create IAM policies that directly reference the associated k8s SA without adding the IAM SA on top?

[g3289ds]

"But in that case would it be more manageable to create IAM policies that directly reference the associated k8s SA without adding the IAM SA on top?"

Can you show how to do this?

[shannduin]

This is the method that we show in the main part of the how-to (https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#configure-authz-principals) - you create an IAM allow policy that grants a role directly to a k8s SA without needing the intermediary IAM SA.

[g3289ds]

I wanted to do alternative because we may need cloud functions or one of the many other functions listed in https://cloud.google.com/iam/docs/federated-identity-supported-services. But this clarifies things. For the alternative method is there a way to add metadata to the iam account for easy identification for cluster or namespace we want to use it for? The IAM sa name before email part is limited to 30 character.

[shannduin]

You could potentially use the recommended method (no IAM SA) for most situations, and if you wanted to do something like use Container Registry from a GKE Pod, you'd use the alternative method for just that. You're not locked in to a specific method, you can use both in a cluster. 

For identification, you could:

• try adding `--description` when creating the IAM SA (https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/create#--description)
• Use Tags (bit more complex to set up but it's intended for this, plus you can control access to those service accounts based on the Tags that they have.