etcd RBAC: the root CA issues every client certificate, members hold no intermediate #83

New issue

Open

opened 2026-10-07 17:20:03 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-10-07 17:20:03 -03:00

(Migrated from github.com)

Maintainer decision, 2026-10-07 (answer 'SIm' to the proposal after the keel#81 review, finding 4).

Today each etcd member holds an intermediate CA (root-signed, name-constrained to its /128) and issues its own client certificates. etcd maps users from the client certificate CN, so any member can mint a certificate with any CN, root included, and per-user RBAC is meaningless.

Decision:

The root CA (the region root, 0051) issues every etcd client and peer certificate itself; the request is relayed by the inviter as today for intermediates. Members hold no intermediate CA.
The CN is the member's mesh identity, fixed by the root; SANs stay the member's /128.
etcd auth is enabled; users map to CNs; roles: the VIP key prefixes of a pair are read-write only for that pair's two members, read for the rest; the root holder manages users and roles.
Renewal (30 days) and new memberships wait while the root is unreachable; with several regions (0051) another root issues, as 0051 point 8 already says.
Amends 0048 third round (Q1) and 0051 (intermediates per member). A handbook amendment records it.
Do this after keel#81 (VIP) merges, to avoid conflicts in the etcd code. The VIP keeps its signed-claim checks as defence in depth.

Maintainer decision, 2026-10-07 (answer 'SIm' to the proposal after the keel#81 review, finding 4). Today each etcd member holds an intermediate CA (root-signed, name-constrained to its /128) and issues its own client certificates. etcd maps users from the client certificate CN, so any member can mint a certificate with any CN, root included, and per-user RBAC is meaningless. Decision: - The root CA (the region root, 0051) issues every etcd client and peer certificate itself; the request is relayed by the inviter as today for intermediates. Members hold no intermediate CA. - The CN is the member's mesh identity, fixed by the root; SANs stay the member's /128. - etcd auth is enabled; users map to CNs; roles: the VIP key prefixes of a pair are read-write only for that pair's two members, read for the rest; the root holder manages users and roles. - Renewal (30 days) and new memberships wait while the root is unreachable; with several regions (0051) another root issues, as 0051 point 8 already says. - Amends 0048 third round (Q1) and 0051 (intermediates per member). A handbook amendment records it. Do this after keel#81 (VIP) merges, to avoid conflicts in the etcd code. The VIP keeps its signed-claim checks as defence in depth.