Comment ajouter une authentification de base HTTP à une entrée Kubernetes NGINX

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éation d’un fichier HTPasswd

Assurez-vous d’avoir un htpasswd disponible avant de vous attaquer à la configuration Kubernetes. Vous pouvez créer un nouvel utilisateur unique htpasswd 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

Références d’entrée NGINX htpasswd fichiers en tant que secrets Kubernetes. Le contenu du fichier doit être stocké dans le auth clé d’un Opaque secret. Kubernetes dispose également d’un basic-auth type secret, mais cela ne convient pas à l’entrée NGINX.

Créez un nouveau manifeste secret et appliquez-le à votre cluster avec Kubectl :

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: htpasswd
data:
  auth: <base64-encoded htpasswd file>

Ajoutez votre encodé en base64 htpasswd fichier comme valeur du auth clé.

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 le auth-type annotation et fournissez une référence à votre secret.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: htpasswd
    nginx.ingress.kubernetes.io/auth-realm: "Enter your credentials"
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 Ingress. Les basic le type d’authentification est utilisé avec les informations d’identification du htpasswd secret créé plus tôt. Les auth-realm annotation 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. Saisissez le nom d’utilisateur et le mot de passe fournis au htpasswd commande pour vous authentifier.

Forme secrète alternative

Le secret montré ci-dessus utilise le auth-file format. Cela signifie qu’il a un auth champ contenant la sortie codée en base64 du htpasswd commander.

NGINX Ingress prend également en charge une autre forme appelée auth-map. Dans cette variante, le 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-encoded password hash from htpasswd>
  user2: <base64-encoded password hash from htpasswd>

Ajoutez vos noms d’utilisateur au fichier, puis utilisez htpasswd pour générer des informations d’identification hachées. Inspectez le htpasswd sortir; il aura le format suivant :

username:<hashed password>

Prenez la partie mot de passe, encodez-la avec le base64 commande, puis ajoutez le résultat à votre secret Kubernetes.

NGINX acceptera les connexions à partir de toute 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.

Les nginx.ingress.kubernetes.io/auth-url annotation 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 200 OK code d’état. 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 le nginx.ingress.kubernetes.io/auth-signin URL. Celui-ci recevra l’URL d’origine à rediriger arrière après une tentative d’authentification réussie en tant que paramètre d’URL défini avec le auth-signin-redirect-param annotation.

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 en contact avec la plate-forme externe si un utilisateur fait plusieurs requêtes à votre service dans un court laps de temps.

Sommaire

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 l’entrée NGINX en fournissant des informations d’identification dans un secret Kubernetes et en définissant des annotations sur vos ressources d’entrée. 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.