Generated banner for API Gateway Backend Security And Rate Limiting
Generated logo for API Gateway Backend Security And Rate Limiting

API Gateway Backend Security And Rate Limiting

GoogleOfficialPublished by Google

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Secures and rate limits backend services behind Google Cloud API Gateway across OpenAPI 2.0 and OpenAPI 3.0.x API configurations, including MCP-enabled gateways. Use when configuring API key or JWT authentication, locking down Cloud Run or Cloud Run functions backends with a gateway service account, reading authenticated claims from X-Apigateway-Api-Userinfo, setting per-project request quotas, or diagnosing HTTP 429 and HTTP 500 Service Control Quota errors. Do not use for Apigee, GKE Gateway API, Cloud Load Balancing custom domain setup, or LLM model routing.
— the description by Google

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/google/api-gateway-backend-security-and-rate-limiting/download
  2. Unzip 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

  1. Install the Google Cloud CLI and Python 3.10+ YAML parser:

    • Install or update the Google Cloud SDK.

    • Install PyYAML for the quota metric validation script:

      pip install "PyYAML>=6.0,<7.0"
  2. Authenticate your environment:

    • Local CLI session: gcloud auth login

    • Application Default Credentials (SDKs): gcloud auth application-default login

    • Service account key file (if required by CI): set GOOGLE_APPLICATION_CREDENTIALS={key_file_path}

  3. 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-central1 as the default --location for API Gateway commands. For the other supported regions, see API Gateway deployment model.

  4. 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.

  5. Verify required IAM roles:

    • To manage API Gateway resources and enable services: roles/apigateway.admin and roles/serviceusage.serviceUsageAdmin

    • To create the gateway service account and attach it to an API config: roles/iam.serviceAccountAdmin and roles/iam.serviceAccountUser

    • To manage API keys in consumer projects: roles/serviceusage.apiKeysAdmin

    • For the gateway service account to invoke the backend: roles/run.invoker (Cloud Run or 2nd gen functions) or roles/cloudfunctions.invoker (1st gen functions)

Decision Matrix: Client Authentication, Backend Security, and Quotas

Select the layer that matches the security requirement:

GoalMechanism to ConfigureKey ConstraintDetailed Reference
Identify the calling consumer project for quotas and billingAPI 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 servicesJWT (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 serviceDedicated gateway service account (--backend-auth-service-account) + roles/run.invoker + backend --no-allow-unauthenticatedRoll 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-quotaNEVER 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: falsex-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:

  1. 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 granting roles/run.invoker on {backend_service}.

    • Update backend handler code to decode verified user claims from X-Apigateway-Api-Userinfo (base64url-encoded JSON) instead of Authorization.

  2. 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 on tools-list (also list a JWT scheme in the root security list), and review operation opt-outs using MCP Traffic Security.

  3. 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.metrics or x-google-api-management.metrics), skip this step.

    • Request human approval before creating an API config that defines or modifies quotas, because api-configs create immediately replaces quota definitions across all gateways of the API.

    • By default, run scripts/check_quota_metrics.py against 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 gcloud access (pass --baseline-spec for 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-run
    • If scripts/check_quota_metrics.py exits with code 1 (status: "FAIL"), add the missing metrics and limits back to {candidate_openapi_spec}, move each x-google-quota listed in ignored_quota_extensions into the operations it applies to, and re-run the script until it exits with code 0 (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. If skipped_configs is 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 code 2, fix the problem printed to stderr: the CLI arguments, gcloud authentication, or an API config that the script cannot inspect.

  4. 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 create and gcloud api-gateway gateways update (request human approval before updating a production gateway), enable the API's managedService in consumer projects (Client Authentication), and then restrict {backend_service} with --no-allow-unauthenticated.

    • Verify that direct calls to the backend *.run.app URL return 403, unauthenticated calls to the gateway defaultHostname return 401, and authenticated calls return 200.

Pre-Deployment Checklist

  • [ ] Dedicated {gateway_sa_name} is granted roles/run.invoker (or roles/cloudfunctions.invoker), and --no-allow-unauthenticated is applied after the gateway config is active.

  • [ ] Backend code decodes X-Apigateway-Api-Userinfo for 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's managedService is enabled and allowed on the API key in each consumer project.

  • [ ] python3 scripts/check_quota_metrics.py returns status: "PASS" (exit code 0) against active gateway configs or all baseline specs before api-configs create.

  • [ ] If MCP is enabled, x-google-api-management.mcp.tools-list.security names exactly one JWT or API key scheme (a JWT scheme is also in the root security list), and administrative endpoints are secured on REST in addition to x-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

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 returns HTTP 429 Too Many Requests (or gRPC ResourceExhausted). Instruct client applications to catch 429 responses 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.

  1. 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 update is called.

  2. 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 with HTTP 500 and the message Failed to call Service Control Quota.

  3. 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.py against all active gateways (--project and --api). Keep both the old metric and the new metric defined in metrics and quota.limits in 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: OK

OpenAPI 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: Created

Reference: 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:

  1. Move metrics and quota from x-google-management into x-google-api-management.

  2. Convert metrics and quota.limits from YAML arrays (- name: ...) into YAML maps keyed by metric and limit name, and preserve the exact metric keys.

  3. Remove valueType, metricKind, unit, and STANDARD: wrapper keys (values in OpenAPI 3.x is a direct int64 integer).

  4. Replace x-google-quota: { metricCosts: { ... } } with x-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
Google
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