Request: option to disable etcd password authentication (RBAC)

[l2dy]

Given that the default password is only used as a fool-proofing mechanism (#708), and that Patroni cannot reload etcd password without restarting, it's nice to have an option to disable etcd password authentication in pigsty.yml. The benefits are:

1. Improve backward compatibility with shared etcd clusters set up by Pigsty v3.7.
2. In some environments where weak passwords are forbidden or passwords need to be rotated periodically (e.g. for compliance reasons), this reduces maintenance churn.

[Vonng]

Thanks for the suggestion. Enabling etcd RBAC by default in v4.0 was a deliberate design decision, and I don't plan to add a toggle to disable it. Here's why:

Maintenance cost outweighs the benefit. Introducing an auth on/off switch means every etcd-related code path — Patroni config,, health checks, monitoring — needs to branch on that flag. that's a significant and ongoing burden, and a common source of bugs.

The stated reasons don't quite hold up. v3.7 → v4.0 is a major version bump; breaking changes are expected, and enabling auth is a reasonable upgrade step. As for compliance environments that forbid weak passwords — the fix is to set a strong password, not to disable authentication entirely. That would be a strictly worse security posture.

Existing mechanisms already cover legitimate needs. You can override the etcd root password and per-cluster passwords today. If you truly need a no-auth setup, you can run etcdctl auth disable after deployment.

The general principle here is: either auth is on everywhere, or off everywhere. Given security and compliance considerations, defaulting to "always on" with no opt-out is the better trade-off.

Appreciate the feedback — closing this as won't-fix.

[l2dy]

Thanks for the reply. I respect your decision, but I'd feel more comfortable if you wrote the response in your own words (even if it's short) than pasting some AI generated text.

The following is follow-ups to the AI generated response, not an objection to your decision:

that's a significant and ongoing burden

I'm aware of the increased maintenance cost, but how significant is it?

enabling auth is a reasonable upgrade step

Did I mention that it requires a database restart (not just Patroni reload)? This increases the risks involved.

the fix is to set a strong password, not to disable authentication entirely. That would be a strictly worse security posture.

True from a technical standpoint, but compliance is more complicated if you have to explain why the weak passwords are fine or why we don't want to rotate this password periodically (to prevent unnecessary database restart).

If you truly need a no-auth setup, you can run etcdctl auth disable after deployment.

I'd need to update Patroni config too, otherwise patronictl won't work.

[Vonng]

Yeah, it's AI-polished, but the idea stays the same.

The real question is, is there any real compliance requirement that mandates rotating etcd passwords? Since it's an extra bar on top of client certs, and it is not the database that user should use or concert directly. I think this can be further discussed if it's a real regulatory requirement.

[l2dy]

The real question is, is there any real compliance requirement that mandates rotating etcd passwords? Since it's an extra bar on top of client certs, and it is not the database that user should use or concert directly. I think this can be further discussed if it's a real regulatory requirement.

No, I'm saying that it complicates compliance due to the additional effort required to explain the authentication factors. I already get your point and don't object your decision on this matter.