NGINX Ingress est un contrôleur d'entrée Kubernetes populaire pour acheminer le trafic vers votre cluster. Une ressource Ingress standard vous permet de mapper les requêtes HTTP à vos services Kubernetes. Voici comment protéger vos routes avec l'authentification de base HTTP.
Créer un fichier HTPasswd
Assurez-vous’ Vous disposez d'un fichier htpasswd avant de vous attaquer à la configuration de Kubernetes. Vous pouvez créer un nouveau htpasswd mono-utilisateur dans votre terminal :
apt install apache2-utils htpasswd -c auth example-user
Vous serez invité à saisir le mot de passe. Un nouveau fichier appelé auth sera créé dans votre répertoire de travail.
Ensuite, vous devez encoder en base64 votre chaîne d'informations d'identification afin qu'elle puisse être utilisée comme valeur dans un secret Kubernetes :
cat auth | base64
Copiez la chaîne encodée en base64 dans votre presse-papiers. Nous l'utiliserons dans la section suivante pour créer un secret Kubernetes contenant vos informations d'identification.
Ajouter un secret Kubernetes
NGINX Ingress référence les fichiers htpasswd en tant que secrets Kubernetes. Le contenu du fichier doit être stocké dans la clé d'authentification d'un secret Opaque. Kubernetes dispose également d'un type de secret d'authentification de base intégré, mais cela ne convient pas à l'entrée NGINX.
Publicité
Créez un nouveau manifeste secret et appliquez-le à votre cluster avec Kubectl :< /p> apiVersion : v1 kind : Type de secret : Opaque métadonnées : nom : htpasswd data : auth : <base64-encoded htpasswd file>
Ajoutez votre fichier htpasswd encodé en base64 comme valeur de la clé d'authentification.
Modification de votre entrée
NGINX Ingress prend en charge plusieurs annotations personnalisées qui vous permettent d'associer un comportement supplémentaire à vos ressources Ingress. Pour utiliser l'authentification de base HTTP, vous devez définir l'annotation de type auth et fournir une référence à votre secret.
apiVersion : networking.k8s.io/v1beta1 genre : Métadonnées d'entrée : nom : example-ingress annotations : nginx.ingress.kubernetes.io/auth-type : basic nginx.ingress.kubernetes.io/auth-secret : htpasswd nginx.ingress .kubernetes.io/auth-realm : "Entrez vos informations d'identification" spec: rules: – host: example.com http: paths: – path:/backend: serviceName: example-service servicePort: 80
Les trois annotations configurent NGINX pour exiger une authentification sur chaque demande qui correspond à votre Ressource d'entrée. Le type d'authentification de base est utilisé avec les informations d'identification du secret htpasswd créé précédemment. L'annotation auth-realm définit le message affiché aux utilisateurs lorsqu'ils sont invités à saisir leurs informations d'identification.
Les requêtes correspondant à cette entrée nécessiteront désormais que l'utilisateur se connecte avant de continuer. Le défi d'authentification s'affiche sous forme de boîte de dialogue contextuelle dans la plupart des navigateurs Web. Entrez le nom d'utilisateur et le mot de passe fournis à la commande htpasswd pour vous authentifier.
Forme secrète alternative
Le secret indiqué ci-dessus utilise le format de fichier auth . Cela signifie qu'il dispose d'un champ d'authentification contenant une sortie codée en base64 de la commande htpasswd.
Publicité
NGINX Ingress prend également en charge une autre forme appelée auth-map. Dans cette variante, le champ auth est remplacé par un ensemble de clés qui fournissent chacune le mot de passe d'un utilisateur individuel.
apiVersion : v1 kind : Secret type : Opaque metadata : name : htpasswd data : user1 : <base64- hachage de mot de passe codé de htpasswd> user2 : <hachage de mot de passe codé en base64 à partir de htpasswd>
Ajoutez vos noms d'utilisateur au fichier, puis utilisez htpasswd pour générer des informations d'identification hachées. Inspectez la sortie htpasswd ; il aura le format suivant :
nom d'utilisateur :<mot de passe haché>
Prenez la partie mot de passe, encodez-la avec la commande base64, puis ajoutez le résultat à votre secret Kubernetes.
NGINX acceptera les connexions à partir de n'importe quelle combinaison valide de nom d'utilisateur et de mot de passe définie dans le secret. Cette approche peut faciliter la configuration de plusieurs comptes d'utilisateurs et vous aide à voir exactement qui a accès.
Authentification plus avancée
NGINX Ingress peut s'intégrer à des fournisseurs d'authentification externes si vous avez besoin de plus de contrôle mais que vous souhaitez une expérience de configuration tout aussi simple. L'utilisation d'un fournisseur d'authentification externe redirige les utilisateurs vers ce site avant qu'ils ne puissent accéder au service derrière votre entrée. Cela vous permet d'appliquer une routine d'authentification complète sans toucher à votre code backend.
Publicité
L'annotation nginx.ingress.kubernetes.io/auth-url définit l'URL d'un service d'authentification externe à utiliser. Kubernetes transmettra chaque requête entrante au service. L'accès ne sera accordé à l'utilisateur que lorsque le service renvoie un code d'état 200 OK. Le flux normal se poursuit ensuite avec la demande dans votre service Kubernetes.
Lorsque le service d'authentification indique une erreur, les utilisateurs seront redirigés vers la page indiquée par nginx.ingress.kubernetes.io/auth-signin URL. Celui-ci recevra l'URL d'origine vers laquelle rediriger après une tentative d'authentification réussie en tant que paramètre d'URL défini avec l'annotation auth-signin-redirect-param.
Plusieurs autres annotations vous permettent de modifier le comportement de NGINX lors de la communication avec la plate-forme d'authentification. Vous pouvez modifier la méthode HTTP utilisée pour effectuer des demandes d'authentification, ajouter des en-têtes supplémentaires et configurer la mise en cache des réponses d'authentification. Ce dernier garantit que vous n'êtes pas continuellement sur la plate-forme externe si un utilisateur fait plusieurs requêtes à votre service dans un court laps de temps.
Résumé
L'authentification de base HTTP est le moyen le plus simple de protéger un site Web. Il est idéal pour les systèmes internes et les sites de transfert où vous travaillez avec une petite liste d'utilisateurs et n'avez pas besoin d'une gestion centralisée des informations d'identification.
Utilisez l'authentification de base avec NGINX Ingress en fournir des informations d'identification dans un secret Kubernetes et définir des annotations sur vos ressources Ingress. Dans un cas d'utilisation réel, vous ne devriez pas coder en dur les informations d'identification dans vos manifestes Kubernetes. Utilisez soit Helm, soit un système CI/CD pour fournir des valeurs en toute sécurité au moment où vous appliquez les ressources à votre cluster.