A GCP service account is a specialized account that virtual machines and applications use to authorize themselves while interacting with cloud APIs and services. A service account, in many ways, serves as the identity of an application/service. For example, you may assign a service account to a Kubernetes pod. This will enable all the processes inside the pod to make authorized API calls, using the service account as their identity.
There are two main types of service accounts:
The permissions attached to a service account determine exactly which resources the associated application can access and what operations it can perform. If administrative permissions (owner and editor roles) are granted to a user-managed service account, at the project level, they can create new projects or add/modify/delete resources. In the Google Cloud hierarchy, a project provides a way to group resources. For example, multiple buckets, app engines, and VMs may be assigned to a project. The principle of least privilege dictates that a service account should have the bare minimum of permissions required to perform necessary actions. Typically, this doesn’t and shouldn’t include administrative privileges.
User-managed service accounts can be used by applications/services to make authorized API calls. If these service accounts have administrative privileges at the project level, they can be used to make unauthorized changes, such as creating, editing, and delete projects, VMs, and other resources.
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 “Service Accounts with Administrative Privileges within Project Scope” and will alert on this type of issue as shown in the screenshot above.
Overly permissive access policies can lead to privilege abuse and/or misconfigurations, both of which can make your systems vulnerable to compromise. Here are a few real-life examples:
When defining access policies for service accounts, adhere to the principle of least privilege.
Disable automatic IAM grants for default service accounts. This will prevent default service accounts from automatically getting the Editor role upon creation.
Use short-lived service account credentials when granting access to external parties.
Don’t use service accounts to access personal user data without the user’s explicit consent.
Don’t allow users to impersonate service accounts that have more privileges than the users 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.