Should we remove secrets.json and move to environment-only configuration?

[stanfrbd]

Cyberbro currently supports two configuration sources:

1. secrets.json
2. Environment variables (including .env-driven workflows)

At runtime, configuration is loaded from secrets.json first, then overridden by environment variables.

There is also an optional /config GUI page that can update secrets and write them to disk (secrets.json). This page is already disabled by default and documented as unsafe for public/team use.

Why I’m opening this discussion

I’m considering dropping secrets.json support and using environment variables only (typically via .env for local/dev and secret injection for production).

Main reason: security and design clarity.

• Persisting API keys/secrets to a file inside the app/container is risky.
• As the project grows, I want to avoid introducing vulnerability by design.
• Environment-first deployments are the standard pattern for containerized apps.

Also, we currently maintain dual behavior (secrets.json + ENV + config page), which increases complexity and ambiguity.

Current design concern

Today, even if secrets are provided from environment variables, the app logic can write a secrets.json file at runtime when values differ from defaults.

That means values injected via environment may still be persisted to disk by the application, which weakens the “secret-in-env” model and can surprise operators.

Proposal

Adopt a clear policy:

• Primary and only supported runtime source: environment variables
• Deprecate and remove: secrets.json read/write path
• Remove or retire: /config page secret editing workflow (or keep only non-sensitive runtime toggles, if any)

Expected benefits

• Smaller attack surface
• More predictable behavior in Docker
• No secret write-back to local files by app logic => This is the main concern, especially with the rise of infostealers
• Simpler documentation and support matrix

Trade-offs

• Less convenience for users who prefer a single JSON file => But this file is getting bloated...
• Loss of current GUI-based secret editing flow => Shouldn't be a great loss honestly?
• Migration effort in docs/examples/tests => For the sake of simplification.

Scope boundary

I’m intentionally trying to avoid turning this into a full multi-user admin system.

Adding auth/roles/session management only to protect a config page was never the goal of Cyberbro, and I don’t want to rebuild something comparable to IntelOwl’s architecture.

Migration idea (if accepted)

• Mark secrets.json as deprecated in next release
• Emit warning when secrets.json is detected
• Remove write-back behavior first
• Update docs and examples to .env/environment-only

Questions for maintainers and users

1. Would you support an environment-only configuration model?
2. Do you rely on /config in real deployments, or only in local testing?
3. Should we keep a temporary compatibility layer for one release cycle?
4. Any blocker?

I’d like to converge on a secure, simple default before the project grows further. Please, let me know what you think!

Stan

[ubahmapk]

Simpler is good. 👍

The original Settings object with Pydantic was very basic (my fault).

This might be a good opportunity to move to something that's more widely adopted (specifically) for config management - like Dynaconf (or something else)? That would retain config files for those who want/need that capability, and it has good support for secrets management, but still eases the management of merging values. It's a very standard setup. It also already inherently supports Flask app config.

Regardless, I'd still support retiring /config. If you need to edit a config, edit the env or the conf file manually. No need for a web interface for that.

Answers

1. Yes
2. Local testing only
3. Probably a good idea
4. None that I see (yet)