Evaluate mesh and end-user access options

[yannick-vinkesteijn]

Feature description

Evaluate the access setup beyond the Headscale operator mesh.

Mesh at review (pinned commit): https://github.com/srdp-hub/srdp/tree/6571735939e43fbf8d44b97a9fb4d25283f6234f/deploy/scaleway/deploy/mesh

Use case

As shipped, end users would need Headscale enrollment just to open Marimo. We want to decide the access profile for researchers and check whether one service can cover both open access and VPN.

Proposed solution

• Decide the end-user access profile: mesh only, or a browser facing ingress (public LB or identity aware edge). May become an ADR.
• Evaluate Pangolin as a single service covering both open access and VPN. Check the blockers: OIDC federation to an external IdP (we want Zitadel) may be a paid feature, and community edition limits are unclear. If it works it removes the split DNS and hosts file workarounds in the mesh backlog.
• Keep Headscale as the default until an alternative clearly wins.

Alternatives considered

Headscale only (current), public ingress in front of oauth2-proxy, Pangolin.

Component: Infra: Other

[AE-EVKA]

A data point for option 2 (public ingress + oauth2-proxy), from a client project rather than from
Marimo specifically.

I've put a dashboard of my own behind the Traefik + oauth2-proxy + Zitadel gate on the Compose
stack. For my users — small data teams, not researchers with managed laptops — requiring mesh
enrollment to open a dashboard would be a hard sell. Browser-facing ingress with SSO in front is the
thing they expect and the thing they'll accept.