gcp-key-restrictionslisted

# GCP Key Restrictions (APPLY) ## Overview For each API key flagged `CRITICAL` (unrestricted) by `gcp-credentials-audit`, queries the last 30 days of Cloud Monitoring `request_count` filtered by that key's `credential_id`, and — if the usage signal is unambiguous — restricts the key to exactly those APIs via `gcloud services api-keys update`. Keys with no usage signal, signals spanning >5 APIs, or that are <7 days old are demoted to "flag for review" rather than auto-restricted. ## When to Use - Triggered by `gcp-ironclad` as Phase 3b, after `gcp-spend-guardrails`. - Or standalone when you have a known list of unrestricted keys to lock down. ## Inputs - `SESSION_DIR` (must contain a fresh `audit.json` with `riskClass = "CRITICAL"` entries). - `DRY_RUN` env var (default `0`). - `MAX_INFERRED_APIS` env var (default `5` — keys with usage across more APIs are flagged, not auto-restricted). - `LOOKBACK_DAYS` env var (default `30`). ## Outputs Writes `${SESSION_DIR}/key-restrictions.json` matching `output.schema.json`. ## Execution ### Step A: Load candidate keys ```bash jq -r '.credentials[] | select(.type == "api_key" and .riskClass == "CRITICAL") | "\(.project)\t\(.uid)\t\(.displayName)\t\(.createTime)"' \ "${SESSION_DIR}/audit.json" > "${SESSION_DIR}/restriction-candidates.tsv" wc -l "${SESSION_DIR}/restriction-candidates.tsv" ``` ### Step B: For each candidate, query usage For each line `(project, uid, displayName, createTime)`: 1. If `createTime` is within the