Secrets and registry credentials

Secret material and its rotation, and the credentials the platform pulls container images with. No route on this page returns a secret value.

Every address below is served under the control plane’s base URL. Permission is the guard the route is registered with; who holds it is read from the control plane’s own grant, so it cannot drift from what the server does. A dash means the route carries no permission guard of its own — the access tier below the table is then the whole of what stands in front of it.

Generated from Route. Hand edits to this table are overwritten on the next build — change the Go doc comment, or the generator.

Route	Permission	Who holds it	Body
GET /api/v1/registry-credentials	config:read	developer, operator, readonly, support	—
POST /api/v1/registry-credentials	config:write	an administrator only, through the wildcard grant	—
DELETE /api/v1/registry-credentials/{name}	config:write	an administrator only, through the wildcard grant	—
GET /api/v1/registry-credentials/{name}	config:read	developer, operator, readonly, support	—
PUT /api/v1/registry-credentials/{name}	config:write	an administrator only, through the wildcard grant	—
POST /api/v1/registry-credentials/{name}/test	config:write	an administrator only, through the wildcard grant	—
GET /api/v1/secrets/resources	vault:read	developer	—
GET /api/v1/secrets/resources/{resource:.+}/consumers	vault:read	developer	—
GET /api/v1/secrets/{resource}	vault:read	developer	—
PUT /api/v1/secrets/{resource}	vault:manage	developer	—
GET /api/v1/secrets/{resource}/rotation	vault:read	developer	—
POST /api/v1/secrets/{resource}/rotation	vault:manage	developer	—
POST /api/v1/secrets/{resource}/rotation/retire	vault:manage	developer	—
POST /api/v1/secrets/{resource}/rotation/switch	vault:manage	developer	—

Who can reach these at all

authenticated — Behind authentication, cross-site-request-forgery validation and tenant extraction. Every call acts inside exactly one tenant.

Reachable only by an administrator

No role holds the permissions below explicitly. They are satisfied by the administrator’s wildcard grant and by nothing else, so an operator or a developer cannot call these routes however their tenant is configured. That is a role-model question rather than a documentation one; it is recorded here because a reader planning around it needs to know before they try.

• POST /api/v1/registry-credentials — needs config:write
• DELETE /api/v1/registry-credentials/{name} — needs config:write
• PUT /api/v1/registry-credentials/{name} — needs config:write
• POST /api/v1/registry-credentials/{name}/test — needs config:write

Registered more than once

Each route below is registered at more than one place in the control plane. The router serves the first registration; the rest are unreachable. Where two of them carry different permissions the table above shows the one the router uses, and both are listed here — a second registration is where a permission a reader expects to apply turns out not to.

GET /api/v1/registry-credentials

• pkg/api/server.go:771 — the guard config:read
• pkg/api/server.go:1149 — no permission guard

POST /api/v1/registry-credentials

• pkg/api/server.go:772 — the guard config:write
• pkg/api/server.go:1150 — no permission guard

DELETE /api/v1/registry-credentials/{name}

• pkg/api/server.go:775 — the guard config:write
• pkg/api/server.go:1153 — no permission guard

GET /api/v1/registry-credentials/{name}

• pkg/api/server.go:773 — the guard config:read
• pkg/api/server.go:1151 — no permission guard

PUT /api/v1/registry-credentials/{name}

• pkg/api/server.go:774 — the guard config:write
• pkg/api/server.go:1152 — no permission guard

POST /api/v1/registry-credentials/{name}/test

• pkg/api/server.go:776 — the guard config:write
• pkg/api/server.go:1154 — no permission guard