Bug report criteria
What happened?
Starting with etcd 3.5.28 (the fix for CVE-2026-33413), all RPCs on the Maintenance service require the caller to have the root role. Before 3.5.28, several of these RPCs — including Status, MemberList, and AlarmList — skipped the authorization check entirely, which was the security gap being fixed.
In 3.5.29 (#21550), MemberList and AlarmList were explicitly added to a non-admin-allowed list so that authenticated non-admin users can still use them for member discovery and alarm inspection. Maintenance.Status was not included in that carve-out and continues to require the root role.
This breaks a common and previously-working pattern: non-admin clients (identified by TLS client-cert CN, granted a scoped key-prefix role) calling Status as a lightweight health-check probe. These clients now receive:
'''rpc error: code = PermissionDenied desc = etcdserver: permission denied'''
Clients running against 3.5.27 or earlier work; the same clients against 3.5.28/3.5.29 fail.
What did you expect to happen?
Authenticated non-admin users should be able to call Maintenance.Status, consistent with the treatment given to MemberList and AlarmList in 3.5.29. Status is widely used as a health/liveness probe and exposes only node-local metadata (server version, DB size, leader member ID, raft term/index/applied index, alarms, isLearner, member ID) — no key-value data and no destructive operation.
How can we reproduce it (as minimally and precisely as possible)?
Prereqs: an etcd 3.5.28 or 3.5.29 cluster with --client-cert-auth=true and auth enabled (etcdctl auth enable).
Create a non-admin user and role with a scoped key-prefix permission:
etcdctl --user root: user add test-client --no-password
etcdctl --user root: role add test-role
etcdctl --user root: role grant-permission test-role --prefix=true readwrite /test/
etcdctl --user root: user grant-role test-client test-role
Issue a client certificate with CN=test-client, signed by the CA etcd trusts.
Call Maintenance.Status with that cert:
ETCDCTL_API=3 etcdctl
--endpoints=https://:2379
--cacert=ca.crt --cert=test-client.crt --key=test-client.key
endpoint status
Anything else we need to know?
No response
Etcd version (please run commands below)
etcd 3.5.29
Etcd configuration (command line flags or environment variables)
Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)
Relevant log output
Error: rpc error: code = PermissionDenied desc = etcdserver: permission denie
Bug report criteria
What happened?
Starting with etcd 3.5.28 (the fix for CVE-2026-33413), all RPCs on the Maintenance service require the caller to have the root role. Before 3.5.28, several of these RPCs — including Status, MemberList, and AlarmList — skipped the authorization check entirely, which was the security gap being fixed.
In 3.5.29 (#21550), MemberList and AlarmList were explicitly added to a non-admin-allowed list so that authenticated non-admin users can still use them for member discovery and alarm inspection. Maintenance.Status was not included in that carve-out and continues to require the root role.
This breaks a common and previously-working pattern: non-admin clients (identified by TLS client-cert CN, granted a scoped key-prefix role) calling Status as a lightweight health-check probe. These clients now receive:
'''rpc error: code = PermissionDenied desc = etcdserver: permission denied'''
Clients running against 3.5.27 or earlier work; the same clients against 3.5.28/3.5.29 fail.
What did you expect to happen?
Authenticated non-admin users should be able to call Maintenance.Status, consistent with the treatment given to MemberList and AlarmList in 3.5.29. Status is widely used as a health/liveness probe and exposes only node-local metadata (server version, DB size, leader member ID, raft term/index/applied index, alarms, isLearner, member ID) — no key-value data and no destructive operation.
How can we reproduce it (as minimally and precisely as possible)?
Prereqs: an etcd 3.5.28 or 3.5.29 cluster with --client-cert-auth=true and auth enabled (etcdctl auth enable).
Create a non-admin user and role with a scoped key-prefix permission:
etcdctl --user root: user add test-client --no-password
etcdctl --user root: role add test-role
etcdctl --user root: role grant-permission test-role --prefix=true readwrite /test/
etcdctl --user root: user grant-role test-client test-role
Issue a client certificate with CN=test-client, signed by the CA etcd trusts.
Call Maintenance.Status with that cert:
ETCDCTL_API=3 etcdctl
--endpoints=https://:2379
--cacert=ca.crt --cert=test-client.crt --key=test-client.key
endpoint status
Anything else we need to know?
No response
Etcd version (please run commands below)
etcd 3.5.29
Etcd configuration (command line flags or environment variables)
Etcd debug information (please run commands below, feel free to obfuscate the IP address or FQDN in the output)
Relevant log output