Le répartiteur NGINX devant un palier applicatif est un endroit naturel pour appliquer des contrôles d’accès de base — authentification HTTP, autoriser/refuser par IP, ou les deux. Cette page couvre les deux mécanismes et montre comment les combiner avec la directive satisfy.
Un répartiteur est ajouté à la topologie automatiquement quand vous mettez à l’échelle un palier applicatif. Vous pouvez aussi en ajouter un manuellement devant un seul serveur applicatif depuis le bloc Balancing de l’assistant de topologie.
Authentification HTTP basique
Verrouillez l’application derrière une invite identifiant/mot de passe sur le répartiteur.
1. Générer le hash du mot de passe
NGINX attend des mots de passe stockés sous forme de hash bcrypt ou APR1 dans un fichier .htpasswd. Depuis un shell local :
htpasswd -c password.htpasswd alice
Copiez la ligne obtenue (de la forme alice:$apr1$...).
2. Placer le fichier htpasswd sur le répartiteur
Dans le tableau de bord, cliquez sur Config sur le nœud répartiteur NGINX et créez un nouveau fichier dans /etc/nginx/conf.d/ nommé password.htpasswd (l’extension est requise). Collez le hash. Ajoutez un compte par ligne si vous en voulez plusieurs.
Enregistrez le fichier.
3. Activer l’auth dans le bloc serveur
Ouvrez /etc/nginx/nginx-jelastic.conf, trouvez le bloc location dans la première section server, et ajoutez :
auth_basic "closed site";
auth_basic_user_file /etc/nginx/conf.d/password.htpasswd;
Enregistrez et redémarrez le nœud répartiteur. La prochaine requête navigateur recevra une invite de credentials.
Le motif recommandé est de surcharger les directives dans
nginx.confplutôt que d’éditer lenginx-jelastic.confauto-généré. Pour quelque chose d’aussi petit et autonome, éditernginx-jelastic.confune fois est acceptable — mais si vous faites de nombreux changements, suivez le motif de surcharge du document configuration du répartiteur.
Autoriser / refuser par IP
Bloquer les requêtes d’une IP spécifique — ou autoriser un petit ensemble d’IP et refuser tout le reste.
Refuser une IP unique
Dans le même bloc location, ajoutez :
deny 198.51.100.42;
Le client à cette adresse recevra un 403. Remplacez l’adresse par all pour refuser toutes les requêtes, puis ajoutez des directives allow explicites pour autoriser un petit ensemble :
allow 203.0.113.0/24;
deny all;
Redémarrez le répartiteur pour appliquer.
Derrière un autre proxy
Si le répartiteur est derrière le Shared Load Balancer ou un autre proxy en amont, l’adresse réelle du client est dans X-Forwarded-For, pas dans l’IP source de la connexion. Une construction qui filtre sur l’entête fonctionne dans ce cas :
if ($http_x_forwarded_for ~* 198.51.100.42) {
return 403;
}
C’est un repli — préférez les modules real_ip quand vous le pouvez.
Combiner auth et règles d’IP
Par défaut, avec à la fois auth_basic et allow/deny déclarés, un client doit passer les deux vérifications. Pour passer avec l’une ou l’autre, mettez satisfy à any :
satisfy any;
allow 203.0.113.0/24;
deny all;
auth_basic "closed site";
auth_basic_user_file /etc/nginx/conf.d/password.htpasswd;
L’effet : une requête d’une IP autorisée passe sans credentials ; une requête d’une IP bloquée peut quand même passer si elle présente des credentials valides.
C’est utile pour des environnements de préproduction où vous voulez laisser entrer votre réseau de bureau de manière transparente tout en autorisant les ingénieurs distants par mot de passe.