GCP default service accounts best security practices

Question

So, we have a "Compute Engine default service account", and everything is clear with it:

• it's a legacy account with excessive permission
• it used to be limited by "scope" assigned to each GCE instance or instances group
• it's recommended to delete this account and use custom service account for each service with the least privilege principle.

1. The second "default service account" mentioned in the docs is the "App Engine default service account". Presumably it's assigned to the App Engine instances and it's also a legacy thing that needs to be treated similarly to the Compute Engine default service account. Right?

2. And what about "Google APIs Service Agent"? It has the "Editor" role. As far as I understand, this account is used internally by GCP and is not accessed by any custom resources I create as a user. Does it mean that there is no reason to reduce its permissions for the sake of complying with the best security practices?

Answer 1

You don't have to delete your default service account however at some point it's best to create accounts that have minimum permissions required for the job and refine the permissions to suit your needs instead of using default ones.

You have full control over this account so you can change its permissions at any moment or even delete it:

Google creates the Compute Engine default service account and adds it to your project automatically but you have full control over the account.

The Compute Engine default service account is created with the IAM basic Editor role, but you can modify your service account's roles to control the service account's access to Google APIs.

You can disable or delete this service account from your project, but doing so might cause any applications that depend on the service account's credentials to fail

If something stops working you can recover the account for up to 90 days.

It's also advisable not to use service accounts during development at all since this may pose a security risk in the future.

Google APIs Service Agent which

This service account is designed specifically to run internal Google processes on your behalf. The account is owned by Google and is not listed in the Service Accounts section of Cloud Console

Additionally:

Certain resources rely on this service account and the default editor permissions granted to the service account. For example, managed instance groups and autoscaling uses the credentials of this account to create, delete, and manage instances. If you revoke permissions to the service account, or modify the permissions in such a way that it does not grant permissions to create instances, this will cause managed instance groups and autoscaling to stop working.

For these reasons, you should not modify this service account's roles unless a role recommendation explicitly suggests that you modify them.

Having said that we can conclude that removing either default service account or Google APIs Service Agent is risky and requires a lot of preparation (especially that latter one).

Have a look at the best practices documentation describing what's recommended and what not when managing service accounts.

Also, you can have a look at securing them against any expoitation and changing the service account and access scope for an instance.

Answer 2

When you talk about security, you especially talk about risk. So, what are the risks with the default service account.

If you use them on GCE or Cloud Run (the Compute Engine default service account) you have over permissions. If your environment is secured, the risk is low (especially on Cloud Run). On GCE the risk is higher because you have to keep up to date the VM and to control the firewall rules to access to your VM.

Note: by default, Google Cloud create a VPC with firewall rules open to 0.0.0.0/0 on port 22, RDP and ICMP. It's also a security issue to fix by default.

The App Engine default service account is used by App Engine and Cloud Functions by default. Same as Cloud Run, the risk can be considered as low.

---

Another important aspect is the capacity to generate service account key files on those default services accounts. Service account key file are simple JSON file with a private key in it. This time the risk is very high because a few developers take REALLY care of the security of that file.

Note: In a previous company, the only security issues that we had came from those files, especially with service account with the editor role

Most of the time, the user doesn't need a service account key file to develop (I wrote a bunch of articles on that on Medium)

---

There is 2 ways to mitigate those risks.

1. Perform IaC (Infra as code, with product like teraform) to create and deploy your projects and to enforce all the best security practices that you have defined in your company (VPC without default firewall rules, no editor role on service accounts,...)
2. Use organisation policies, especially this one "Disable service account key creation" to prevent the service account key creation, and this one "Disable Automatic IAM Grants for Default Service Accounts" to prevent the editor role on the default service accounts.

---

The deletion isn't a solution, but a good knowledge of the risk, a good security culture in the team and some organisation policies are the key.