Allowed addresses
Each admin user can be limited to a list of IP addresses and ranges they may sign in from. The list is checked on every personal sign-in, with a password or a passkey, after the credential has been verified. An empty list, the default, admits every address.
The list is per admin user, not per server. A colleague who always works from the office network can be held to it while the on-call admin user, who signs in from anywhere, is not.
Set the list
On Admin Users, select Allowed IPs on the admin user's row. The
page, Allowed IP Addresses, takes IPv4 and IPv6 addresses and CIDR
ranges, e.g. 203.0.113.7 or 2001:db8::/32, and replaces the list when
you save. Like every change on that screen, it asks you to confirm your
identity first.
On the host:
elpanctl server:admin-user:set-allowed-ips <username> --ip=<ip or cidr> --ip=<ip or cidr>
elpanctl server:admin-user:set-allowed-ips <username> --clear
--ip is repeatable and replaces the whole list; --clear empties it so
the admin user may sign in from anywhere. The command refuses a value that
is not an address or a CIDR range. A new admin user gets its list at
creation with server:admin-user:create --allow-ip=<ip or cidr>.
Every change is a row of the Auth Log, Allowed addresses changed, on the admin user whose list it is.
When you edit your own addresses, the page warns you: if the address you are using isn't in the list, you can't sign in again with your password or a passkey. Your current session continues. The way back in is the break-glass (see Break-glass on the host), or another admin user who clears your list.
The refusal
A sign-in from an address the list doesn't admit fails with one message, Login is not allowed from your IP address., whether the credential was a password or a passkey. The check runs after the password is verified, or after the passkey is verified and before any session exists, so a right credential from the wrong place gives away nothing but the message.
The attempt is recorded as Sign-in failed with the reason address not allowed and the method tried. On the Auth Log, filter by IP Address to see what else came from there.
What is not held to the list
Two ways in deliberately skip it:
| Way in | Why |
|---|---|
A server:login token | Whoever can mint one is root on the host, which has proven more than an address. See Break-glass on the host. |
| A server API key, including a key owned by this admin user | A key is a bearer secret for automation, and never had an allowlist. Giving a key an owner didn't change what it is checked against. |
The second step after a password is not a separate way in, so it has no check of its own: the list was already checked when the password was.
A server API key is limited by its scope and its expiry, and revoked when
it leaks; see API Keys. To limit where the
API is reachable from, do it at the network, on both hosts that serve it:
admin.<server hostname> and the bare server hostname, which proxies
/api/v1 to the admin app.