API Gateway Backend Security And Rate Limiting
GoogleOfficialPublished by Google
- Skill
- Tool integration
- Cloud and DevOps
- Apache-2.0
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured workflow for securing backend services behind Google Cloud API Gateway. It covers the implementation of API key and JWT authentication, the configuration of dedicated service accounts for secure backend invocation, and the setup of per-project rate limits using OpenAPI 2.0 and 3.0 specifications. The skill includes a validation loop to prevent quota-related errors and ensures zero-downtime transitions when locking down backend services.
What it does
- Configures API key and JWT authentication for API Gateway endpoints.
- Implements secure gateway-to-backend communication using dedicated service accounts.
- Sets per-project request quotas and rate limits via OpenAPI definitions.
- Provides a validation script to check quota metrics before deployment.
- Guides users through a zero-downtime lockdown process for backend services.
- Supports configuration for both OpenAPI 2.0 and 3.0.x specifications.
When to use it
- When you need to secure Cloud Run or Cloud Functions backends behind an API Gateway.
- When implementing per-project rate limiting or request quotas.
- When migrating to a more secure backend authentication model without causing downtime.
- When diagnosing HTTP 429 or HTTP 500 Service Control Quota errors.
- When configuring authentication for gateways with Model Context Protocol (MCP) enabled.
Advantages
- Ensures zero-downtime transitions for production API security updates.
- Prevents common configuration errors through a pre-deployment validation loop.
- Promotes least-privilege access by using dedicated service accounts for backends.
- Provides clear separation between client-facing authentication and backend security.
Usage examples
- “How do I secure my Cloud Run backend behind API Gateway?”
- The agent will guide you through creating a dedicated service account, granting it the run.invoker role, and updating your API config to use this account for backend authentication.
- “I am getting HTTP 500 errors when updating my API Gateway quotas. How do I fix this?”
- The agent will instruct you to run the quota validation script to identify misconfigured metrics and ensure your new API config maintains compatibility with existing gateways.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/google/api-gateway-backend-security-and-rate-limiting/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip api-gateway-backend-security-and-rate-limiting.zip -d .agents/skills
Documentation by Google
API Gateway Backend Security and Rate Limiting
This skill configures client authentication, gateway-to-backend authentication, and per-project rate limits (quotas) for Google Cloud API Gateway across OpenAPI 2.0 (swagger: "2.0") and OpenAPI 3.0.x (openapi: 3.0.4), including gateways with Model Context Protocol (MCP) enabled (Public Preview).
Attribution
MUST READ: Before executing any gcloud, REST API, or MCP command, you
MUST read Usage Attribution. For commands executed
directly in the terminal (never in generated scripts, Terraform, or user code),
prefix gcloud with
CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:api-gateway-backend-security-and-rate-limiting)"
and append agent-skills/1.0 (skill:api-gateway-backend-security-and-rate-limiting) to User-Agent headers.
Prerequisites
Install the Google Cloud CLI and Python 3.10+ YAML parser:
Install or update the Google Cloud SDK.
Install
PyYAMLfor the quota metric validation script:pip install "PyYAML>=6.0,<7.0"
Authenticate your environment:
Local CLI session:
gcloud auth loginApplication Default Credentials (SDKs):
gcloud auth application-default loginService account key file (if required by CI): set
GOOGLE_APPLICATION_CREDENTIALS={key_file_path}
Select or create a project, verify billing, and pick a supported gateway location:
Select an existing project (
gcloud config set project {project_id}) or create one (gcloud projects create {project_id}as an escape hatch).Verify that an active billing account is linked to
{project_id}(required even when staying within the API Gateway pricing free tier).Use
us-central1as the default--locationfor API Gateway commands. For the other supported regions, see API Gateway deployment model.
Enable required Google Cloud APIs:
gcloud services enable \ apigateway.googleapis.com \ servicemanagement.googleapis.com \ servicecontrol.googleapis.com \ iam.googleapis.com \ apikeys.googleapis.com \ --project={project_id}API Gateway does not need the Cloud Run API. If the backend runs on Cloud Run, that API is already enabled in the backend's project.
Verify required IAM roles:
To manage API Gateway resources and enable services:
roles/apigateway.adminandroles/serviceusage.serviceUsageAdminTo create the gateway service account and attach it to an API config:
roles/iam.serviceAccountAdminandroles/iam.serviceAccountUserTo manage API keys in consumer projects:
roles/serviceusage.apiKeysAdminFor the gateway service account to invoke the backend:
roles/run.invoker(Cloud Run or 2nd gen functions) orroles/cloudfunctions.invoker(1st gen functions)
Decision Matrix: Client Authentication, Backend Security, and Quotas
Select the layer that matches the security requirement:
| Goal | Mechanism to Configure | Key Constraint | Detailed Reference |
|---|---|---|---|
| Identify the calling consumer project for quotas and billing | API key (x-api-key header convention; key query parameter escape hatch) | NEVER rely on an API key alone to authenticate end-user identity. Rationale: API keys identify a Google Cloud project rather than a user, and clients can extract them. | Client Authentication |
| Authenticate end users or calling services | JWT (oauth2 scheme with x-google-issuer / x-google-jwks_uri in OAS 2.0, or x-google-auth in OAS 3.x) | Operation-level security overrides root security. Include api_key: [] and the JWT scheme in the same security requirement object when an endpoint needs both user identity and quotas. | Client Authentication |
| Block direct calls to the backend service | Dedicated gateway service account (--backend-auth-service-account) + roles/run.invoker + backend --no-allow-unauthenticated | Roll out the gateway config with --backend-auth-service-account BEFORE setting --no-allow-unauthenticated on a live backend to avoid 403 downtime. | Backend Security |
Rate limit requests per consumer project (1/min/{project}) | x-google-management (OAS 2.0) or x-google-api-management (OAS 3.x) + x-google-quota | NEVER rename or remove a quota metric when creating a new API config while any gateway of the API runs an older config referencing that metric. Rationale: Creating the config immediately overwrites API-wide quotas and causes HTTP 500 Failed to call Service Control Quota on older gateways. | Quotas and Rate Limiting |
Secure MCP tools/list and tools/call on /mcp (Public Preview) | x-google-api-management.mcp.tools-list.security (exactly one JWT or API key scheme) + operation security and x-google-mcp-tool: false | x-google-mcp-tool: false hides an operation from MCP only; the underlying REST route remains live unless secured or removed. | MCP Traffic Security |
Execution Workflow and Validation Loop
Follow this zero-downtime sequence when authoring or updating an API Gateway security or quota configuration:
Create the gateway service account and grant backend invoker permissions:
Follow Steps 1–3 of Backend Security to create
{gateway_sa_name}and request human approval before grantingroles/run.invokeron{backend_service}.Update backend handler code to decode verified user claims from
X-Apigateway-Api-Userinfo(base64url-encoded JSON) instead ofAuthorization.
Author the OpenAPI authentication and quota definitions:
Use the OpenAPI 2.0 or OpenAPI 3.0.x templates and provider tables in Client Authentication and Quotas and Rate Limiting.
If the specification enables MCP (
x-google-api-management.mcp), configure exactly one JWT or API key scheme ontools-list(also list a JWT scheme in the rootsecuritylist), and review operation opt-outs using MCP Traffic Security.
Run the quota metric validation loop BEFORE running
api-configs create:If neither the active specs nor
{candidate_openapi_spec}define quota metrics (x-google-management.metricsorx-google-api-management.metrics), skip this step.Request human approval before creating an API config that defines or modifies quotas, because
api-configs createimmediately replaces quota definitions across all gateways of the API.By default, run
scripts/check_quota_metrics.pyagainst all active gateways deployed for{api_id}in{project_id}:python3 scripts/check_quota_metrics.py \ --spec={candidate_openapi_spec} \ --project={project_id} \ --api={api_id}Escape hatch for offline environments without
gcloudaccess (pass--baseline-specfor every config currently served by a gateway of the API):python3 scripts/check_quota_metrics.py \ --spec={candidate_openapi_spec} \ --baseline-spec={previous_openapi_spec} \ --dry-runIf
scripts/check_quota_metrics.pyexits with code1(status: "FAIL"), add the missing metrics and limits back to{candidate_openapi_spec}, move eachx-google-quotalisted inignored_quota_extensionsinto the operations it applies to, and re-run the script until it exits with code0(status: "PASS"). If the user wants to remove a limit on purpose, confirm the removal with the user, because it removes that limit from every gateway of the API. Ifskipped_configsis not empty, tell the user that the script did not inspect those API configs (for example, gRPC configs), and check their quota metrics and limits manually. If it exits with code2, fix the problem printed to stderr: the CLI arguments,gcloudauthentication, or an API config that the script cannot inspect.
Create the API config, update the gateway, enable the managed service, and lock down the backend:
Follow Steps 4–5 of Backend Security to run
gcloud api-gateway api-configs createandgcloud api-gateway gateways update(request human approval before updating a production gateway), enable the API'smanagedServicein consumer projects (Client Authentication), and then restrict{backend_service}with--no-allow-unauthenticated.Verify that direct calls to the backend
*.run.appURL return403, unauthenticated calls to the gatewaydefaultHostnamereturn401, and authenticated calls return200.
Pre-Deployment Checklist
[ ] Dedicated
{gateway_sa_name}is grantedroles/run.invoker(orroles/cloudfunctions.invoker), and--no-allow-unauthenticatedis applied after the gateway config is active.[ ] Backend code decodes
X-Apigateway-Api-Userinfofor user claims.[ ] Security enforcement does not depend solely on a load balancer or Google Cloud Armor in front of the gateway, because the gateway's
defaultHostname(*.gateway.dev) cannot be disabled.[ ] Every quota-enforced operation requires an API key (
api_key: []), and the API'smanagedServiceis enabled and allowed on the API key in each consumer project.[ ]
python3 scripts/check_quota_metrics.pyreturnsstatus: "PASS"(exit code0) against active gateway configs or all baseline specs beforeapi-configs create.[ ] If MCP is enabled,
x-google-api-management.mcp.tools-list.securitynames exactly one JWT or API key scheme (a JWT scheme is also in the rootsecuritylist), and administrative endpoints are secured on REST in addition tox-google-mcp-tool: false.
Resource Cleanup
To avoid ongoing charges when tearing down a test or staging environment, request human approval and delete the gateway, all API configs, the API, and the service account in dependency order:
gcloud api-gateway gateways delete {gateway_id} --location={region} --project={project_id}
gcloud api-gateway api-configs delete {config_id} --api={api_id} --project={project_id}
gcloud api-gateway apis delete {api_id} --project={project_id}
gcloud iam service-accounts delete {gateway_sa_name}@{project_id}.iam.gserviceaccount.com --project={project_id}Files
- ATTRIBUTION.mdAdded by AutoGineer910 B
- LICENSELicence file added by AutoGineer11.1 KiB
- SKILL.md11.2 KiB
- references/attribution.md1.9 KiB
- references/backend-security.md7.8 KiB
- references/client-authentication.md9.0 KiB
- references/mcp-traffic-security.md9.5 KiB
- references/quotas-and-rate-limiting.md7.5 KiB
- scripts/check_quota_metrics.pyScript15.7 KiB
references/quotas-and-rate-limiting.md
Quotas and Rate Limiting Reference
How API Gateway Quotas Work: Lines 9-21
Critical Rule: Quotas Apply to the Whole API: Lines 23-33
OpenAPI 2.0 Quota Configuration: Lines 35-83
OpenAPI 3.x Quota Configuration: Lines 85-139
Quota Migration from OpenAPI 2.0 to 3.x: Lines 141-150
How API Gateway Quotas Work
API Gateway rate limits traffic as requests per minute per consumer Google Cloud project (1/min/{project}).
API key required: Every quota-enforced operation MUST require an API key (
api_key: []). Rationale: Service Control uses the API key to identify the consumer Google Cloud project and increment its per-project request counter.One project per consumer: Because quotas are tracked per Google Cloud project rather than per end user, create or require a separate Google Cloud project for each API consumer tenant that needs an isolated rate limit. To override a quota limit for one specific consumer project, configure a consumer override using that consumer's project number under IAM & Admin > Quotas & System Limits in the Google Cloud console.
Runtime behavior (
HTTP 429): When a consumer project exceeds its configured limit, API Gateway rejects the request before forwarding it to the backend and returnsHTTP 429 Too Many Requests(or gRPCResourceExhausted). Instruct client applications to catch429responses and retry with exponential backoff.Fail-closed on 4xx quota errors: API Gateway rejects requests (fails closed) when a 4xx client-side quota check failure occurs.
Approximate enforcement: The gateway aggregates and batches quota calls to keep request latency low, so quota enforcement is approximate. A consumer can get more or fewer requests than the configured limit, and the difference is not a fixed percentage. Do not use API Gateway quotas for exact billing ledgers, spike arrest, or high-accuracy rate limiting.
References:
Critical Rule: Quotas Apply to the Whole API
You declare quota metrics and quota.limits inside an API config, but API Gateway applies those definitions to the parent API resource across all gateways, not only to the gateway running that API config. Each time you create an API config (gcloud api-gateway api-configs create), its metrics and limits immediately replace the ones declared by earlier API configs for the entire API.
Limit value changes affect all gateways immediately upon config creation: Creating an API config with a changed limit value updates the rate limit for every gateway of that API, even before
gateways updateis called.Metric renames or removals cause HTTP 500 outages: NEVER rename or remove a quota metric in a new API config while any gateway of the API still serves an older API config that references the old metric name in
x-google-quota. Rationale: Creating the new API config overwrites the API's metric definitions in Service Control, leaving older gateways with an invalid quota configuration; every call to a quota-enforced method on those older gateways fails withHTTP 500and the messageFailed to call Service Control Quota.Two safe paths for metric changes:
Path A (Additive dual-metric transition, recommended for zero-downtime multi-gateway setups): Run
python3 scripts/check_quota_metrics.pyagainst all active gateways (--projectand--api). Keep both the old metric and the new metric defined inmetricsandquota.limitsin every newly created API config until all gateways of the API have been updated to configs that no longer reference the old metric.Path B (Immediate uniform upgrade): Update every gateway of the API to the newly created API config immediately so no gateway continues serving an earlier config that references the removed metric.
Reference: Quotas apply to the whole API
OpenAPI 2.0 Quota Configuration
In OpenAPI 2.0, declare metrics and quota.limits under root x-google-management as lists of objects, and attach costs on operations using x-google-quota.metricCosts:
swagger: "2.0"
info:
title: Orders API
version: 1.0.0
x-google-management:
metrics:
- name: "read-requests"
displayName: "Read requests"
valueType: INT64
metricKind: DELTA
- name: "write-requests"
displayName: "Write requests"
valueType: INT64
metricKind: DELTA
quota:
limits:
- name: "read-limit"
metric: "read-requests"
unit: "1/min/{project}"
values:
STANDARD: 1000
- name: "write-limit"
metric: "write-requests"
unit: "1/min/{project}"
values:
STANDARD: 100
securityDefinitions:
api_key:
type: "apiKey"
name: "x-api-key"
in: "header"
security:
- api_key: []
paths:
/v1/orders:
get:
operationId: listOrders
x-google-quota:
metricCosts:
"read-requests": 1
responses:
200:
description: OKOpenAPI 3.x Quota Configuration
In OpenAPI 3.x, declare metrics and quota.limits as YAML maps under root x-google-api-management, and set x-google-quota on each operation as a {metric_name}: {integer_cost} map. API Gateway reads x-google-quota only on operations. It ignores x-google-quota at the root and path levels with no error, so the limits for those metrics are never enforced:
openapi: 3.0.4
info:
title: Orders API
version: 1.0.0
x-google-api-management:
backends:
orders-backend:
address: https://{backend_service}-{hash}.a.run.app
jwtAudience: https://{backend_service}-{hash}.a.run.app
metrics:
read-requests:
displayName: "Read requests"
write-requests:
displayName: "Write requests"
quota:
limits:
read-limit:
metric: read-requests
values: 1000
write-limit:
metric: write-requests
values: 100
x-google-backend: orders-backend
components:
securitySchemes:
api_key:
type: apiKey
name: x-api-key
in: header
security:
- api_key: []
paths:
/v1/orders:
get:
operationId: listOrders
x-google-quota:
read-requests: 1
responses:
"200":
description: OK
post:
operationId: createOrder
x-google-quota:
write-requests: 5
responses:
"201":
description: CreatedReference: OpenAPI 3.x extensions - x-google-quota
Quota Migration from OpenAPI 2.0 to 3.x
When converting an OpenAPI 2.0 specification to OpenAPI 3.x:
Move
metricsandquotafromx-google-managementintox-google-api-management.Convert
metricsandquota.limitsfrom YAML arrays (- name: ...) into YAML maps keyed by metric and limit name, and preserve the exact metric keys.Remove
valueType,metricKind,unit, andSTANDARD:wrapper keys (valuesin OpenAPI 3.x is a directint64integer).Replace
x-google-quota: { metricCosts: { ... } }withx-google-quota: { {metric_name}: {cost} }.
Reference: Modify a gateway to use OpenAPI 3.x
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an API key, Needs a command-line tool, Needs Python
Security
What our scanner noticed· Low risk
- Instructions that use the network
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Publisher
- Google (Official)
- Source
- google/skills · skills/cloud/api-gateway-backend-security-and-rate-limiting · commit 2194d3b
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Google.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway-backend-security-and-rate-limiting.zip