How to Detect Transitive Access to Sensitive Resources in Google Cloud

Read full article here: https://www.p0.dev/blog/transitive-access-gcp/?utm_source=nhimg

Uncovering Hidden Permissions Paths in Complex IAM Configurations

When securing access to sensitive resources in Google Cloud Platform (GCP), most practitioners start with the IAM permissions page in the Cloud Console. This view lists all principals with direct or inherited access to a resource—but it misses a critical exposure path: transitive access via service accounts.

Understanding Transitive Access

In Google Cloud, service accounts can act as principals, much like users or groups. Workloads authenticated as a service account inherit all permissions assigned to that account. However, if a human user has the ability to impersonate or authenticate as a service account, they effectively gain the same access as that account—introducing a transitive, often invisible, access path.

Permissions that enable this include:

• iam.serviceAccounts.actAs
• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.getOpenIdToken
• iam.serviceAccounts.implicitDelegation
• iam.serviceAccounts.setIamPolicy
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt

These permissions are commonly present in broad roles such as roles/editor, roles/owner, or roles/iam.serviceAccountUser, which can unintentionally grant indirect access to sensitive assets.

Detecting Transitive Access

Google Policy Analyzer can help visualize these hidden access paths. By using the analyzeIamPolicy method in the Cloud Asset API with analyzeServiceAccountImpersonation enabled, you can identify users who can indirectly access a resource through a service account.

A simplified example query for a Cloud Storage bucket:

{

  "scope": "organizations/123",

  "analysisQuery.resourceSelector.fullResourceName": "//storage.googleapis.com/test",

  "analysisQuery.options.analyzeServiceAccountImpersonation": true

}

However, note that the Policy Analyzer does not include the iam.serviceAccounts.setIamPolicy permission, which can allow privilege escalation. To cover this case, additional queries must be run per service account.

Alternative Detection Methods

With Google’s planned restriction of the Policy Analyzer API to Security Command Center customers, organizations may need to rely on alternative detection methods using Cloud Asset Inventory APIs:

1. Identify Service Accounts with Access:
   Use searchAllIamPolicies to find service accounts with permissions on the target resource or its parent hierarchy (projects, folders, or organization).
2. Trace Who Can Act As Those Accounts:
   Query for principals with impersonation permissions on those service accounts to reveal transitive access relationships.
3. Chain Analysis:
   Recurse through service account relationships—since one service account may be able to impersonate another, creating multi-hop access chains.

Best Practices for Service Account Management

• Avoid Service Account Keys: Keys can enable direct impersonation, bypassing IAM entirely. Use workload identity federation instead.
• Apply Least Privilege: Regularly review IAM policies to eliminate broad roles or unnecessary impersonation rights.
• Automate Access Reviews: Integrate policy analysis into CI/CD pipelines or cloud posture management tools.
• Monitor Changes Continuously: Use logs and security monitoring to detect new impersonation permissions or service account role changes.

Bottom Line

Transitive access is one of the most overlooked risks in Google Cloud IAM. Detecting and remediating these hidden access paths requires a combination of automated analysis and disciplined service account hygiene. By proactively uncovering indirect permissions, security teams can close critical gaps and strengthen the foundation of their cloud access governance.