Document security implications of flyio-proxy → homelab ACL
The new ACL grant lets the Fly.io proxy reach all Caddy-proxied services, not just Loki/Prometheus. Document the expanded attack surface and trust boundary (requires RCE on gilbert or 1Password access) in both the flyio-proxy and caddy reference cards. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
1e1e513b4a
commit
977f63a951
2 changed files with 12 additions and 0 deletions
|
|
@ -79,6 +79,10 @@ mise run provision-indri -- --tags caddy
|
|||
|
||||
The token is written to `~/.config/caddy/gandi-token` (chmod 0600) and sourced by the Caddy wrapper script.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
Caddy has no authentication layer — it is a plain reverse proxy. Access control relies entirely on Tailscale ACLs restricting which devices can reach indri on port 443. Currently `tag:homelab`, `autogroup:admin`, and `tag:flyio-proxy` can reach Caddy. The [[flyio-proxy]] grant exists so Alloy can push metrics/logs to Loki and Prometheus, but it means the Fly.io container can technically reach all Caddy-proxied services. See [[flyio-proxy#Security Considerations]] for the threat model.
|
||||
|
||||
## Custom Build
|
||||
|
||||
Caddy is built from source with the Gandi DNS plugin:
|
||||
|
|
|
|||
|
|
@ -70,6 +70,14 @@ The Tailscale auth key is `preauthorized=True` to avoid device approval hangs on
|
|||
|
||||
Alloy listens on `127.0.0.1:12345` for self-scraping its `/metrics` endpoint. All metrics carry `instance="flyio-proxy"`.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
The `tag:flyio-proxy` ACL grants access to both `tag:k8s:443` (for proxying public services) and `tag:homelab:443` (for pushing metrics/logs to [[caddy|Caddy]]-proxied Loki and Prometheus). This means a compromised nginx config could route traffic to **any** Caddy-proxied service — not just the intended backends. Some of those services (Loki, Prometheus) have no auth; others ([[forgejo]], [[navidrome]], [[immich]]) do.
|
||||
|
||||
Exploitation requires either pushing a malicious image to Fly.io or modifying the nginx config — both of which require RCE on [[gilbert]] (where `fly` is authenticated) or access to [[1password]] (the deploy token). This is an acceptable boundary given that 1Password is already the trust root for the entire infrastructure.
|
||||
|
||||
If this surface area becomes a concern, an alternative would be to add dedicated Tailscale Ingress tags for Loki/Prometheus write endpoints and restrict `tag:flyio-proxy` to only those.
|
||||
|
||||
## Secrets
|
||||
|
||||
| Secret | Source | Description |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue