Ilker ManapandClaude Opus 5
e519dc587c
Reaching it meant an SSH tunnel, because the page lived on the admin listener and that listener is bound to loopback. Opening the port was never the way to fix that: it also serves pprof, and pprof can dump the process heap, where every API key sits in plaintext. Exposing the port would have been exposing the key store. So the page moves rather than the port. The same dashboard is now mounted at /admin on the client-facing port, behind the session and CSRF machinery that already guards /profile, gated on a flag on the account. The admin listener keeps pprof and metrics and stays on loopback. One bit, not a role system: it grants looking. Everything that changes the cluster or issues a credential stays on the CLI, where it needs a shell rather than a session — which keeps the worst case of a stolen admin cookie to "saw the cluster" rather than "drained your fleet". Someone without the flag gets 404, not 403. A 403 confirms the page is there and that admin accounts exist here, which is free reconnaissance; 404 is what every other unknown path returns. The profile page does not show a link to a door the visitor cannot open. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
12 lines
593 B
SQL
12 lines
593 B
SQL
-- Who may see the cluster.
|
|
--
|
|
-- Until now the answer was "whoever has a shell on the control plane", because
|
|
-- the dashboard lived on a loopback-bound port. Serving it over the web needs
|
|
-- an actual answer, and this is the smallest one that is not a lie: a flag on
|
|
-- an account that already has a password, a session and a CSRF token.
|
|
--
|
|
-- Deliberately not a role system. One bit is enough for "can see the cluster"
|
|
-- and impossible to get subtly wrong; roles arrive when there is a second
|
|
-- distinction worth drawing.
|
|
ALTER TABLE users ADD COLUMN is_admin INTEGER NOT NULL DEFAULT 0;
|