Deletion of Default Compute Service Account prevents all VM usage

[Rycieos]

The default for the default compute service account is to delete it on project creation. This will cause many problems if the Compute API is used, preventing any VMs from being created. Obviously, we could change our setting to "keep" instead, but we have had many teams not realize that the default is delete and not make that change. Since the service account can only be undeleted within 30 days, many of my teams have missed that window, tried to create VMs, and realized that their service account is long gone. We have no choice at that point except to create a new project. We tested disabling the Compute API and re-enabling, but the service accounts don't come back. We also contacted Google support, and they affirmed that the only fix is to make a new project.

For this reason, I would prefer that the default is "keep" instead of "delete", since it's less destructive.

If that is too much of a change, I'd like to see another option added, "disable", which disables the service account. This is a better option than "delete", since it has the same outcome (the account doesn't work), but it is possible to get the account back, unlike which delete which can be unrecoverable. This then should be the default, since it achieves the same outcome, but is completely and easily reversible for those that realize they don't want the default later on.

Related to this, the service account doesn't even exist until the Compute API is enabled. I have tested this with some projects. This is the default:

terraform-google-project-factory/variables.tf

Lines 80 to 84 in fa21b22

	variable "activate_apis" {
	description = "The list of apis to activate within the project"
	type = list(string)
	default = ["compute.googleapis.com"]
	}

There are other APIs that are not enabled by default like this, but are instead enabled if a related feature is turned on:

terraform-google-project-factory/modules/core_project_factory/main.tf

Line 45 in fa21b22

activate_apis = var.impersonate_service_account != "" ? concat(var.activate_apis, ["iamcredentials.googleapis.com"]) : var.activate_apis

In this case, if the service account impersonation feature is enabled, then the iamcredentials API is also enabled.

We could do something similar for the Compute API: if the shared_vpc_subnets or shared_vpc inputs are specified, then enable the Compute API. This would prevent the service account being created until someone actually wants to use it.

Related: #181, #186

Thoughts?

[morgante]

The default for the default compute service account is to delete it on project creation. This will cause many problems if the Compute API is used, preventing any VMs from being created.

There is no requirement to use the default compute Service Account to create VMs. It'd be more accurate to say you cannot create any VMs with the default account if it's deleted.

You absolutely still can create VMs, but you have to choose and specify an explicit Service Account for them. This is our best practice, as each VM should ideally have a service account specific to its purpose, instead of sharing a "default" account across all VMs.

Is there a reason this wouldn't work for you? I know it adds complexity, but one of our firm goals here is to promote security best practices, which include not using the default account.

If that is too much of a change, I'd like to see another option added, "disable", which disables the service account.

It sounds like you're looking for the "depriviledge" option, which already exists. It doesn't delete the account but simply removes its permissions.

[Rycieos]

You are correct in that "depriviledge" and "disable" would get to the same end (the account doesn't work), but by depriviledging more work is required to restore the account to its initial state, especially if the user doesn't know what permissions it had before or needs now. I'm not looking to replace the deprivilege option, but to add another that fits our needs better.

I agree that not all VM uses need a default service account, but it seems that most uses through the GCP console assume it's use. When trying to create a Tomcat deployment, I got this message:

You must have a valid default service account in order to create a deployment, but this account could not be detected. Contact support for help restoring the account.

I'll be contacting Google support about this, but assuming there is at least one scenario where you must have the default service account, shouldn't the default not be to delete it?

[morgante]

You are correct in that "depriviledge" and "disable" would get to the same end (the account doesn't work), but by depriviledging more work is required to restore the account to its initial state, especially if the user doesn't know what permissions it had before or needs now. I'm not looking to replace the deprivilege option, but to add another that fits our needs better.

I don't know what you mean by "disable." There's no such thing as "disabling" a service account. You can delete it (as we do by default) or remove its permissions (as depriviledge does).

I agree that not all VM uses need a default service account, but it seems that most uses through the GCP console assume it's use.

When creating a VM in the console, you can select a service account to use.

I'll be contacting Google support about this, but assuming there is at least one scenario where you must have the default service account, shouldn't the default not be to delete it?

We want to keep best practices for defaults. If you require edge scenarios, that's why we have alternative options.

[Rycieos]

There's no such thing as "disabling" a service account.

There is, see disabling a service account. Google even recommends it:

Unlike deleting a service account, disabled service accounts can easily be re-enabled as necessary. We recommend disabling a service account before deleting it to make sure no critical applications are using the service account.

It's not only for custom service accounts; I was able to disable the default compute service account in my projects.

If you require edge scenarios, that's why we have alternative options.

So are you open to a contribution to add an option for disabling the service account instead?

[morgante]

There is, see disabling a service account. Google even recommends it:

Interesting! You learn something new every day—I'd never heard seen this before. Definitely happy to look at a PR which adds this as an option (and potentially even becoming the default).