Terraform: no way to appoint a service account in GKE

[d00rk33p3r]

What happened:

When creating a deployment using GKE Terraform module, there was no way to use a service account to provision Agones in GCP.

What you expected to happen:

There should be a way of using a different service account than the default one, which is a useful practice, mainly when you are deploying using automated means, like Jenkins. In my environment, the default service account is disabled and it is necessary to create a new one for each service in GCP, through Terraform. So, without a mean to associate a new service account to Agones, it is impossible to make a sane deployment using Agones install terraform scripts.

How to reproduce it (as minimally and precisely as possible):

• Try to create a Terraform script which creates a service account.
• Use this newly created service account as owner of all objects related to Agones in GCP.

Anything else we need to know?:

Environment:

• Agones version: 1.33.0
• Kubernetes version (use kubectl version): 1.26.0
• Cloud provider or hardware configuration: GCP
• Install method (yaml/helm): Terraform
• Troubleshooting guide log(s):
• Others:

[markmandel]

Just so I'm clear on this - you would want some kind of serviceaccount variable in the terraform scripts?

Or to ask another way - what would you like the experience to ideally look like?

[d00rk33p3r]

Hi, @markmandel. Thanks for your reply.

Here is my use case scenario: currently, our default service account is disabled for security reasons. Our devops team requires that each service created within GCP should create its own service account, which must be limited to the scope of the service itself.

Agones GCP Terraform has, as its premise, that everything will be ran under a default service account. Therefore, in my scenario, I just can't use it. I had to create my own version adding a service account to each node pool.

I can create a PR with some changes so you will be able to revise it. I think that an input variable should do the trick. However, adding a new input variable should not change the current behavior, otherwise it will break everyone that is using that module the way it was designed originally.

[zmerlynn]

@d00rk33p3r: Happy to review such a PR!

[github-actions[bot]]

'This issue is marked as Stale due to inactivity for more than 30 days. To avoid being marked as 'stale' please add 'awaiting-maintainer' label or add a comment. Thank you for your contributions '

[github-actions[bot]]

This issue is marked as obsolete due to inactivity for last 60 days. To avoid issue getting closed in next 30 days, please add a comment or add 'awaiting-maintainer' label. Thank you for your contributions