Security: CLI-only config makes secrets harder to handle safely

[pahaz]

Feature Description

Authorizer v2 currently accepts configuration only through CLI arguments. This includes sensitive values such as client secrets, JWT secrets, admin secrets, database passwords, and SMTP credentials.

This makes production deployments harder to secure and may discourage teams from adopting Authorizer.

Describe the solution you'd like

Please add a safer way to provide secrets in production, for example:

• environment variables;
• --*-file options, such as --jwt-secret-file;

CLI arguments can remain supported for local development and backward compatibility.

Describe alternatives you've considered

Using CLI arguments only, as currently documented. This works, but secrets passed this way may be exposed through process listings, /proc/<pid>/cmdline, systemd logs, container metadata, CI logs, shell history, or monitoring tools.

Additional context

This is not about requiring .env support specifically. The main concern is safe secret delivery in production. Many platform and security teams expect env vars, secret files, or secret manager integration. A CLI-only configuration model can be enough to fail security review.

[lakhansamani]

This was done, to make it secure, as we can inject env / secret store or mounted read only volumes (k8s) specific into cli args.
This makes it more flexible and secure.