Access Control Fundamentals
Nginx offers several layers of access restriction that can be combined: IP-based allow/deny rules using the ngx_http_access_module, HTTP Basic Authentication via auth_basic, and the satisfy directive that decides whether all conditions must pass or just one. These mechanisms let you lock down admin panels, internal APIs, or staging environments without touching application code.
Cricket analogy: It's like a stadium that lets members-stand ticket holders in through one gate and requires everyone else to show ID at a second gate - two independent checks that can be required together or as alternatives.
IP Allow/Deny and satisfy
Rules under allow and deny are evaluated top to bottom, and the first match wins, so ordering matters: a deny all catch-all must come last. The satisfy directive controls how multiple access mechanisms combine - satisfy all requires every condition (IP match AND valid credentials) to pass, while satisfy any lets a request through if it satisfies at least one, such as trusted internal IPs bypassing the password prompt entirely.
Cricket analogy: It's like DRS review order - the on-field call, then ball-tracking, then snickometer are checked in a defined sequence, and the first conclusive signal in that chain settles the decision.
location /admin/ {
satisfy any;
allow 10.0.0.0/8; # trusted internal network bypasses auth
deny all;
auth_basic "Restricted Area";
auth_basic_user_file /etc/nginx/.htpasswd;
}
location /internal-api/ {
satisfy all; # must be on trusted IP AND supply valid credentials
allow 10.0.0.0/8;
deny all;
auth_basic "Internal API";
auth_basic_user_file /etc/nginx/.htpasswd_api;
}Generate htpasswd files with htpasswd -c /etc/nginx/.htpasswd username (the -c flag creates a new file - omit it when adding additional users to an existing file).
Combining with Rate Limiting and Geo Blocks
Beyond simple allow/deny lists, the geo module can map client IP ranges to a variable used later in access decisions, which scales far better than dozens of individual allow lines when restricting by country or CIDR block. This is commonly paired with a map directive to build a blocklist variable that's checked with an if inside a location, returning 403 for disallowed sources before the request ever reaches the upstream application.
Cricket analogy: It's like a ground's regional ticketing system that groups postcodes into zones rather than listing every individual street, making it far easier to open or close entire regions for a match.
IP-based access control alone is not a substitute for authentication - IP addresses can be spoofed at the network layer or shared behind NAT/corporate proxies, so combine allow/deny with auth_basic or a proper application-level auth layer for anything sensitive.
- allow/deny rules are evaluated top-to-bottom and the first match wins; always end with a catch-all deny all.
- satisfy all requires every access condition to pass; satisfy any lets a single passing condition through, e.g., trusted IPs bypassing password prompts.
- auth_basic combined with auth_basic_user_file adds HTTP Basic Authentication to any location block.
- The geo and map modules let you scale IP-based restrictions to country- or CIDR-block-level policies without maintaining huge allow lists.
- IP allow/deny should not be relied on alone for sensitive endpoints since IPs can be spoofed or shared via NAT.
- htpasswd files must be generated with the htpasswd utility and kept outside the web root to avoid accidental exposure.
- Access restrictions defined at the location level do not automatically nest into deeper nested locations unless explicitly repeated or inherited by design.
Practice what you learned
1. In Nginx's allow/deny directive processing, which rule takes precedence when multiple rules could match a request?
2. What does 'satisfy any' allow that 'satisfy all' does not?
3. Which directive specifies the file containing hashed credentials for HTTP Basic Authentication?
4. Why is IP-based access control alone considered insufficient for protecting sensitive endpoints?
5. What is the purpose of the geo module in access control configurations?
Was this page helpful?
You May Also Like
Nginx Security Headers
Learn how to configure HTTP response headers in Nginx to protect users from clickjacking, MIME-sniffing, XSS, and insecure transport.
Nginx Hardening Checklist
A practical, prioritized checklist for locking down a production Nginx deployment, from TLS configuration to information disclosure and module minimization.
Mitigating DDoS with Nginx
Use Nginx's rate limiting, connection limiting, and buffering controls as a first line of defense against volumetric and application-layer DDoS attacks.
Related Reading
Related Study Notes in DevOps
Browse all study notesAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics