VM Instance Using the Default Service Account

About Google Cloud Service Accounts

On Google Cloud, a service account (SA) serves as the IAM identity of an application or a virtual machine (VM) instance. Using the attached service account, a VM or application can authenticate and authorize itself to access Google Cloud APIs and resources. For example, attaching an SA to a Linux VM allows a web server running on it to use the SA credentials to access a Google Cloud SQL database.

A service account can’t be assigned to a person.

There are two main kinds of service accounts:

• User-managed service accounts: As the name indicates, these are created by Google Cloud users via the IAM API, gcloud, or the Cloud Console.
• Default service accounts: These are automatically created by Google if a user doesn’t specify a service account while running a Google cloud service.

Every service account has a permission set attached to it that determines the level of privileges the associated VM or application can have. The default Compute Engine service account has editor permissions. This is the service account that usually gets assigned to instances that don’t have any user-defined SA specifications.

Cloud Risk Description

The editor privileges of the default compute engine service account grant read and write access to almost all Google Cloud services and resources. This means that all VM instances using the default service account can perform virtually any action in your infrastructure. This is in violation of the principle of least privilege, according to which a VM instance should not have more than the bare-minimum privileges, to perform required actions.

How Does Orca Help?

Orca detects and prioritizes identity and access management misconfigurations such as weak and leaked passwords, exposed credentials, and overly permissive identities. In this specific case, Orca helps by looking for “VM instances that are using the default service account” and will alert on this type of issue as shown in the screenshot above.

• Discover and prioritize cloud IAM risk Find out more about VM Instance Using the Default Service Account.

Related Risks

• Service account with administrator privileges within project scope

  User-defined accounts with administrator privileges at the project level can be used to create/delete/modify projects, and/or Google Cloud resources. This is also in violation of the principle of least privilege.

Recommended Mitigation Strategies

• Avoid Default Service Accounts

  Whenever possible, avoid using default service accounts. Create a new service account instead.

• Manage Editor Privileges

  If you are using the default compute engine service account, be sure to revoke its editor privileges.

• Disable Necessary Constraints

  Disable the “iam.automaticIamGrantsForDefaultServiceAccounts” boolean constraint. This will ensure that default SAs don’t automatically get editor privileges.

• Apply Principle of Least Privilege

  Always apply the principle of least privilege while defining policies for your service accounts.

• Use Short-lived Credentials

  When giving privileges to third parties, use short-lived service account credentials.

• Manage Privileges

  Don’t allow users or applications to assume service accounts that have more privileges than the users or applications themselves.

Useful Links

• Service accounts on GCP: https://cloud.google.com/compute/docs/access/service-accounts
• Best practices for securing service accounts: https://cloud.google.com/iam/docs/best-practices-for-securing-service-accounts
• Managing service account keys: https://cloud.google.com/iam/docs/best-practices-for-managing-service-account-keys
• Creating short-lived service account credentials: https://cloud.google.com/iam/docs/creating-short-lived-service-account-credentials
• Creating service accounts: https://cloudone.trendmicro.com/docs/workload-security/gcp-account-create/
• Service accounts for instances: https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances