Scope the bridge's Secret access to the referenced per-App Secrets (per-client RBAC grants) #55

New issue

Open

opened 2026-09-19 01:23:14 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-09-19 01:23:14 +00:00

Owner

Context

Security architecture review, 18 Sep 2026 (candidate 1, "Strong"). The bridge's ServiceAccount currently carries a cluster-wide secrets rule (read for every replica, write for the leader) because the mirror watches the referenced per-App client Secrets in arbitrary App namespaces. That is strictly broader than ADR 0005's stated consequence ("every replica needs RBAC to read the referenced per-App Secrets (in App namespaces)"): a compromised manager pod can read — and, for the leader, rewrite — every Secret in the cluster, not just the client Secrets of the Apps the bridge serves.

What to build

Scope the bridge's Secret access to exactly the referenced per-App Secrets, using per-client RBAC grants: one Role + RoleBinding per OauthClient, in the client's namespace, granting get/watch on exactly the referenced client Secret name. Follow the existing per-client grant pattern the repo already runs for ReferenceGrants (ownership labels, deterministic names, GC on client deletion). The leader's referenced-Secret check and the replica mirror's watch operate through these scoped grants; the leader keeps a narrow by-name rule for the two managed Secrets (Registry + Cookie key) in the bridge namespace. The cluster-wide secrets RBAC markers are removed.

Sequence as expand–contract: add the grant mechanism first (nothing breaks while the old rule exists), then switch the mirror/leader over, then narrow the markers.

Acceptance criteria

For each OauthClient with a clientSecretRef, a Role + RoleBinding exists in the client's namespace granting get/watch on exactly the referenced Secret name
Grants are updated when the clientSecretRef changes and GC'd when the OauthClient is deleted (same ownership/GC pattern as the ReferenceGrant controller)
The cluster-wide secrets RBAC markers are gone; the leader's checkSecrets and the replica mirror's watch operate through the per-App Roles
The leader retains access to the managed Registry + Cookie key Secrets (by-name, bridge namespace)
make manifests regenerates the RBAC; tests cover grant reconciliation (create, update on ref change, GC)
A test asserts the scoped access: with only the per-App Role, the referenced Secret is readable and an unrelated Secret in the same namespace is not
Existing registry/snapshot tests stay green

Blocked by

None — can start immediately

## Context Security architecture review, 18 Sep 2026 (candidate 1, "Strong"). The bridge's ServiceAccount currently carries a cluster-wide `secrets` rule (read for every replica, write for the leader) because the mirror watches the referenced per-App client Secrets in arbitrary App namespaces. That is strictly broader than ADR 0005's stated consequence ("every replica needs RBAC to read the referenced per-App Secrets (in App namespaces)"): a compromised manager pod can read — and, for the leader, rewrite — every Secret in the cluster, not just the client Secrets of the Apps the bridge serves. ## What to build Scope the bridge's Secret access to exactly the referenced per-App Secrets, using per-client RBAC grants: one Role + RoleBinding per OauthClient, in the client's namespace, granting get/watch on exactly the referenced client Secret name. Follow the existing per-client grant pattern the repo already runs for ReferenceGrants (ownership labels, deterministic names, GC on client deletion). The leader's referenced-Secret check and the replica mirror's watch operate through these scoped grants; the leader keeps a narrow by-name rule for the two managed Secrets (Registry + Cookie key) in the bridge namespace. The cluster-wide `secrets` RBAC markers are removed. Sequence as expand–contract: add the grant mechanism first (nothing breaks while the old rule exists), then switch the mirror/leader over, then narrow the markers. ## Acceptance criteria - [ ] For each OauthClient with a clientSecretRef, a Role + RoleBinding exists in the client's namespace granting get/watch on exactly the referenced Secret name - [ ] Grants are updated when the clientSecretRef changes and GC'd when the OauthClient is deleted (same ownership/GC pattern as the ReferenceGrant controller) - [ ] The cluster-wide `secrets` RBAC markers are gone; the leader's checkSecrets and the replica mirror's watch operate through the per-App Roles - [ ] The leader retains access to the managed Registry + Cookie key Secrets (by-name, bridge namespace) - [ ] `make manifests` regenerates the RBAC; tests cover grant reconciliation (create, update on ref change, GC) - [ ] A test asserts the scoped access: with only the per-App Role, the referenced Secret is readable and an unrelated Secret in the same namespace is not - [ ] Existing registry/snapshot tests stay green ## Blocked by - None — can start immediately

ginjiruu added the

ready-for-agent

label

2026-09-19 01:25:24 +00:00