VM Instance Using the Default Service Account
- GCP CIS
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.
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.
Don’t allow users or applications to assume service accounts that have more privileges than the users or applications themselves.
Orca Security, the cloud security innovation leader, provides cloud-wide, workload-deep security and compliance for AWS, Azure, and GCP － without the gaps in coverage, alert fatigue, and operational costs of agents.