Proposal: a --security "anonymous=..." key for Alpha

[matthewmcneely]

Proposal: a --security "anonymous=..." key for Alpha

Currently, Alpha's privileged operations sit behind three independent checks: the --security "whitelist=" source-IP list, the --security "token=" shared secret, and ACL guardian authorization. Each one passes when its own feature is unconfigured, so the protection you get is whatever you configured rather than the union of the three. The stock default is tighter than it looks, since an empty whitelist admits loopback only. The gap is that whitelist answers where a request came from and carries no credential in it, so widening the range is by itself enough to make administrative operations reachable anonymously from anywhere inside it. whitelist=0.0.0.0/0 is a common setting (our own dgraph/standalone quickstart image sets it unconditionally), and in that posture there is nothing left to check. I'd like to add a fourth key that says directly what a caller with no verified identity may do: --security "anonymous=full|data|none". full is today's behavior. data lets an unauthenticated caller run queries, mutations, commits, and login, while every administrative capability is denied regardless of whitelist: namespace create/drop, UID leasing, drop-all, backup/restore/export, shutdown, removeNode, moveTablet, and cluster config. none leaves only login and the health and readiness endpoints. To make data usable without standing up full ACL, --security "token=" would also start producing an identity rather than acting as a boolean check, so a token-bearing client counts as authenticated instead of anonymous.

On rollout, the plan is to ship this in an upcoming v25 in an upcoming release with anonymous=full as the default so that nothing changes for an existing cluster, plus a startup warning when the whitelist has been widened with neither a token nor ACL configured. v26 would flip the default to data.

Two things I'd like feedback on. First, is the three-value split the right cut, or is a boolean enough for what people actually deploy? Second, is data the right default for v26, and if you run Dgraph in production today, would that break you? I already know of one rough edge: dgraph live allocates UIDs through an administrative RPC and has no way to attach --auth_token to that call, so the loaders need client-side work before any default can move. dgraph increment and dgraph import are in the same shape. I'd rather collect the rest of that list now than in a v26 release thread.

Thanks!