glpi-neural-brain/data/research-evidence/b0ca4cf80a28cb8563f343c7.json

{
  "schema_version": 1,
  "saved_at": "2026-08-07T05:24:11.1497814Z",
  "content_sha256": "a8eb689651b1e2fe086f3f0287b304354e6c874db4d4c06e8a95974736d709f6",
  "result": {
    "title": "How to Configure VPC Service Controls for Google Cloud Storage",
    "url": "https://oneuptime.com/blog/post/2026-02-17-how-to-configure-vpc-service-controls-for-google-cloud-storage/view",
    "snippet": "A step-by-step guide to configuring VPC Service Controls for Google Cloud Storage to prevent data exfiltration and enforce network-level security boundaries.",
    "content": "IAM controls who can access your Cloud Storage data. VPC Service Controls add another layer by controlling where requests can come from and where data can flow. Even if someone has the right IAM permissions, VPC Service Controls can block their access if the request does not originate from an approved network or project. This is your defense against data exfiltration - preventing authorized users from copying data to unauthorized destinations.\n\nThis guide covers how to set up VPC Service Controls for Cloud Storage, from creating service perimeters to configuring access levels and handling common scenarios.\n\nWhat VPC Service Controls Do\n\nVPC Service Controls create a security perimeter around GCP services. For Cloud Storage, this means:\n\nRequests from outside the perimeter are blocked, even with valid IAM credentials\n\nData cannot be copied to buckets outside the perimeter\n\nAPI calls must originate from approved networks, IP ranges, or projects\n\nYou get protection against both external threats and insider data exfiltration\n\ngraph TD\nsubgraph \"VPC Service Perimeter\"\nA[Cloud Storage Bucket]\nB[Compute Engine VMs]\nC[Cloud Functions]\nA \u003c--\u003e B\nA \u003c--\u003e C\nend\n\nD[Authorized Network] --\u003e|Allowed| A\nE[Unauthorized Network] --\u003e|Blocked| A\nF[External Bucket] --\u003e|Copy blocked| A\n\nPrerequisites\n\nBefore setting up VPC Service Controls:\n\nYou need an organization - VPC Service Controls require a GCP organization\n\nYou need the Access Context Manager Admin role\n\nYou need to enable the Access Context Manager API\n\n# Enable the Access Context Manager API\n\ngcloud services enable accesscontextmanager.googleapis.com\n\n# Verify your organization ID\ngcloud organizations list\n\nStep 1: Create an Access Policy\n\nAn access policy is the top-level container for your VPC Service Controls configuration. Most organizations have one policy:\n\n# Create an access policy for your organization\ngcloud access-context-manager policies create \\\n--organization=ORGANIZATION_ID \\\n--title=\"My Organization Policy\"\n\nList existing policies:\n\n# List access policies\ngcloud access-context-manager policies list \\\n--organization=ORGANIZATION_ID\n\nStep 2: Create Access Levels\n\nAccess levels define the conditions under which requests are allowed through the perimeter. Common conditions include IP ranges, device attributes, and identity.\n\nIP-Based Access Level\n\nAllow access from your corporate network:\n\n# Create an access level that allows requests from specific IP ranges\ngcloud access-context-manager levels create corp-network \\\n--title=\"Corporate Network\" \\\n--basic-level-spec=corp-network.yaml \\\n--policy=POLICY_ID\n\nThe corp-network.yaml file:\n\n- ipSubnetworks:\n- 203.0.113.0/24\n- 198.51.100.0/24\n\nIdentity-Based Access Level\n\nAllow specific service accounts regardless of network:\n\n# identity-access.yaml\n- members:\n- serviceAccount: [email protected]\n- user: [email protected]\n\n# Create an identity-based access level\ngcloud access-context-manager levels create trusted-identities \\\n--title=\"Trusted Service Accounts\" \\\n--basic-level-spec=identity-access.yaml \\\n--policy=POLICY_ID\n\nCombined Access Level\n\nYou can combine conditions with AND/OR logic:\n\n# combined-access.yaml\n- ipSubnetworks:\n- 203.0.113.0/24\nmembers:\n- serviceAccount: [email protected]\n\nStep 3: Create a Service Perimeter\n\nThe service perimeter defines which projects and services are protected:\n\n# Create a service perimeter that protects Cloud Storage\ngcloud access-context-manager perimeters create my-storage-perimeter \\\n--title=\"Storage Security Perimeter\" \\\n--resources=\"projects/PROJECT_NUMBER\" \\\n--restricted-services=\"storage.googleapis.com\" \\\n--access-levels=\"accessPolicies/POLICY_ID/accessLevels/corp-network\" \\\n--policy=POLICY_ID\n\nProtecting Multiple Services\n\nIn practice, you usually protect multiple services together:\n\n# Create a perimeter protecting storage and related services\ngcloud access-context-manager perimeters create data-perimeter \\\n--title=\"Data Security Perimeter\" \\\n--resources=\"projects/PROJECT_NUMBER_1,projects/PROJECT_NUMBER_2\" \\\n--restricted-services=\"storage.googleapis.com,bigquery.googleapis.com,pubsub.googleapis.com\" \\\n--access-levels=\"accessPolicies/POLICY_ID/accessLevels/corp-network,accessPolicies/POLICY_ID/accessLevels/trusted-identities\" \\\n--policy=POLICY_ID\n\nIncluding Multiple Projects\n\n# Update a perimeter to include additional projects\ngcloud access-context-manager perimeters update my-storage-perimeter \\\n--add-resources=\"projects/ANOTHER_PROJECT_NUMBER\" \\\n--policy=POLICY_ID\n\nStep 4: Test with Dry Run Mode\n\nBefore enforcing a perimeter, use dry run mode to see what would be blocked. If you want to test before enforcing, create the perimeter in dry run mode instead of using the enforced command above:\n\n# Create a perimeter in dry run mode first\ngcloud access-context-manager perimeters dry-run create my-storage-perimeter \\\n--perimeter-title=\"Storage Security Perimeter (Dry Run)\" \\\n--perimeter-type=\"regular\" \\\n--perimeter-resources=\"projects/PROJECT_NUMBER\" \\\n--perimeter-restricted-services=\"storage.googleapis.com\" \\\n--perimeter-access-levels=\"accessPolicies/POLICY_ID/accessLevels/corp-network\" \\\n--policy=POLICY_ID\n\nMonitor the audit logs for dry run violations:\n\n# Query audit logs for VPC Service Controls dry run violations\ngcloud logging read \\\n'protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata\" AND protoPayload.metadata.dryRun=true' \\\n--limit=50 \\\n--format=\"table(timestamp, protoPayload.metadata.violationReason, protoPayload.methodName)\"\n\nOnce you are satisfied with the dry run results, enforce the perimeter:\n\n# Convert dry run perimeter to enforced\ngcloud access-context-manager perimeters dry-run enforce my-storage-perimeter \\\n--policy=POLICY_ID\n\nConfiguring Ingress Rules\n\nIngress rules define how external clients can access services inside the perimeter:\n\n# Create a perimeter with ingress rules\ngcloud access-context-manager perimeters update my-storage-perimeter \\\n--set-ingress-policies=ingress-policy.yaml \\\n--policy=POLICY_ID\n\nThe ingress policy YAML:\n\n- ingressFrom:\nidentityType: ANY_IDENTITY\nsources:\n- accessLevel: accessPolicies/POLICY_ID/accessLevels/corp-network\ningressTo:\noperations:\n- serviceName: storage.googleapis.com\nmethodSelectors:\n- method: google.storage.objects.get\n- method: google.storage.objects.list\nresources:\n- projects/PROJECT_NUMBER\n\nThis allows read-only access to Cloud Storage from the corporate network.\n\nConfiguring Egress Rules\n\nEgress rules control how data can flow out of the perimeter:\n\n# egress-policy.yaml\n- egressFrom:\nidentityType: ANY_IDENTITY\negressTo:\noperations:\n- serviceName: storage.googleapis.com\nmethodSelectors:\n- method: google.storage.objects.create\nresources:\n- projects/BACKUP_PROJECT_NUMBER\n\n# Apply egress rules\ngcloud access-context-manager perimeters update my-storage-perimeter \\\n--set-egress-policies=egress-policy.yaml \\\n--policy=POLICY_ID\n\nThis allows data to be copied only to a specific backup project's bucket.\n\nPerimeter Bridges\n\nWhen two perimeters need to share data, create a perimeter bridge:\n\n# Create a bridge between two perimeters\ngcloud access-context-manager perimeters create bridge-prod-analytics \\\n--title=\"Production to Analytics Bridge\" \\\n--perimeter-type=bridge \\\n--resources=\"projects/PROD_PROJECT_NUMBER,projects/ANALYTICS_PROJECT_NUMBER\" \\\n--policy=POLICY_ID\n\nTerraform Configuration\n\n# Access policy (usually already exists for the org)\nresource \"google_access_context_manager_access_policy\" \"policy\" {\nparent = \"organizations/${var.org_id}\"\ntitle = \"Organization Security Policy\"\n\n# Access level for corporate network\nresource \"google_access_context_manager_access_level\" \"corp_network\" {\nparent = \"accessPolicies/${google_access_context_manager_access_policy.policy.name}\"\nname = \"accessPolicies/${google_access_context_manager_access_policy.policy.name}/accessLevels/corp_network\"\ntitle = \"Corporate Network\"\n\nbasic {\nconditions {\nip_subnetworks = [\n\"203.0.113.0/24\",\n\"198.51.100.0/24\",\n\n# Service perimeter\nresource \"google_access_context_manager_service_perimeter\" \"storage_perimeter\" {\nparent = \"accessPolicies/${google_access_context_manager_access_policy.policy.name}\"\nname = \"accessPolicies/${google_access_context_manager_access_policy.policy.name}/servicePerimeters/storage_perimeter\"\ntitle = \"Storage Security Perimeter\"\n\nstatus {\nrestricted_services = [\"storage.googleapis.com\"]\n\nresources = [\n\"projects/${var.project_number}\",\n\naccess_levels = [\ngoogle_access_context_manager_access_level.corp_network.name,\n\ningress_policies {\ningress_from {\nsources {\naccess_level = google_access_context_manager_access_level.corp_network.name\nidentity_type = \"ANY_IDENTITY\"\ningress_to {\nresources = [\"*\"]\noperations {\nservice_name = \"storage.googleapis.com\"\nmethod_selectors {\nmethod = \"google.storage.objects.get\"\nmethod_selectors {\nmethod = \"google.storage.objects.list\"\n\nTroubleshooting\n\nChecking Why a Request Was Blocked\n\n# Query VPC Service Controls audit logs\ngcloud logging read \\\n'protoPayload.metadata.@type=\"type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata\"' \\\n--limit=20 \\\n--format=\"json(timestamp, protoPayload.metadata.violationReason, protoPayload.authenticationInfo.principalEmail, protoPayload.methodName)\"\n\nCommon violation reasons:\n\nRESOURCE_NOT_IN_SAME_SERVICE_PERIMETER - trying to copy data between perimeters\n\nNO_MATCHING_ACCESS_LEVEL - request does not meet access level conditions\n\nSERVICE_NOT_ALLOWED_FROM_VPC - the service is not allowed by the perimeter's VPC accessible services configuration\n\nCommon Issues\n\nCloud Console access blocked. To use the Cloud Console with resources inside a perimeter, create an access level that allows the user's IP range or user account.\n\nCI/CD pipeline failures. Add your CI/CD service accounts to an access level or ingress rule.\n\nCross-project access broken. Both projects must be in the same perimeter or connected via a bridge.\n\nVPC Service Controls are one of the strongest security mechanisms available on GCP. They turn your Cloud Storage buckets from \"accessible with the right credentials\" to \"accessible with the right credentials from the right network.\" For any organization handling sensitive data, they should be part of your security baseline.\n\nShare this article\n\nNawaz Dhandala\n\nAuthor\n\n@nawazdhandala • Feb 17, 2026 •\n\nNawaz is building OneUptime with a passion for engineering reliable systems and improving observability.\n\nGitHub\n\nTechnically validated\n\n· May 28, 2026\n\nView report\n\nHelp improve this post\n\nEvery OneUptime blog post is open source. Found a typo, an inaccuracy, or have a clearer way to explain something? Anyone can contribute — your edits make this post better for everyone who reads it next.\n\nEdit this post on GitHub\n\nContributing guidelines",
    "content_type": "text/html",
    "query": "Wie werden private Pfade in GCP Cloud Storage konfiguriert, um den Zugriff auf Speicherobjekte zu beschränken?",
    "language": "de-DE",
    "round": 3,
    "fetched": true,
    "relevant": true,
    "relevance": 0.89,
    "source_quality": "primary",
    "source_quality_score": 0.904,
    "actionable": true,
    "covered_gap_ids": [
      "GAP-004"
    ],
    "assessment_reason": "Die Quelle beschreibt detailliert, wie VPC Service Controls in GCP Cloud Storage konfiguriert werden, um den Zugriff auf Speicherobjekte zu beschränken. Sie liefert konkrete Befehle und Schritte zur Einrichtung von Access Policies, Access Levels und Service Perimeters. Dies entspricht der konkreten Schritt-für-Schritt-Anforderung der Suchanfrage."
  }
}