AlinsRan commented on issue #12170: URL: https://github.com/apache/apisix/issues/12170#issuecomment-4888911574
Agree with @SkyeYoung / @juzhiyuan on fail-fast over auto-generation. Reasoning, tied to the actual behavior today: The real bug here is the **config.yaml rewrite** in `core/id.lua`: on an empty `admin_key` it generates a key, flips `changed`, and rewrites the file — which drops comments and can emit a trailing `...`, breaking the next start. That write-back has to go regardless of what we decide for the empty-key case. Auto-generating the key (even purely in memory, without the rewrite) is still the wrong default for two reasons: 1. **It changes on every restart.** A token that silently rotates each boot is unusable for any real deployment and confusing to debug — you set nothing, it "works", then breaks after a restart. 2. **It hides a security-relevant misconfiguration.** Silently inventing an admin credential is the opposite of fail-safe; the operator never learns they shipped without a key. We already have the right switch for the "I really don't want auth" case: **`admin_key_required`**. So the clean model is: - `admin_key_required: false` → run without an admin key (already supported, already prints a warning). This is the getting-started / local-dev path. - `admin_key_required: true` (the default) + empty/missing key → **fail fast at startup** with a clear message telling the user to set a key. No generation, no file mutation. Concretely that means: drop `autogenerate_admin_key` and the `write_file` back-write in `core/id.lua`, and change the current "empty key → will auto-generate" warning in `cli/ops.lua` into a hard error when `admin_key_required` is on. Secure by default, no surprise config edits, and the escape hatch for trials is one explicit flag. Behavior change to call out: anyone relying on the old auto-generate would now need to either set a key or set `admin_key_required: false`. That seems acceptable given it's the documented, safer default. I can take this if nobody's already on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
