p24-infra Docs

secret-manager-request

3 min read

Secret Manager Request — How to Request Credential Operations

Who reads this: any agent in any repo that needs to add, rotate, delete, or retrieve a credential. You cannot handle SOPS files yourself. The secret-manager worker does it.

When to use this

SituationAction
Key exposed in chat / logsUrgency P0 — follow this playbook immediately
Key needs rotation (scheduled, preventive, service change)Create request issue, dispatch to queue
New credential needs to be added to the ecosystemCreate request issue, dispatch to queue
Old credential needs to be removed after decommissionCreate request issue, dispatch to queue
Not sure which SOPS file holds KEY_NAMECreate request issue — worker will answer in comment

Never: attempt to edit secrets/*.env.sops directly in a non-p24-infra session. Never: label a credential rotation as human-action without checking the tier first.

Step 1 — Tier check

Before creating the issue, determine if the operation can be autonomous:

  • Tier 1 / Tier 2 → dispatch to queue → worker rotates autonomously → callback comment
  • Tier 3 (UI-only, no API) → still dispatch to queue → worker will add human-action label and explain

Matrix: p24-infra/docs/playbooks/secret-rotation-access-matrix.md (Fetch via GH API if you don’t have a local p24-infra clone)

Step 2 — Create issue in your own repo

Create the issue in the repo you are currently working in (not in p24-infra).

Title format:

[SECRET-REQUEST] <OPERATION>: <KEY_NAME> — <reason>

Operations: ADD | ROTATE | DELETE | RETRIEVE

Body template:

## Secret Manager Request
 
**Operation:** ROTATE
**Key name(s):** KEY_NAME_1, KEY_NAME_2
**SOPS file (if known):** secrets/monitoring.env.sops
**Reason:** exposed in chat / scheduled / new service / decommission
**Urgency:** P0 within 1h / P1 by EOD / P2 routine
 
## Context
[Why this is needed. Never include key values — reference KEY_NAME only.]
 
## Expected outcome
After completion: new value deployed to [Vercel|vps-i1|bms-4|all],
old value revoked at provider.
 
## Requesting agent
Session: <current repo and branch>
Related issue: <link if any>

Labels to add: secret-request (or security if exposure)

Step 3 — Dispatch to the shared worker queue

# All projects share the same queue endpoint
curl -sf -X POST "$QUEUE_API_URL/queue-issue" \
  -H "Authorization: Bearer $QUEUE_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"issue_number\": ISSUE_NUM, \"repo\": \"radieu/YOUR_REPO\", \"job_type\": \"secret-manager\"}"

job_type: secret-manager routes to the secret-manager worker — not the regular dev worker.

Where to get QUEUE_API_KEY + QUEUE_API_URL by project:

Your repoKey location
et-operational-platformVercel env QUEUE_API_KEY + QUEUE_API_URL
brandpilotVercel env QUEUE_API_KEY + QUEUE_API_URL
Art-Agencyp24-infra/secrets/art-agency.env.sops
radekkonarski-personal-brandsecrets/radekkonarski-brand.env.sops in that repo
Any other repoOpen a p24-infra session: add QUEUE_API_KEY+QUEUE_API_URL to that project’s SOPS

Step 4 — Wait for callback

The worker picks up the issue within ~2 minutes, then:

  1. Reads the issue body and determines the operation
  2. Checks the tier (matrix)
  3. Tier 1/2: executes autonomously — SOPS update → GH Secret → server deploy → revoke old → rotation log
  4. Tier 3: adds human-action label + comments with instructions; human acts first, then worker distributes
  5. Comments on your issue with confirmation (or human-action instructions)

Continue other work while waiting — the comment on your issue is the signal.

What NOT to do

  • Do NOT expose key values in the issue body, chat, or any log
  • Do NOT label Tier 1 or Tier 2 rotations as human-action (check the matrix first)
  • Do NOT attempt SOPS operations in your own session
  • Do NOT pass secret values in the GH issue — KEY_NAME only
  • Do NOT create the issue in p24-infra — create it in your own repo

Graph View

Backlinks