fix(security): bind Grafana to loopback instead of publishing admin/admin on all interfaces

[barbatos2011]

trond apply --monitor deployed a Grafana reachable from anywhere that could route to the host, with the image's built-in credentials. Found by an audit of develop at 0c654cd.

The problem

RenderMonitoringCompose emitted the Grafana service with an unconditional - "{{.GrafanaPort}}:3000" and no environment: block at all — no GF_SECURITY_ADMIN_PASSWORD, no auth hardening — so the container kept grafana-oss's built-in admin/admin while docker published it on 0.0.0.0. Nothing else in the repo supplies a password; README.md:371 documents admin/admin.

On a cloud VM with a permissive security group that is the public internet. The payoff is not just metrics: a Grafana admin can create arbitrary datasources and query them through the backend proxy, which turns it into a server-side request primitive into the host's internal network and cloud metadata endpoints.

What changed

Grafana binds to 127.0.0.1 by default.

A new monitoring.grafana.expose restores the all-interfaces bind, but is rejected unless monitoring.grafana.admin_password_env is also set — so the escape hatch cannot recreate the finding. The renderer independently falls back to loopback for an unvalidated intent, so it fails closed rather than honouring a request it cannot verify.

The password is named by env var, not embedded: it renders as a required compose variable reference, so the secret never enters the 0644 compose file, and an unset or empty value fails at interpolation before any container is created.

Verified against real Docker (docker compose config on four rendered configurations): the default resolves to host_ip: 127.0.0.1; expose: true with a password drops the bind address and passes the secret through as a reference; expose: true without a password stays on loopback.

Note the finding's premise that the Prometheus port already had loopback treatment turned out to be wrong — Prometheus is opt-in-published via a conditional, and there was no pre-existing bind-address idiom to follow.

Behaviour changes worth reviewing

• Breaking: Grafana is no longer reachable off-host by default. An SSH tunnel (ssh -L 3000:127.0.0.1:3000), a reverse proxy, or the new expose opt-in. This mostly affects SSH/remote targets; for local targets trond already advertised grafana_url as http://127.0.0.1:<port>.
• New validation error for expose: true without admin_password_env — unreachable for any intent written today, since both fields are new.
• GF_SECURITY_ADMIN_PASSWORD only applies on first initialisation of the grafana_data volume. That is Grafana's behaviour, not ours; setting it for an already-running stack does not rotate an existing password.

Testing

go test ./... -race -count=1, go vet ./... and gofmt clean on the branch. New tests parse the rendered compose as YAML rather than substring-matching, and assert a set password never appears in the rendered file.

Unrelated bug noticed while tracing callers

deployMonitoring and deployNetworkMonitoring build the Grafana datasource URL as http://prometheus:<host port>, which is http://prometheus:0 under the default unexposed-Prometheus config. Pre-existing and untouched here, but worth its own fix.