housecarl/docs/permissions.md

Users, permissions and tokens

Users

Administrators may do everything, including managing users. Everyone else gets grants, resource:access:

Resource	read	write
config	settings, zones, sets, services, rules, NAT, the ruleset, history, interfaces, probation, changesets (the web UI shows the forms locked)	change them, stage and apply changesets (your own, or anyone's for administrators), undo, import, confirm and roll back; close connections; start and stop traces
sets	dynamic sets' entries	add and remove entries
bans	ban lists' bans, and the lists the grant names	ban and unban (bans.md)
log	hit counters, the log, connections, traces	–
audit	the audit log	–
*	all of the above

A sets grant can name the sets it covers: sets:write:guests may change the entries of the set guests and no other; sets:read:guests,blocked may read two. That is the grant for another program, such as Steward's captive portal, which should be able to let a client in and nothing more. A dynamic set's entries need a sets grant even for those with config:write.

A bans grant names ban lists the same way: bans:write:web may ban into the list web (and read it) and nothing else, the grant for Guard or fail2ban on the web server.

Only administrators may delete other tables (hc takeover), and manage users and the certificate (hc cert, Server → Certificate).

Roles are ready-made sets of grants:

Role	Grants
viewer	config:read sets:read bans:read log:read
operator	config:write sets:write bans:write log:read audit:read
log	log:read, e.g. for a monitoring script

hc user add sam --role operator
hc user add portal --no-password --grant sets:write:guests     # tokens only
hc user update sam --grant config:read --grant log:read

The last administrator can't be removed, demoted or disabled.

API tokens

A token has its user's permissions, or fewer. A token made with --role or --grant can do only that, even if its user can do more:

hc token create portal --user portal --grant sets:write:guests --expires 365d

The secret is shown once; only its hash is stored. A restricted token can only create tokens with a subset of its own grants.

In the web UI, Account → New token makes one of your own; an administrator makes one for another user with New token on that user's row under Users (--user in the CLI, POST /users/{id}/tokens in the API). The dialog only offers roles within what the token's user may do; a token with more would get no more than its user anyway.

Rotating gives a token a new secret, keeping its ID, name and permissions, so only the programs that use it need updating:

hc token rotate 7 --grace 1h           # the old secret works for another hour
hc token rotate --current --save       # this CLI's own token

A token that expires gets its lifetime again, from now (--expires 90d or never to change it). Without --grace the old secret stops at once: use that when it may have leaked. Using an old secret during its grace period is logged, naming the token and the address, so you can find the programs still to update. A restricted token may rotate itself and tokens no wider than itself. hc token list shows when each token was last used, and from where. hc token revoke ID stops one at once.

The local socket

On the firewall, /run/housecarl/housecarl.sock lets root and the housecarl user act as administrator without a token, and their changes aren't on probation. The audit log shows them by their system user name. Both can already change the machine's firewall, so this adds convenience, not power. Anyone else on the socket needs a token, and their changes are on probation like any other.

The audit log

Logins (and failed ones), users, tokens, every configuration change (with its history entry), changesets created, applied and discarded, confirmations and rollbacks, imports, takeovers, dynamic set entries and bans are recorded with who, from where and how: session, token or socket.