Service Account with Administrative Privileges within Project Scope
- Orca Best Practices
About Google Cloud Service Accounts
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:
- User-managed service accounts: Created by Google Cloud users, via the Cloud Console, the IAM API, or the command-line tool, gcloud.
- Default service accounts: If you don’t specify a service account while using a Google Cloud service, a default service account is created for you.
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.
Cloud Risk Description
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.
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 “Service Accounts with Administrative Privileges within Project Scope” and will alert on this type of issue as shown in the screenshot above.
Recommended Mitigation Strategies
Apply least privilege principle
When defining access policies for service accounts, adhere to the principle of least privilege.
Disable IAM grants
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 credentials
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.
Limit account impersonation
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.