universal-cloudflared: keep CF_* secrets out of cloudflared's environment

[tenfourty]

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description:

cloudflared logs its entire environment at INFO level on startup. It redacts
secrets, but only for variables whose names begin with TUNNEL_ (plus known secret
flags such as --token). This mod's variables are named CF_TUNNEL_PASSWORD,
CF_API_TOKEN and CF_REMOTE_MANAGE_TOKEN, so they fall outside that filter and are
written to the container log verbatim:

INF Environmental variables map[CF_TUNNEL_CONFIG:... CF_TUNNEL_NAME:homelab
    CF_TUNNEL_PASSWORD:<plaintext> TUNNEL_ORIGIN_CERT:/config/...]

This change strips those three variables from cloudflared's environment at exec
time in svc-mod-universal-cloudflared/run.

They are not needed by that point. init-mod-universal-cloudflared-setup has already
derived TunnelSecret from CF_TUNNEL_PASSWORD, written
/etc/cloudflared/${CF_TUNNEL_ID}.json, and emitted
credentials-file: /etc/cloudflared/${CF_TUNNEL_ID}.json into config.yml —
so cloudflared authenticates from the credentials file, not the environment.

The existing guards are unaffected because they are evaluated before the exec, and
--token ${CF_REMOTE_MANAGE_TOKEN} still receives its value because bash expands it
before env removes it from the child's environment.

Benefits of this PR and context:

The tunnel secret is currently readable by anyone who can run docker logs on the
container, or through any log viewer pointed at it, and it persists for as long as
the log history is kept. Users have no way to avoid this short of lowering
loglevel, which also suppresses normal connection and registration logging and
brings the secret straight back for anyone who raises the level again to debug.

Two alternatives were considered and rejected:

• Lowering loglevel to warn — hides the dump but loses useful logging, and
  only masks the problem.
• Renaming the variables to TUNNEL_* so cloudflared's own scrubber catches
  them — cleaner in principle, but a breaking change for every existing user.

How Has This Been Tested?

Tested on a running lscr.io/linuxserver/swag container with this mod enabled
(cloudflared 2026.8.2, named tunnel authenticating from the credentials file), by
replacing the live service script under /run and restarting only that s6 service
with s6-svc -r.

Variables appearing in cloudflared's startup environment dump:

before	CF_TUNNEL_CONFIG, CF_TUNNEL_NAME, CF_TUNNEL_PASSWORD, TUNNEL_ORIGIN_CERT
after	CF_TUNNEL_CONFIG, CF_TUNNEL_NAME, TUNNEL_ORIGIN_CERT

The tunnel re-registered all four QUIC connections normally and the proxied hostnames
continued to serve (HTTP 200). bash -n passes on the modified script.

Only the CF_TUNNEL_* / CF_API_TOKEN branch was exercised; I do not have a
CF_REMOTE_MANAGE_TOKEN setup to test the first branch, though the change there is
identical in form.

Source / References:

• cloudflared run parameters (loglevel is the only logging control; there is no
  option to suppress the environment dump):
  https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/run-parameters/
• cloudflared redacts secrets for TUNNEL_* environment variables and known secret
  flags, which is why the CF_* names are not covered.

[tenfourty]

btw - I think your CI is currently broken.

[thespad]

It's not broken per se, it just fails for 3rd party PRs since they changed the restrictions on pull_request_target because Github's workflow approvals system is busted.

[tenfourty]

Brilliant, thank you!