Hardening discussion: making the default SECRET_KEY / default admin harder to miss in Docker quickstart

[hopemiso]

Hi all — I've been studying Superset's security posture as part of a
security course, deploying it via the official Docker Compose quickstart
and assessing the default configuration.

A couple of observations I wanted to raise constructively (not bug reports —
these are documented behaviors, but they may be easy for new operators to miss):

1. The quickstart deployment starts with the default SECRET_KEY. I noticed
   the CLI now refuses to start with "Refusing to start due to insecure
   SECRET_KEY," which is great — but the docker-compose path can still run
   with the documented default in some setups. Given the history around
   CVE-2023-27524, would it be worth making the SECRET_KEY warning even more
   prominent in the quickstart README / first-run output?

2. The default admin/admin account from the quickstart — could the docs more
   strongly prompt a forced password change on first login for non-dev use?

I understand these are intentional for local/dev convenience and are covered
in the "Securing Superset for Production" docs. My suggestion is purely about
surfacing these to operators earlier so dev defaults don't accidentally reach
production.

Thanks for the great project.