GCP IAM for AI Services

Advanced10 min readUpdated 2026-03-15

IAM exploitation patterns for GCP AI services: service account exploitation, Workload Identity abuse, VPC Service Controls for AI, and privilege escalation through Vertex AI permissions.

gcp iam service-accounts workload-identity vpc-service-controls privilege-escalation vertex-ai

GCP IAM for AI Services

GCP's IAM model for AI services revolves around service accounts, predefined roles, and the granular 權限 system. Unlike AWS where IAM policies are attached to principals and resources independently, GCP IAM binds roles (collections of 權限) to members (users, service accounts, groups) at various resource hierarchy levels (organization, folder, project, resource). For AI workloads, the service account is the critical identity -- every Vertex AI 訓練 job, prediction endpoint, notebook, and pipeline runs as a service account, and that service account's 權限 define the blast radius of any compromise.

Service Account 利用

Identifying AI Service Accounts

# List all service accounts
gcloud iam service-accounts list --project=<project>
 
# Find service accounts used by Vertex AI resources
# Check notebooks
gcloud workbench instances list --location=us-central1 \
  --format="table(name,serviceAccount)"
 
# Check endpoints
gcloud ai endpoints describe <id> --region=us-central1 \
  --format="json(deployedModels[].serviceAccount)"
 
# Check 訓練 jobs
gcloud ai custom-jobs describe <id> --region=us-central1 \
  --format="json(jobSpec.serviceAccount)"

Common Overprivilege Patterns

Pattern	Service Account	Permissions	Risk
Default SA everywhere	`PROJECT_NUM-compute@`	`roles/editor`	Total project compromise
AI admin SA	Custom SA with `roles/aiplatform.admin`	Full Vertex AI control	Model and data manipulation
Cross-service SA	SA with AI + storage + BigQuery roles	Multi-service access	Data exfiltration across services
Key file exposure	SA with downloaded key file	Whatever roles are bound	Credential theft for persistent access

Service Account Key 利用

Service account key files are JSON credentials that provide persistent, non-expiring access (until the key is deleted). They are the most common credential exposure in GCP environments:

# Check for user-managed keys (potential exposure)
gcloud iam service-accounts keys list \
  --iam-account=<sa-email> \
  --managed-by=user
 
# Common locations where SA keys are found:
# - Environment variables (GOOGLE_APPLICATION_CREDENTIALS)
# - Application configuration files
# - Git repositories (committed accidentally)
# - CI/CD pipeline configurations
# - Notebook files (.ipynb cells containing key JSON)
# - Docker images (baked into layers)

Service Account Impersonation Chains

GCP allows service account impersonation through the roles/iam.serviceAccountTokenCreator role. This creates chains where compromising one identity leads to assuming another:

# Check who can impersonate AI service accounts
gcloud iam service-accounts get-iam-policy <ai-sa-email> \
  --format="json(bindings)"
 
# Impersonate a service account
gcloud auth print-access-符元 --impersonate-service-account=<ai-sa-email>
 
# Use impersonation to access AI services
gcloud ai endpoints predict <endpoint-id> \
  --region=us-central1 \
  --impersonate-service-account=<ai-sa-email> \
  --json-request=request.json

Map the full impersonation graph to 識別 all paths to privileged AI service accounts.

Workload Identity

GKE and Vertex AI Integration

Organizations running models on GKE (Google Kubernetes Engine) use Workload Identity to provide GCP credentials to pods. When Vertex AI workloads run on GKE (e.g., Kubernetes-hosted endpoints, custom serving containers), Workload Identity bindings determine what GCP resources the pods can access.

# Check Workload Identity configuration on a GKE cluster
gcloud container clusters describe <cluster> --zone=<zone> \
  --format="json(workloadIdentityConfig)"
 
# List Kubernetes service accounts with GCP SA bindings
kubectl get serviceaccounts -A -o json | \
  python3 -c "
import sys, json
data = json.load(sys.stdin)
for item in data['items']:
    annotations = item.get('metadata', {}).get('annotations', {})
    gcp_sa = annotations.get('iam.gke.io/gcp-service-account', '')
    if gcp_sa:
        print(f\"{item['metadata']['namespace']}/{item['metadata']['name']} -> {gcp_sa}\")
"

Workload Identity Abuse

攻擊	Description	Impact
Pod escape to node SA	Escape pod to access node's service account	Node SA 權限 (often broader than pod SA)
Annotation manipulation	Modify KSA annotation to bind to a more privileged GCP SA	Escalate to higher-privileged GCP identity
Namespace privilege	Create pods in a namespace with privileged WI binding	Assume the namespace's GCP SA
Token theft	Steal the projected SA 符元 from the pod filesystem	Impersonate the pod's GCP identity

# From a compromised pod with Workload Identity
# Get GCP access 符元
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/符元"
 
# Check what identity we have
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"

VPC Service Controls for AI

How VPC SC Protects AI

VPC Service Controls create 安全 perimeters that restrict which identities and networks can access GCP services, including Vertex AI. A properly configured VPC SC perimeter prevents:

Data exfiltration from Vertex AI to external projects
Model artifact copying to 攻擊者-controlled GCS buckets
Cross-project access to 訓練資料
API calls from outside the defined perimeter

VPC SC 評估

# List VPC SC perimeters
gcloud access-context-manager perimeters list --policy=<policy-id>
 
# Describe a perimeter (reveals protected services and access levels)
gcloud access-context-manager perimeters describe <perimeter-name> \
  --policy=<policy-id>
 
# Check if aiplatform.googleapis.com is in the perimeter
gcloud access-context-manager perimeters describe <perimeter-name> \
  --policy=<policy-id> \
  --format="json(status.restrictedServices)"

VPC SC Bypass Techniques

Bypass	Description	先備知識
Ingress rule abuse	Overpermissive ingress rules allow external access	Ingress rules with broad identity or IP scopes
Egress rule abuse	Egress rules allowing data transfer to external projects	Egress rules not scoped to specific projects/services
Bridge perimeter	Perimeters bridged for legitimate cross-project access	Bridged perimeters include 攻擊者-accessible projects
Access level 利用	Access levels based on IP ranges or device trust	Compromised device or network position within allowed ranges
Service not in perimeter	AI-related services (e.g., Artifact Registry, BigQuery) not included in the perimeter	Exfiltrate data through unprotected services

Privilege Escalation Paths

Vertex AI-Specific Escalation

權限	Escalation Path	Target
`aiplatform.customJobs.create`	Create 訓練 job with privileged SA	SA 權限
`aiplatform.notebookRuntimeTemplates.create`	Create notebook with privileged SA	SA 權限 + interactive access
`aiplatform.endpoints.deploy`	Deploy model endpoint with privileged SA	SA 權限 through serving container
`aiplatform.pipelineJobs.create`	Create pipeline running as privileged SA	SA 權限對每個 pipeline step
`iam.serviceAccounts.actAs`	Impersonate AI service accounts directly	Direct SA access

Cross-Service Escalation

Vertex AI 權限 can enable access to other GCP services:

Vertex AI to GCS
A Vertex AI 訓練 job or notebook with storage.objects.list and storage.objects.get on a broad scope can access any GCS bucket the SA can reach. Use Vertex AI compute to enumerate and download data from storage.
Vertex AI to BigQuery
Training jobs and notebooks with BigQuery roles can query any dataset the SA has access to. 這是 a common path for 訓練資料 exfiltration.
Vertex AI to Secret Manager
AI service accounts with secretmanager.versions.access can retrieve secrets. Common in deployments where models need API keys for external services.
Vertex AI to other projects
Service accounts with cross-project roles or service account impersonation 權限 can pivot to other projects through Vertex AI compute.

IAM 評估 Checklist

Enumerate all AI service accounts and their role bindings
Check for default SA usage across all Vertex AI resources
識別 SA key files (especially in notebooks and Git repos)
Map impersonation chains from users/groups to AI service accounts
Verify VPC SC coverage for all AI-related services
Check Workload Identity bindings if GKE is used for model serving
測試 cross-project access through AI service account roles
Audit organization policies that restrict AI service usage

參考文獻

GCP IAM for Vertex AI -- Access control documentation
Workload Identity -- GKE identity federation
VPC Service Controls -- Supported services and configuration

GCP IAM for AI Services

Advanced10 min readUpdated 2026-03-15

IAM exploitation patterns for GCP AI services: service account exploitation, Workload Identity abuse, VPC Service Controls for AI, and privilege escalation through Vertex AI permissions.

gcp iam service-accounts workload-identity vpc-service-controls privilege-escalation vertex-ai

GCP IAM for AI Services

Service Account 利用

Identifying AI Service Accounts

# List all service accounts
gcloud iam service-accounts list --project=<project>
 
# Find service accounts used by Vertex AI resources
# Check notebooks
gcloud workbench instances list --location=us-central1 \
  --format="table(name,serviceAccount)"
 
# Check endpoints
gcloud ai endpoints describe <id> --region=us-central1 \
  --format="json(deployedModels[].serviceAccount)"
 
# Check 訓練 jobs
gcloud ai custom-jobs describe <id> --region=us-central1 \
  --format="json(jobSpec.serviceAccount)"

Common Overprivilege Patterns

Pattern	Service Account	Permissions	Risk
Default SA everywhere	`PROJECT_NUM-compute@`	`roles/editor`	Total project compromise
AI admin SA	Custom SA with `roles/aiplatform.admin`	Full Vertex AI control	Model and data manipulation
Cross-service SA	SA with AI + storage + BigQuery roles	Multi-service access	Data exfiltration across services
Key file exposure	SA with downloaded key file	Whatever roles are bound	Credential theft for persistent access

Service Account Key 利用

Service account key files are JSON credentials that provide persistent, non-expiring access (until the key is deleted). They are the most common credential exposure in GCP environments:

# Check for user-managed keys (potential exposure)
gcloud iam service-accounts keys list \
  --iam-account=<sa-email> \
  --managed-by=user
 
# Common locations where SA keys are found:
# - Environment variables (GOOGLE_APPLICATION_CREDENTIALS)
# - Application configuration files
# - Git repositories (committed accidentally)
# - CI/CD pipeline configurations
# - Notebook files (.ipynb cells containing key JSON)
# - Docker images (baked into layers)

Service Account Impersonation Chains

GCP allows service account impersonation through the roles/iam.serviceAccountTokenCreator role. This creates chains where compromising one identity leads to assuming another:

# Check who can impersonate AI service accounts
gcloud iam service-accounts get-iam-policy <ai-sa-email> \
  --format="json(bindings)"
 
# Impersonate a service account
gcloud auth print-access-符元 --impersonate-service-account=<ai-sa-email>
 
# Use impersonation to access AI services
gcloud ai endpoints predict <endpoint-id> \
  --region=us-central1 \
  --impersonate-service-account=<ai-sa-email> \
  --json-request=request.json

Map the full impersonation graph to 識別 all paths to privileged AI service accounts.

Workload Identity

GKE and Vertex AI Integration

# Check Workload Identity configuration on a GKE cluster
gcloud container clusters describe <cluster> --zone=<zone> \
  --format="json(workloadIdentityConfig)"
 
# List Kubernetes service accounts with GCP SA bindings
kubectl get serviceaccounts -A -o json | \
  python3 -c "
import sys, json
data = json.load(sys.stdin)
for item in data['items']:
    annotations = item.get('metadata', {}).get('annotations', {})
    gcp_sa = annotations.get('iam.gke.io/gcp-service-account', '')
    if gcp_sa:
        print(f\"{item['metadata']['namespace']}/{item['metadata']['name']} -> {gcp_sa}\")
"

Workload Identity Abuse

攻擊	Description	Impact
Pod escape to node SA	Escape pod to access node's service account	Node SA 權限 (often broader than pod SA)
Annotation manipulation	Modify KSA annotation to bind to a more privileged GCP SA	Escalate to higher-privileged GCP identity
Namespace privilege	Create pods in a namespace with privileged WI binding	Assume the namespace's GCP SA
Token theft	Steal the projected SA 符元 from the pod filesystem	Impersonate the pod's GCP identity

# From a compromised pod with Workload Identity
# Get GCP access 符元
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/符元"
 
# Check what identity we have
curl -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"

VPC Service Controls for AI

How VPC SC Protects AI

VPC Service Controls create 安全 perimeters that restrict which identities and networks can access GCP services, including Vertex AI. A properly configured VPC SC perimeter prevents:

Data exfiltration from Vertex AI to external projects
Model artifact copying to 攻擊者-controlled GCS buckets
Cross-project access to 訓練資料
API calls from outside the defined perimeter

VPC SC 評估

# List VPC SC perimeters
gcloud access-context-manager perimeters list --policy=<policy-id>
 
# Describe a perimeter (reveals protected services and access levels)
gcloud access-context-manager perimeters describe <perimeter-name> \
  --policy=<policy-id>
 
# Check if aiplatform.googleapis.com is in the perimeter
gcloud access-context-manager perimeters describe <perimeter-name> \
  --policy=<policy-id> \
  --format="json(status.restrictedServices)"

VPC SC Bypass Techniques

Bypass	Description	先備知識
Ingress rule abuse	Overpermissive ingress rules allow external access	Ingress rules with broad identity or IP scopes
Egress rule abuse	Egress rules allowing data transfer to external projects	Egress rules not scoped to specific projects/services
Bridge perimeter	Perimeters bridged for legitimate cross-project access	Bridged perimeters include 攻擊者-accessible projects
Access level 利用	Access levels based on IP ranges or device trust	Compromised device or network position within allowed ranges
Service not in perimeter	AI-related services (e.g., Artifact Registry, BigQuery) not included in the perimeter	Exfiltrate data through unprotected services

Privilege Escalation Paths

Vertex AI-Specific Escalation

權限	Escalation Path	Target
`aiplatform.customJobs.create`	Create 訓練 job with privileged SA	SA 權限
`aiplatform.notebookRuntimeTemplates.create`	Create notebook with privileged SA	SA 權限 + interactive access
`aiplatform.endpoints.deploy`	Deploy model endpoint with privileged SA	SA 權限 through serving container
`aiplatform.pipelineJobs.create`	Create pipeline running as privileged SA	SA 權限對每個 pipeline step
`iam.serviceAccounts.actAs`	Impersonate AI service accounts directly	Direct SA access

Cross-Service Escalation

Vertex AI 權限 can enable access to other GCP services:

Vertex AI to GCS
A Vertex AI 訓練 job or notebook with storage.objects.list and storage.objects.get on a broad scope can access any GCS bucket the SA can reach. Use Vertex AI compute to enumerate and download data from storage.
Vertex AI to BigQuery
Training jobs and notebooks with BigQuery roles can query any dataset the SA has access to. 這是 a common path for 訓練資料 exfiltration.
Vertex AI to Secret Manager
AI service accounts with secretmanager.versions.access can retrieve secrets. Common in deployments where models need API keys for external services.
Vertex AI to other projects
Service accounts with cross-project roles or service account impersonation 權限 can pivot to other projects through Vertex AI compute.

IAM 評估 Checklist

Enumerate all AI service accounts and their role bindings
Check for default SA usage across all Vertex AI resources
識別 SA key files (especially in notebooks and Git repos)
Map impersonation chains from users/groups to AI service accounts
Verify VPC SC coverage for all AI-related services
Check Workload Identity bindings if GKE is used for model serving
測試 cross-project access through AI service account roles
Audit organization policies that restrict AI service usage

參考文獻

GCP IAM for Vertex AI -- Access control documentation
Workload Identity -- GKE identity federation
VPC Service Controls -- Supported services and configuration

GCP IAM for AI Services

Vertex AI to GCS

Vertex AI to BigQuery

Vertex AI to Secret Manager

Vertex AI to other projects

Related articles

GCP IAM for AI Services

Vertex AI to GCS

Vertex AI to BigQuery

Vertex AI to Secret Manager

Vertex AI to other projects

Related articles