Description:
Hello,
In our organization, we have configured an Access Policy with a scope for a GCP folder.
Here are the details of our configuration:
1. Access Policy:
- Name: `accessPolicies/XXXXX`
- Scope: GCP Folder
2. **Access Level:**
- Name: `accessLevels/Access_Level_Restriction`
- Filter: Authorized public IPs
3. **VPC Service Perimeter in Dry Run mode:**
- Name: `servicePerimeters/vpc_perimeter`
- Resources to protect:
- Projects: All GCP projects in the GCP folder
- Networks: All VPCs of the protected GCP projects
- Restricted Services: All services
- VPC Accessible Services: N/A
- Access Levels: N/A
- Ingress Policy:
- From: Any Identity (Source: Access Level: `Access_Level_Restriction`)
- To: All projects, All services
- Egress Policy:
- From: Any Identity
- To: All projects, All services
We have enabled the VPC SC / WIF feature for our organization.
Issue Encountered:
When connected via Workforce Identity Federation (WIF) or Cloud Identity, I can access Compute Engine to list instances in the GCP project `project_id`. However, when filtering logs with `log_id("cloudaudit.googleapis.com/policy") AND severity="error" AND protoPayload.metadata.dryRun="true"`, I receive VPC Service Controls errors in Dry Run mode stating:
(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: XXXXXXX
**Error Details:** ```json { "protoPayload": { "@type": "type.googleapis.com/google.cloud.audit.AuditLog", "status": { "code": 7, "message": "(Dry Run Mode) Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: XXXXXXX", "details": [ { "@type": "type.googleapis.com/google.rpc.PreconditionFailure", "violations": [ { "type": "VPC_SERVICE_CONTROLS", "description": "XXXXXXX" } ] } ] }, "authenticationInfo": { "principalEmail": "anonymized_email@domain.com" }, "requestMetadata": { "callerIp": "MY_IPV4", "requestAttributes": {}, "destinationAttributes": {} }, "serviceName": "compute.googleapis.com", "methodName": "compute.beta.ProjectsService.Get", "resourceName": "projects/XXXXXXXXX", "metadata": { "deviceState": "Unknown", "ingressViolations": [ { "servicePerimeter": "accessPolicies/XXXXX/servicePerimeters/vpc_perimeter", "targetResource": "projects/XXXXXXXXX" } ], "intermediateServices": [ "cloudclient-pa.googleapis.com" ], "securityPolicyInfo": { "organizationId": "XXXXXXXXX", "servicePerimeterName": "accessPolicies/XXXXX/servicePerimeters/vpc_perimeter" }, "vpcServiceControlsUniqueId": "XXXXXXX", "@type": "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata", "dryRun": true, "resourceNames": [ "project_id" ], "violationReason": "NO_MATCHING_ACCESS_LEVEL" } }, "insertId": "XXXXXXXXX", "resource": { "type": "audited_resource", "labels": { "method": "compute.beta.ProjectsService.Get", "service": "compute.googleapis.com", "project_id": "project_id" } |
Questions:
Thank you for your help!
Solved! Go to Solution.
Hello,
Here's how we resolved the issue :
Explicitly Add Access Level in Service Perimeter:
Modify VPC Accessible Services and Restricted Services:
Ensure Organization-Level Access Policy:
Update Access Level in the Service Perimeter:
Add Compute Engine API to VPC Accessible Services:
Create Organization-Level Access Policy:
After making these changes, you can verify the configuration and test again:
Check Access Level Association:
Test Access:
By explicitly adding the access level in the VPC Service Perimeter and ensuring the correct services are listed in the VPC Accessible Services, you should resolve the issue of unexpected VPC Service Controls errors. Additionally, creating an organization-level access policy without a specific scope can help mitigate unexpected issues with scoped policies.
Hello,
Here's how we resolved the issue :
Explicitly Add Access Level in Service Perimeter:
Modify VPC Accessible Services and Restricted Services:
Ensure Organization-Level Access Policy:
Update Access Level in the Service Perimeter:
Add Compute Engine API to VPC Accessible Services:
Create Organization-Level Access Policy:
After making these changes, you can verify the configuration and test again:
Check Access Level Association:
Test Access:
By explicitly adding the access level in the VPC Service Perimeter and ensuring the correct services are listed in the VPC Accessible Services, you should resolve the issue of unexpected VPC Service Controls errors. Additionally, creating an organization-level access policy without a specific scope can help mitigate unexpected issues with scoped policies.