GCP IAM for AI Services
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 for AI Services
GCP's IAM model for AI services revolves around service accounts, predefined roles, and the granular permission system. Unlike AWS where IAM policies are attached to principals and resources independently, GCP IAM binds roles (collections of permissions) 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 training job, prediction endpoint, notebook, and pipeline runs as a service account, and that service account's permissions define the blast radius of any compromise.
Service Account Exploitation
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 training 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 Exploitation
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-token --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.jsonMap the full impersonation graph to identify 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
| Attack | Description | Impact |
|---|---|---|
| Pod escape to node SA | Escape pod to access node's service account | Node SA permissions (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 token from the pod filesystem | Impersonate the pod's GCP identity |
# From a compromised pod with Workload Identity
# Get GCP access token
curl -H "Metadata-Flavor: Google" \
"http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"
# 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 security 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 attacker-controlled GCS buckets
- Cross-project access to training data
- API calls from outside the defined perimeter
VPC SC Assessment
# 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 | Prerequisites |
|---|---|---|
| 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 attacker-accessible projects |
| Access level exploitation | 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
| Permission | Escalation Path | Target |
|---|---|---|
aiplatform.customJobs.create | Create training job with privileged SA | SA permissions |
aiplatform.notebookRuntimeTemplates.create | Create notebook with privileged SA | SA permissions + interactive access |
aiplatform.endpoints.deploy | Deploy model endpoint with privileged SA | SA permissions through serving container |
aiplatform.pipelineJobs.create | Create pipeline running as privileged SA | SA permissions for each pipeline step |
iam.serviceAccounts.actAs | Impersonate AI service accounts directly | Direct SA access |
Cross-Service Escalation
Vertex AI permissions can enable access to other GCP services:
Vertex AI to GCS
A Vertex AI training job or notebook with
storage.objects.listandstorage.objects.geton 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. This is a common path for training data exfiltration.
Vertex AI to Secret Manager
AI service accounts with
secretmanager.versions.accesscan 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 permissions can pivot to other projects through Vertex AI compute.
IAM Assessment Checklist
- Enumerate all AI service accounts and their role bindings
- Check for default SA usage across all Vertex AI resources
- Identify 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
- Test cross-project access through AI service account roles
- Audit organization policies that restrict AI service usage
Related Topics
- GCP AI Services Overview -- Service landscape and enumeration
- Vertex AI Attack Surface -- Exploitation using SA access
- AWS IAM for AI -- Comparison with AWS IAM patterns
- Multi-Cloud Comparison -- Cross-cloud IAM comparison
A Vertex AI Workbench notebook instance is configured with a custom service account that has roles/aiplatform.admin and roles/storage.objectAdmin. An attacker compromises the notebook through a malicious pip package. What is the attacker's blast radius?
An organization has VPC Service Controls protecting aiplatform.googleapis.com but NOT storage.googleapis.com. Why is this insufficient for protecting AI workloads?
References
- GCP IAM for Vertex AI -- Access control documentation
- Workload Identity -- GKE identity federation
- VPC Service Controls -- Supported services and configuration