Reading non-secret values from a remote store (Azure App Configuration)

[jmoreno11]

Hi, first of all thanks for fnox. It replaced a pile of shell scripts and half-committed .env files on our Azure project.

Use case

We inject our whole environment through fnox, across three Azure environments. Some of those values are not secrets. AZURE_OPENAI_ENDPOINT is a public hostname our IaC pipeline writes when it provisions the model deployment, and it sits in Key Vault only because Key Vault is the only Azure store fnox can read. So we have RBAC grants and audit logging on a URL.

Then I found the "Public Configuration" section in docs/providers/plain.md, so non-secret values are clearly welcome, as long as they are literals in the file. That is where we get stuck. Ours live in Azure App Configuration, which is the store designed for them, and a literal cannot follow a value that infrastructure owns.

Alternatives considered

1. mise [env] with mise.<env>.toml. This works, and I understand it is the intended answer, but the environment is then described in two files, and one of them quietly goes stale when IaC rotates a deployment.
2. plain defaults in fnox.toml. The same problem in one file instead of two.
3. azure-sm with a per-profile prefix. This part works nicely, and it means a new provider would need no new profile mechanism at all. It just does not change the fact that a non-secret has to go into Key Vault to be reachable.
4. A script calling az appconfig kv show. One az process per value, and invisible to fnox check, fnox ls and the daemon cache.

Proposed solution

docs/guide/sync.md calls fnox.toml "the source of truth", and that is how we treat it: one file describing an environment completely, whatever store each value happens to live in. fnox feels close to that already, since exec, export, check and the daemon cache all work fine without knowing whether a value is sensitive.

An azure-ac provider reading Azure App Configuration:

[providers]
appconfig = { type = "azure-ac", endpoint = "https://my-store.azconfig.io", label = "dev" }

Read-only, no new dependencies since reqwest, azure_identity and azure_core are already fnox-core deps. label would be an ordinary provider field, so [profiles.<name>.providers] covers per-environment labels for free.

Question

Would you be open to a provider that reads non-secret values from a remote store, so the configuration plain.md already covers can be resolved instead of hardcoded?

If yes, I am happy to write it and open the PR.

[jmoreno11]

Wrote it: #659.

Read-only azure-ac, no new dependencies, and label ended up being an ordinary provider field as hoped, so profiles cover it with no new mechanism. I tested it against a real store before opening, including hierarchical keys and the label vs no-label case, then deleted the store.

Opening the PR is not me assuming the answer is yes. If it is no, or if you would rather this lived outside fnox, say so and I will close it.