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:
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.
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.
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.
Whenever possible, avoid using default service accounts. Create a new service account instead.
If you are using the default compute engine service account, be sure to revoke its editor privileges.
Disable the “iam.automaticIamGrantsForDefaultServiceAccounts” boolean constraint. This will ensure that default SAs don’t automatically get editor privileges.
Always apply the principle of least privilege while defining policies for your service accounts.
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.