Security
Access lists
The common use is putting an admin area behind your office network while the rest of the site stays public. Lists are made once and shared by as many sites as you like.
What a list holds
| Setting | What it does |
|---|---|
| Allowed | Addresses or networks that may reach it. One per line. A single address, or a range such as 198.51.100.0/24. |
| Blocked | Addresses that may not. Used with a default of allow, for shutting out a specific nuisance. |
| When nothing matches | Allow or deny. Deny with a list of allowed addresses is a private area. Allow with a list of blocked ones is a public area with exceptions. |
| Include the management networks | Adds the networks set in Settings, plus every cluster node, so you do not lock yourself out of your own admin area. |
| Ask for a username and password | A second lock on top of the address check. |
| Trust the address from a header | For when something else sits in front, such as a CDN. |
The setting that stops you locking yourself out
Include the management networks adds an allow line for each network in Settings and for every node in the cluster, generated from the roster rather than typed in. A node you add later lands in every one of those lists on its own.
That is the part people forget when doing this by hand, and it is how health checks end up blocked by an ACL somebody wrote months earlier, producing a pool that is down for no visible reason.
Trusting the address from a header
This is the dangerous one
If you turn it on when nothing trustworthy is in front of your load balancers, anybody can set that header themselves and walk straight through your access list. Turn it on only when you know exactly what is in front and you have named it as trusted. There is no partial version of this: either the header is trustworthy or your list is decoration.
A username and password
Reasonable as a second layer on top of an address check. Thin on its own: it is one shared secret, it is often written down, and it never gets rotated. Use it to add friction, not as the only thing between the internet and an admin area.
Put it on a path where you can
Applying a list to a whole site when you meant to protect one area is how a public website ends up
reachable only from the office. Choosing the list on a single path is what lets you lock down
/admin and leave the rest alone.
Management network only
Sites have a shortcut switch for the common case. It writes an allow line for every node in the cluster plus your management networks, then deny all. It is the right answer for an internal tool that happens to be served by the same load balancers as your public site.
Common questions
IPv4 and IPv6 both?
Yes. Put both forms in the list. A visitor arriving over IPv6 when your list only names IPv4 addresses is a very common way to lock yourself out.
Is this the same as the list that controls the management screen?
No, and the difference matters. Who may open the management GUI is set in the environment file on each node, because it has to be in force before the login page renders, which is earlier than anything in the database can be read.
Can I share one list across sites?
Yes, that is why they live on their own page. One office network list used by six admin areas is much easier to keep correct than six copies.
Step by step instructions
The how to section has searchable, task shaped answers. Search it for access list.
Related features
Rate and connection limits
Cap how fast and how much one visitor can ask for.
Read moreCountry blocking
Cut scanner noise and meet a rule about where you serve.
Read morePath routing
Send /api one way and everything else another.
Read moreUsers, roles and TOTP
Three roles, a second factor, and recovery codes.
Read more