Monitoring and Restricting Google Cloud APIs

Secure API traffic using perimeter and private access controls keeps calls to Google APIs on internal network paths and checks perimeter policy before data can leave. Private Google Access (opens in a new tab) provides private domains and IP ranges for reaching Google APIs from a Virtual Private Cloud (VPC) network without using the public internet. VPC Service Controls (opens in a new tab) builds a service perimeter around projects and supported services, so traffic flows from workloads inside the VPC to authorized Google APIs only when perimeter policy allows it.

1.1Private and Restricted Google API Domains

Private and restricted API domains are the two internal entry points for Google APIs, and both use IP addresses that are routable only from within Google Cloud. private.googleapis.com reaches a broad set of Google APIs and services, including services that do not support VPC Service Controls. restricted.googleapis.com uses 199.36.153.4/30 (199.36.153.4, 199.36.153.5, 199.36.153.6, 199.36.153.7) and 2600:2d00:0002:1000::/56 and reaches only APIs that support VPC Service Controls. The restricted domain blocks all other APIs and does not support Google Workspace APIs or Workspace web applications such as Gmail and Google Docs.

1.2Keeping API Traffic Inside the VPC with DNS Resolution

Keeping API traffic inside the VPC depends on DNS and routing that force Google API names to resolve to the private or restricted virtual IP addresses. A Cloud DNS response policy can override public DNS for names such as *.run.app and *.cloudfunctions.net and return restricted.googleapis.com A records with TTL 300 and the four addresses in 199.36.153.4/30. Once the policy is applied to the VPC network, requests that originate from within the VPC do not leave the VPC network. Those requests can then reach only Google APIs and services that enforce VPC Service Controls, so exfiltration through a non-compliant Google API is denied at both the network and perimeter layers.

1.3Requiring Serverless Workloads to Stay Inside the Perimeter

Perimeter-compliant Cloud Run services and jobs are Cloud Run workloads configured so all ingress and egress is evaluated by the VPC network and the service perimeter. Compliance requires three linked network controls:

• The service or job attaches to the VPC network with Direct VPC egress or a Serverless VPC Access connector.
• The service or job routes all outgoing traffic through the VPC network, not directly to the internet.
• The Cloud Run service allows traffic from internal sources only, because setting ingress to all disables VPC Service Controls enforcement.

New services created in projects inside the perimeter are automatically checked, but existing services continue to run and might not comply. Periodic audits using the Cloud Run Admin API to list services and flag improper ingress and egress settings are therefore required. Cloud Tasks (opens in a new tab) enforces the same boundary on dispatch: authenticated requests from a Cloud Tasks execution to compliant Cloud Run targets at run.app endpoints and compliant Cloud Run functions targets at functions.net endpoints are allowed. Non-compliant targets, targets at non-run.app or non-functions.net endpoints, and non-Cloud Run endpoints are blocked and fail with TARGET_TYPE_NOT_PERMITTED_FOR_VPC.

1.4Placing Interdependent Services in the Same Perimeter

Placing interdependent services in the same perimeter means adding every project and service that exchanges data to one VPC Service Controls boundary with explicit ingress and egress rules. Sensitive Data Protection is secured by adding the projects containing its resources to the perimeter and selecting Sensitive Data Protection by filtering for dlp. Any service that Sensitive Data Protection scans or writes to must also be secured within the same perimeter, otherwise the scan or write crosses the boundary. Pipeline runs powered by Dataform require Dataform and BigQuery to be restricted by the same perimeter, the dataform.restrictGitRemotes organization policy to be set, and user identities to be added to ingress rules when users authenticate with Google Account credentials for scheduled or manual runs. For Looker (Google Cloud core), connections to resources outside the perimeter require ingress and egress rules or Private Service Connect paths, a Shared VPC host project and Looker service project in different perimeters require a perimeter bridge for instance creation, and a customer-managed encryption key (CMEK) hosted in another project requires that Cloud KMS key hosting project to be added to the perimeter.

1.5Controlling Egress to External and Unsupported Services

Controlling egress to external and unsupported services addresses traffic that VPC Service Controls does not inherently govern. Third-party connectors interact with public endpoints outside Google's network for polling or webhooks, so VPC Service Controls alone does not block or secure that path. Granular VPC firewall rules must therefore restrict outbound connections to only the supplied fully qualified domain names (FQDNs). Similarly, if a default route is removed or only the restricted VIP is used, calls to non-compliant APIs such as email-sending APIs, Google Workspace, legacy bucket connectors, and the Google SecOps ImportPushLogs endpoint will fail or be unavailable. ImportPushLogs poses no exfiltration risk because it only pushes data into Google SecOps. After ingress and egress rules are configured, run the perimeter in dry-run mode for the first weeks, audit Cloud Audit Logs for violations from integrations such as Content Hub response actions, and use the violation analyzer to diagnose access denials before moving to enforced mode.

Audit, Monitor, and Detect Anomalous API Activity is the continuous practice of recording who invoked which Google Cloud API, correlating that control-plane activity with network telemetry, and alerting on patterns that indicate drift or exfiltration. Cloud Audit Logs (opens in a new tab) provides the who-did-what-where-and-when record for resource configuration. Virtual Private Cloud (VPC) Flow Logs and Firewall Rules Logging provide the network evidence for how traffic actually flowed. Log-based alerts and exports provide retention and automated detection, and audit logging should be enabled at the organization level through the same pipeline used to set up the organization so coverage cannot be bypassed at lower levels.

2.1Cloud Audit Logs for API Accountability

Cloud Audit Logs is the authoritative record of API interaction with Google Cloud resources, split into log types with different defaults and contents. Admin Activity audit logs record ADMIN WRITE operations that modify configuration or metadata, such as creating virtual machine (VM) instances, changing Identity and Access Management (IAM) permissions, and creating, modifying, and deleting organization policy constraints at the organization, folder, and project levels. Data Access audit logs record ADMIN READ operations that read metadata or configuration and DATA READ and DATA WRITE operations that read or write user-provided data, such as Identity-Aware Proxy (IAP) request evaluations.

Admin Activity coverage for privileged administrator activity is enabled by default and cannot be disabled by any principal. Because Admin Activity logs alone do not show read-heavy or data-plane abuse, Data Access logging must be enabled for sensitive APIs and both types must be reviewed together when analyzing invocation patterns.

2.2Network Telemetry with VPC Flow Logs and Firewall Rules Logging

Network telemetry from the VPC validates whether API activity and perimeter policy produced the intended network effect. VPC Flow Logs records a sample of network flows sent from and received by VM instances, including VMs used as Google Kubernetes Engine (GKE) nodes. The sample is typically 50% or less of VPC network flows, and enabling the feature on a subnet enables logging for all VMs in that subnet, with options to reduce volume. VPC Flow Logs should be enabled for each VPC subnet through the pipeline used to create the project.

Firewall Rules Logging audits, verifies, and analyzes the effect of individual firewall rules, which do not write logs by default. Logging shows whether a deny rule is functioning as intended and how many connections a given rule affects. Logging should be enabled for each firewall rule through the pipeline used to create the firewall. Together, VPC Flow Logs shows sampled flow volume between sources and destinations and Firewall Rules Logging attributes allow or deny decisions to a specific rule, so an anomalous API invocation can be traced to its network path across trust boundaries.

2.3Detecting Anomalous API Calls with Log-Based Alerts and Exports

Log-based detection in Cloud Logging turns audit entries into continuous monitoring for unauthorized API access attempts and privilege escalation. The flow runs from the API invocation to Cloud Audit Logs to a log-based alert, and then to notification or response procedures defined by enterprise access policies. Log-based alerts in Cloud Logging flag suspicious API requests such as unauthorized VM creations or IAM privilege escalations, and policies and procedures monitor those alerts and generate actions.

Review of IAP-secured access (opens in a new tab) in Logs Explorer follows an ordered workflow:

1. Open Logs Explorer: Go to Logs Explorer for the project.
2. Select resource: Choose the resource from the resource selector, with IAP-secured HTTPS resources under App Engine Application and Compute Engine Backend Service and IAP-secured SSH and TCP resources under Compute Engine VM instance.
3. Select log type: Choose data_access, which appears only after traffic occurred with Cloud Audit Logs for IAP enabled.
4. Expand entry: Expand the date and time of the access, where authorized access shows a blue i icon and unauthorized access shows an orange !! icon.
5. Inspect access levels: Expand protoPayload > requestMetadata > requestAttributes > auth > accessLevels to view the access levels the requester met.

All access levels the requester met are visible on the request, including levels not required for access. An unauthorized entry does not by itself show which levels were missing; the gap is determined by comparing the conditions on the resource to the access levels visible on the request. For long-term analysis of invocation patterns and allow-policy drift, apply continuous audit hygiene:

• Audit changes to allow policies from Cloud Audit Logs on a regular schedule.
• Audit access to service account keys from Cloud Audit Logs.
• Audit which principals hold the ability to change allow policies on projects.
• Export audit logs to Cloud Storage to retain logs for long periods.
• Manage access to logs with Logging roles and apply the same access policies to the log-routing destination as to Logs Explorer.

Exported storage preserves evidence after live logs age out, while equivalent access controls on the routing destination prevent bypass of Logs Explorer restrictions.

2.4Governing API Enablement and Audit Coverage

Governing API enablement prevents an attacker or misconfiguration from expanding the monitored surface by turning on new services. Enabling an API requires the serviceusage.services.enable permission, held through the Owner role (roles/owner) or the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). If the Restrict service usage organization policy constraint is in use, the target API must be included in the allowed list before enablement, such as including auditmanager.googleapis.com for Audit Manager.

Audit Manager (opens in a new tab) audits Google Cloud folders and projects against built-in or custom frameworks and illustrates hierarchical enablement. Enablement on a project enables the Audit Manager API for that project, while enablement on an organization runs gcloud beta services enable auditmanager.googleapis.com --organization=ORGANIZATION_ID. Enabling Audit Manager creates an Audit Manager service agent, with service-PROJECT_NUMBER@gcp-sa-audit-manager.iam.gserviceaccount.com for project-level enablement and service-org-ORGANIZATION_ID@gcp-sa-audit-manager.iam.gserviceaccount.com for organization-level enablement. After enablement, Audit Manager must be configured to support VPC Service Controls service perimeters so audit reads respect the same data-movement boundary that restricts configured APIs.

Enforce Service Restrictions and Organization Policies is the practice of using central guardrails to allow only approved Google Cloud APIs and to limit how credentials can invoke them. Organization Policy Service (opens in a new tab) controls which services can be enabled across the organization, folder, and project hierarchy, while API key restrictions control which application, network source, and API target can use a given key. Together they prevent unauthorized service enablement, reduce data exfiltration paths, and limit the blast radius of a compromised key.

3.1Restrict Service Usage Across the Resource Hierarchy

Organization restrictions are Organization Policy constraints, including Restrict Service Usage, that enforce an approved API allowlist across the resource hierarchy. A policy set at the organization node flows down to folders and projects, so a child project cannot enable a service that the parent has denied unless an explicit exception is granted. Requests governed by these controls originate from the Google Cloud console, APIs, and client libraries, and each request is evaluated against the allowed service list before the service can be used.

The organization restrictions feature supports a defined catalog of Service API names, such as bigquery.googleapis.com, storage.googleapis.com, compute.googleapis.com, iam.googleapis.com, secretmanager.googleapis.com, and apikeys.googleapis.com. Only services in this supported set can be governed by the restriction, and some services have limited support, such as Cloud Workstations and Container Registry requests that originate from the console. Complementary hygiene is to turn off unused Google services at admin.google.com > Apps > Additional Google Services by setting the value to False, which removes unneeded service surfaces from Cloud Identity environments.

3.2Apply Granular Restrictions to API Keys

API key restrictions are limits attached to an API Keys API (opens in a new tab) key, identified as asset apikeys.googleapis.com/Key, that define where and for what the key is valid. A fully restricted key binds three dimensions together: the application type that may present it, such as an HTTP referrer, Android app, or iOS app; the network source, such as IP address ranges; and the specific API targets, such as only BigQuery or only Cloud Storage. If any dimension does not match, the request from the client application to the Google API is denied, so a stolen key cannot be replayed from another app, network, or service.

Secure handling extends beyond the restriction settings to how the key is transmitted and stored. The key should be provided with the x-goog-api-key HTTP header or a client library instead of as a URL query parameter, because query parameters are retained in URLs and exposed to URL scans and logs. Keys must never be hardcoded in client-side code or committed to code repositories; the client should call the backend server, and the server adds the credential and issues the request to the Google API.

3.3Audit, Rotate, and Monitor Configured APIs

Continuous auditing of configured APIs verifies that restrictions remain in place and that only actively needed keys and services exist. Cloud Monitoring (opens in a new tab) tracks API usage volume and Cloud Logging records Admin Activity and Data Access events, so surge detection and log review can alert on unauthorized or anomalous invocations. Hierarchical log sinks and SIEM ingestion preserve this telemetry in immutable storage where users cannot bypass forwarding, supporting detection of abnormal API bursts and impossible-travel use by service accounts.

Key lifecycle controls keep the audited surface small and short-lived. Unneeded keys should be deleted to minimize attack surface, and each team member and each application should have its own isolated key for audit trail and containment. Keys should be rotated periodically by creating a new key, updating applications to the new key, and then deleting the old key on a 90-day cycle. Authorization keys should not be used in production; migration should move to Identity and Access Management (IAM) policies and short-lived service account credentials under least privilege, because API keys are bearer credentials sent with each request and they obscure the end-user identity in audit logs. The exception is Gemini API in production, which does not create resources in Google Cloud projects, but its bound service account must still hold no IAM roles.

Key Facts

• restricted.googleapis.com at 199.36.153.4/30 reaches only VPC Service Controls-supported APIs and blocks non-supported APIs, while private.googleapis.com reaches a broad set including non-supported APIs.
• Cloud Run services must attach to the VPC network, route all egress through the VPC, and allow only internal ingress to remain VPC Service Controls-compliant.
• Admin Activity audit logs are always written and cannot be disabled, while Data Access audit logs must be explicitly enabled.
• VPC Flow Logs records a sample of typically 50% or less of flows from VM instances, while Firewall Rules Logging attributes allow or deny decisions to a specific firewall rule.
• API keys must be sent in the x-goog-api-key header, restricted by application, IP, and API target, and rotated on a 90-day cycle.