Restricting Access with nginx-proxy: Basic Auth and IP Allowlists

nginx-proxy can do basic authentication and access limiting

* This page contains promotional content

This article is a note on access restriction using Docker’s jwilder/nginx-proxy.
Incidentally, this is information that is also written in the official documentation

Basic authentication

  1. Create a .htpasswd folder inside the nginx-proxy folder
  2. Create a file named after the domain, in htpasswd format, under the .htpasswd folder
  3. Set .hpasswd as a volume in docker-compose.yml

.htpasswd

In the .htpasswd folder, create a file in htpasswd format named after the custom domain you want to protect with basic authentication

htpasswd -c password-file-name user-name

$ pwd
nginx-proxy
$ mkdir .htpasswd; cd $_
$ htpasswd -c hoge.example.com foo

docker-compose.yml

Set volumes on the nginx-proxy container (.htpasswd)

Below is only a partial excerpt

version: "2"
services:
  proxy:
    image: jwilder/nginx-proxy
    container_name: proxy
    volumes:
      - ./htpasswd:/etc/nginx/htpasswd

With this, when you connect to hoge.example.com you are asked for basic authentication, and you can connect with the user name (foo) and the password you set

Access restriction by IP

docker-compose.yml

Set the IP restriction file on the nginx-proxy container (network_internal.com)

Below is only a partial excerpt

version: "2"
services:
  proxy:
    image: jwilder/nginx-proxy
    container_name: proxy
    volumes:
      - ./network_internal.conf:/etc/nginx/network_internal.conf

network_internal.conf

Write out the networks whose IPs you want to allow, and create the file

allow 127.0.0.0/8;
allow 192.168.0.0/16;
allow 172.16.0.0/12;

deny all;

Applying it to a Docker container name

Applying nginx-proxy’s access restriction assumes that the container shares a network with nginx-proxy

Write it into the environment of the container you want the IP access restriction on

Only a partial excerpt

services:
  app:
    environment:
      - NETWORK_ACCESS=internal

When accessing the app container, the access restriction configured in network_internal.conf is applied.

If you only connect from specific places such as home or work, IP restriction is the way to go, and if you connect from unspecified places such as while you are out, basic authentication makes it quite safe, but applying both raises security even further.

Incidentally, on servers that look likely to be used as a stepping stone, such as the RSS-Bridge mentioned earlier, I have IP restriction enabled