Listes d'accès et mode maintenance

Les Access Lists et le mode maintenance répondent à deux questions de gestion : qui peut atteindre le service, et si le service doit accepter le trafic des clients pendant une intervention planifiée. Utilisez-les comme des contrôles explicites et auditables plutôt que des modifications DNS temporaires, des Routes supprimées ou des exceptions de pare-feu non documentées.

Bien utilisés, ils permettent aux clients autorisés de conserver l’accès, bloquent systématiquement les clients refusés, et la maintenance renvoie un 503 délibéré pendant que le nom d’hôte, TLS et la configuration de la Route restent en place.

Les listes d’accès combinent des règles IP et, en option, une authentification HTTP basique. Appliquez la liste la plus restreinte qui répond au besoin et testez à la fois un client autorisé et un client refusé. Traitez les secrets d’authentification basique stockés comme des identifiants et faites-les tourner lorsque la liste des membres change. Supprimer une liste, ou désactiver son authentification basique, retire son fichier de mots de passe de chaque nœud Ingress connecté, et la synchronisation complète d’un nœud après sa reconnexion retire les fichiers de mots de passe qu’aucune configuration n’utilise plus.

Les Access Lists se trouvent sur la page Routes, dans l’onglet Access Lists.

Le mode maintenance est disponible pour les Routes gérées activées qui n’utilisent pas de configuration brute. Il préserve l’hôte virtuel HTTP/HTTPS, renvoie HTTP 503, suspend les vérifications de santé gérées et expose l’état de maintenance aux alertes et aux pages de statut.

Utilisez le mode maintenance pour les interventions délibérées visibles par les clients. Ne simulez pas une maintenance en supprimant une Route, en désactivant TLS ou en pointant vers un upstream factice ; ces actions détruisent un état utile et compliquent la reprise.

Avant de quitter le mode maintenance, vérifiez que l’upstream est sain, que les migrations sont terminées et que les bases de données ou Secure Links dépendants sont prêts.

Processus des listes d’accès

1. Définissez le plus petit ensemble de règles d’autorisation ou de refus qui représente le public visé.
2. N’ajoutez l’authentification HTTP basique que si le client peut protéger l’identifiant et le faire tourner.
3. Rattachez d’abord la liste à une Route de test ou à un nom d’hôte à faible risque.
4. Vérifiez une adresse autorisée et une adresse refusée depuis l’extérieur de l’hôte nginx.
5. Examinez les journaux d’accès nginx pour confirmer que la décision provient de la politique prévue.
6. Ne rattachez la politique à d’autres Routes qu’une fois le test concluant.

Modifier une Access List réutilisable affecte chaque Route rattachée. Avant de modifier une politique partagée, examinez ses relations et créez une liste distincte lorsqu’une application a besoin d’une frontière différente.

Entrer en maintenance en toute sécurité

Avant d’activer le mode maintenance :

• vérifiez que la Route est gérée et activée ;
• consignez l’état de santé actuel et le déploiement actif ;
• publiez un incident sur la page de statut lorsque les clients sont susceptibles de s’en apercevoir ;
• assurez-vous que les opérateurs conservent un chemin d’administration qui n’est pas bloqué par la Route de l’application ;
• décidez quelle vérification prouve que l’intervention de maintenance est terminée.

Une Route qui appartient à une app peut aussi être mise en maintenance par son environnement ou par l’app entière. Cette maintenance s’ajoute à l’interrupteur propre à la Route, qui conserve sa valeur et s’applique à nouveau lorsque la maintenance de l’environnement ou de l’app prend fin ; la page de la Route indique d’où provient sa maintenance. Un code d’accès de maintenance émis pour un environnement ou pour l’app ouvre une fois chacune de ses Routes en maintenance.

Opfield conserve l’hôte virtuel et le comportement TLS tout en renvoyant 503. La supervision et la communication avec les clients restent ainsi explicites, sans agitation du DNS ou des certificats.

Sortir et vérifier

1. Vérifiez l’upstream directement ou via sa vérification de santé gérée.
2. Confirmez que les liaisons de bases de données, les migrations et les services dépendants sont prêts.
3. Désactivez le mode maintenance.
4. Effectuez une requête externe sur le nom d’hôte canonique.
5. Vérifiez le code de réponse, le corps attendu, TLS, les redirections et le comportement WebSocket le cas échéant.
6. Ne clôturez l’incident sur la page de statut qu’une fois la vérification externe réussie.

Si la Route reste indisponible, réactivez la maintenance plutôt que de basculer à répétition des paramètres sans rapport. Utilisez Dépannage de l’ingress pour identifier la couche en échec.

Évaluation des politiques et sécurité des modifications

Documentez si la liste est destinée à restreindre une surface d’administration, un point de terminaison client privé ou toute une application publique. Des règles mêlant autorisations et refus sont faciles à mal interpréter pendant un incident ; gardez donc la politique courte et nommez-la d’après le public qu’elle protège. Testez l’adresse client effective vue par nginx, en particulier lorsque les requêtes passent par un CDN ou un autre proxy de confiance ; tester uniquement l’adresse apparente du navigateur peut valider la mauvaise règle.

L’authentification basique complète la politique réseau, mais ne remplace pas TLS. Ne l’utilisez que sur des Routes HTTPS, stockez l’identifiant généré via le chemin de secrets pris en charge et transmettez-le en dehors des journaux applicatifs ou des tickets. Retirer un utilisateur d’un identifiant partagé exige de faire tourner cet identifiant pour tous les utilisateurs restants ; utilisez des listes distinctes lorsqu’une révocation indépendante est importante.

Avant de modifier une Access List partagée, consignez chaque Route rattachée et le comportement actuel pour une requête autorisée et une requête refusée. Effectuez la modification une seule fois, attendez l’acquittement de nginx et répétez les deux tests. Si la validation ou l’application échoue, conservez la dernière politique acquittée et corrigez la nouvelle révision plutôt que de détacher le contrôle d’accès des Routes de production.

Reprise d’urgence

Une Access List peut empêcher les opérateurs d’accéder à une application, mais elle ne doit pas bloquer le chemin d’administration d’Opfield, sauf si ce chemin a été délibérément placé derrière la même politique. Si tous les clients attendus sont refusés, vérifiez l’adresse source observée dans les journaux d’accès et la configuration des proxys de confiance avant d’élargir la plage autorisée.

Lorsqu’un rétablissement immédiat du service est nécessaire, restaurez la liste précédente réputée saine ou rattachez une liste d’urgence étroitement délimitée, avec une durée de vie opérationnelle courte. Ne la remplacez pas par un accès public sans restriction, sauf si le responsable de l’incident accepte explicitement cette exposition. Après la reprise, retirez les règles temporaires, faites tourner les identifiants d’urgence et vérifiez chaque Route qui partageait la liste d’origine.