AKS avec plusieurs contrôleurs d'entrée nginx, certificats Application Gateway et Key Vault (2023)

Introduction

Dans learticle de blog précédentnous avons créé un cluster AKS avec un contrôleur d'entrée nginx et des certificats récupérés à partir d'Azure Key Vault.

Pour cet article de blog, nous allons étendre cette configuration précédente et inclure ;

1. Déployer le DNS privé Azure
2. Déployez deux contrôleurs d'entrée nginx s'exécutant dans le cluster (un pour le trafic interne, l'autre pour le trafic public. Les deux avec des adresses IP internes)
3. Déployez une passerelle d'application comme point d'entrée pour le trafic public, qui sera intégrée à Key Vault et effectuera la terminaison SSL

Pour suivre ce billet de blog, vous devez disposer d'un cluster AKS et des composants décrits dans lepost précédentinstallée

1. DNS privé Azure

Créer une ressource DNS privé Azure

#Configurez certaines variables que nous allons utiliser tout au long des scriptsexporterSUBSCRIPTION_ID=""exporterLOCATAIRE_ID=""exporterRESOURCE_GROUP=""exporterCLUSTER_NAME=""exporterRÉGION="Europe de l'ouest"exporterNODE_RESOURCE_GROUP="MC_${RESOURCE_GROUP}_${CLUSTER_NAME}_${RÉGION}"exporterIDENTITY_NAME="votre identité" #Doit être en minusculeexporterKEYVAULT_NAME=""exporterDNS_ZONE="private.contoso.com"exporterPUBLIC_DNS_ZONE="public.contoso.com"az réseau privé-dns zone créer -g${RESOURCE_GROUP}-n${DNS_ZONE}az réseau privé-dns zone créer -g${RESOURCE_GROUP}-n${PUBLIC_DNS_ZONE}

Liez la zone DNS privée au réseau virtuel AKS (Vnet créé par AKS). Cela permettra aux ressources de ce réseau virtuel de résoudre le nom DNS.

Vous pouvez obtenir l'ID de ressource AKS Vnet en accédant au groupe de ressources de nœud créé par AKS, la convention de dénomination estMC___. Cliquez sur la ressource de réseau virtuel et copiez l'ID de ressource de réseau virtuel à partir des propriétés.

az réseau privé-dns lien vnetcréer-g ${RESOURCE_GROUP} -n MyDNSLink -z ${DNS_ZONE} -v Ressource IDENTIFIANT> -evrai#register public dns zone - cette fois, l'enregistrement automatique est faux car un seul lien peut être vrai dans le même vnetle réseauprivé-dnslienzélécréer-g ${RESOURCE_GROUP} -n MyDNSLink -z ${PUBLIC_DNS_ZONE} -v Ressource IDENTIFIANT> -eFAUX

Lorsque vous avez terminé, vous pouvez vérifier que le lien a été créé dans la zone DNS privée

2. contrôleur d'entrée nginx

Commençons par créer un nouveau certificat et importons-le dans Key Vault. L'autre certificat pour la DNS_ZONE a été créé dans lepost précédent

exporterCERT_NAME=publicingresscertopenssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -out ingress-tls.crt \ -keyout ingress-tls.key \ -subj"/CN=${PUBLIC_DNS_ZONE}"openssl pkcs12 -exporter-dansingress-tls.crt -inkey ingress-tls.key -out$CERT_NAME.pfx# ignorer l'invite de mot de passeimportation de certificat az keyvault --vault-name${KEYVAULT_NAME}-n$CERT_NAME-F$CERT_NAME.pfx

Si vous continuez à partir duDernier commentairevous devriez avoir deux certificats, avec l'ajout du nouveaupublicingresscert

Dans cet article, je ne créerai pas de nouvelles identités et réutiliserai la même identité créée dansle dernier message

Maintenant, configurons les contrôleurs d'entrée. Pour pouvoir exécuter plusieurs contrôleurs d'entrée, vous devez configurer leclasse d'entréeet ajoutez l'annotation correcte à l'entrée pour la mapper au bon contrôleur d'entrée.Plus d'informations

Installez ou mettez à niveau la version helm (si vous continuez depuis le post précédent)

#internecontrôleur d'entrée -ensembleentréeclasse=nginx-internehelm installer nginx-ingress-interneentrée-nginx/entrée-nginx \ --ensemblecontroller.replicaCount=2\ --ensemblecontroller.ingressClass=nginx-interne\ --ensemblecontroller.podLabels.aadpodidbinding=${IDENTITY_NAME} \ -f - <interne:"vrai"extraVolumes : - nom : secrets-store-en lignecsi : pilote : secrets-store.csi.k8s.io readOnly :vraivolumeAttributs : secretProviderClass :"entrée-tls"#nom de la SecretProviderClass que nous avons créée ci-dessus extraVolumeMounts : - nom : secrets-store-en lignemountPath :"/mnt/secrets-store"lecture seulement:vrai#EOFexternecontrôleur d'entrée -ensembleentréeclasse=nginx-externehelm installer nginx-ingress-externeentrée-nginx/entrée-nginx \ --ensemblecontroller.replicaCount=2\ --ensemblecontroller.ingressClass=nginx-externe\ --ensemblecontroller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-interne"=vrai

Comme vous pouvez le voir dans les scripts, chaque contrôleur d'entrée a unclasse d'entréeet l'annotation pour l'équilibreur de charge interne définie.

Une fois l'installation réussie, vous aurez 4 nouveaux pods, deux pour l'entrée interne et deux pour l'entrée externe car nous avons défini 2 réplicas.

Il y a aussi 2 nouveaux services avec ips internes de la gamme de votre réseau virtuel.

Maintenant, créons les deux entrées, souvenez-vous duclasse d'entréeavons-nous défini pour chaque contrôleur d'entrée ? Il est maintenant temps d'utiliser cette propriété.

#déployez la deuxième application de démonstrationkubectl appliquer -F https://raw.githubusercontent.com/hjgraca/playground/master/k8s/nginx/secondapp.yaml#entrée internechat < | kubectl appliquer -F -apiVersion : réseautage.k8s.io/v1beta1type: Entréemétadonnées : annotations : kubernetes.io/ingress.class : nginx-interne nom: entrée interne espace de noms : défautspécification : tl : - hôtes : - $DNS_ZONE nomsecret : entrée-tls-csi # le secret qui a été créé par le fournisseur du magasin de secrets et attribué au contrôleur d'entrée règles: - héberger: $DNS_ZONE http : chemins : - back-end : Nom du service: première application ServicePort : 80 chemin: /EOF#entrée externe, sans TLS, le TLS est pris en charge par Application Gatewaychat < | kubectl appliquer -F -apiVersion : réseautage.k8s.io/v1beta1type: Entréemétadonnées : annotations : kubernetes.io/ingress.class : nginx-externe nom: entrée externe espace de noms : défautspécification : règles: - héberger: $PUBLIC_DNS_ZONE http : chemins : - back-end : Nom du service: deuxièmeapplication ServicePort : 80 chemin: /EOF

Une fois installé, nous pouvons obtenir les entrées, la liste affichera les hôtes et l'adresse IP de liaison, si vous décrivez l'une des entrées, vous pouvez voir à quel service et à quels pods il est attaché.

J'ai trouvé qu'il valait mieux attendre qu'un contrôleur d'entrée soit complètement installé et ensuite seulement passer au suivant.

Testons les terminaux

Tout d'abord, ajoutons ces adresses IP aux zones DNS privées que nous avons créées précédemment

le réseauprivé-enregistrement DNS-définir un ajout-enregistrer-g ${RESOURCE_GROUP}-z ${DNS_ZONE}-n @-un<IPadressedeinterneentrée>le réseauprivé-enregistrement DNS-définir un ajout-enregistrer-g ${RESOURCE_GROUP}-z ${PUBLIC_DNS_ZONE}-n @-un<IPadressedeexterneentrée>

Ces scripts créeront des enregistrements A pour le domaine dans les zones DNS privées

Puisque nous utilisons des adresses IP internes, la seule façon de résoudre ces adresses IP est à partir de ce réseau virtuel, vpn, bastion. Je vais pour l'option la plus simple d'exécuter un pod à l'intérieur du cluster.

#exécuter un pod avec une image de boîte occupée modifiée avec curlkubectl run -it --rm jumpbox-pod --image=radial/busyboxplus:curl#lorsque dans l'invite, nous pouvons maintenant boucler nos points de terminaison privés#public -> entrée externe -> non TLS -> renvoie secondappcurl http://public.contoso.com#private -> entrée interne -> TLS -> renvoie firstappcurl -v -k https ://privé.contoso.com

Désormais, les consommateurs internes peuvent accéder à notre point de terminaison protégé par TLS en utilisanthttps://private.contoso.comtant qu'ils se trouvent dans le même réseau virtuel, pour d'autres modes de résolution, comme la résolution à partir de locaux, vous aurez besoin d'un redirecteur DNS s'exécutant dans Azure qui transmettra les requêtes DNS au DNS Azure.

En ce qui concerne les consommateurs externes, nous voulons protéger ce point de terminaison en utilisantPasserelle d'applications.

3. Azure Application Gateway pour exposer le service

Pour créer une passerelle d'application, nous avons d'abord besoin d'une infrastructure pour être présente.

#créez d'abord un sous-réseau dans le réseau virtuel AKS existantaz réseau vnet sous-réseaucréer\--name AppGwSubnet \ --resource-group ${NODE_RESOURCE_GROUP} \ --vnet-name  \ --address-prefix 10.0.2.0/27# Maintenant, créons l'adresse IP publique qui servira les demandes publiquesle réseaupublic-ipcréer\--resource-group ${RESOURCE_GROUP} \ --name monAGPublicIPAddress \ --allocation-method Statique \ --sku Norme

Résultats dans 2 sous-réseaux

Et une adresse IP publique dans votre groupe de ressources

Créons maintenant Application Gateway (clause de non-responsabilité; puisque je n'ai pas créé de vnet dans le groupe de ressources où se trouve l'AKS, je devrai déployer sur le groupe de ressources de nœud)

exporter APPGW_NAME="myAppGateway"#créer une passerelle d'applicationpasserelle d'application réseau azcréer\--name ${APPGW_NAME} \ --location ${REGION} \ --resource-group ${NODE_RESOURCE_GROUP} \ --capacité 1 \ --sku Standard_v2 \ --public-ip-address monAGPublicIPAddress \ --vnet-name  \ --subnet AppGwSubnet#ajouter l'adresse IP du pool principal de notre entréepool d'adresses de passerelle d'application réseau azcréer-g ${NODE_RESOURCE_GROUP}--gateway-name ${APPGW_NAME} -n AKSAddressPool --servers # Opération unique, attribuez l'identité à Application Gateway afin que nous puissions accéder au coffre de cléspasserelle d'application réseau azidentitéattribuer \--gateway-name ${APPGW_NAME} \ --resource-group ${NODE_RESOURCE_GROUP} \ --identité ${IDENTITY_RESOURCE_ID}#get secret-id de votre certificat depuis keyvaultversionedSecretId=$(certificat az keyvaultmontrer-n publicingresscert--vault-name $KEYVAULT_NAME --query "sid" -o tsv)unversionedSecretId=$(echo $versionedSecretId | cut -d'/'-F-5)# supprimer la version de l'url#ajouter le certificat SSL à la passerelle d'applicationaz network application-gateway ssl-certcréer\--resource-group ${NODE_RESOURCE_GROUP} \ --gateway-name ${APPGW_NAME} \-n MonCertificatSSLC \--key-vault-secret-id $unversionedSecretId#créer un nouveau port pour HTTPSaz network application-gateway frontend-portcréer\--port 443 \ --gateway-name ${APPGW_NAME} \ --resource-group ${NODE_RESOURCE_GROUP} \ --nom port443#créer un HTTP-LISTENER pour HTTPS qui utilise votre certificat#c'est votre point d'entréepasserelle d'application réseau azhttp-auditeurcréer-g ${NODE_RESOURCE_GROUP}--gateway-name ${APPGW_NAME} \ --frontend-port port443 -n https --frontend-ip appGatewayFrontendIP --ssl-cert MySSLCert --host-name ${PUBLIC_DNS_ZONE}#créer une règle pour mapper l'écouteur http au pool principalrègle de passerelle d'application réseau azcréer\--gateway-name ${APPGW_NAME} \ --name règle2 \ --resource-group ${NODE_RESOURCE_GROUP} \ --http-auditeur https \ --address-pool AKSAddressPool# créer une sonde personnalisée avec le nom d'hôte spécifiésonde de passerelle d'application réseau azcréer-g ${NODE_RESOURCE_GROUP}--gateway-name ${APPGW_NAME} \-n MaSonde--protocol http --host ${PUBLIC_DNS_ZONE} --path /# mettre à jour les paramètres http pour utiliser la nouvelle sondepasserelle d'application réseau azhttp-paramètres mise à jour --enable-probe true --gateway-name ${APPGW_NAME} --name appGatewayBackendHttpSettings --probe MyProbe --resource-group ${NODE_RESOURCE_GROUP}

Après avoir déployé et configuré Application Gateway, nous pouvons maintenant tester notre point de terminaison public, car ce n'est pas un domaine que je possède, nous devrons utiliser curl ou modifier le fichier hosts local.

#curl le point de terminaison public résout l'adresse IP et valide les certificatsboucle -v -k --résoudre $PUBLIC_DNS_ZONE:443:20..***** https://$PUBLIC_DNS_ZONE#la réponse* Certificat serveur :* sujet: CN=public.contoso.com* date de début: Nov 30 21:05:33 2020GMT* date d'expiration: Nov 30 21:05:33 2021GMT* émetteur : CN=public.contoso.com* Résultat de la vérification du certificat SSL : soi signé certificat (18), continuer de toute façon.#et le second app html est retourné

Nous l'avons fait!

Qu'avons-nous fait?

• Déployé deux contrôleurs d'entrée dans notre cluster, l'un pour le trafic interne l'autre pour le trafic public ; le scénario est lorsque vous souhaitez séparer vos charges de travail pour différents publics
• Déployé une entrée avec TLS, le certificat a été stocké dans Key Vault et nous avons pu attribuer ce secret à notre entrée en utilisantIdentité du pod AADetFournisseur de magasin secret CSI
• Déploiement d'une autre entrée sans TLS mais toujours équilibreur de charge interne
• Déployé une passerelle d'application Azure qui effectue le déchargement TLS et obtient le certificat de Key Vault, elle utilise la même identité gérée attribuée par l'utilisateur que celle que nous avons utilisée pour l'identité du pod AAD pour accéder à Key Vault
• Une zone DNS privée afin que nous puissions résoudre les noms DNS de notre réseau virtuel

Remarques finales

• Il est plus facile/recommandé de déployer Application Gateway à l'aide d'ARM ou de Terraform
• Si vous souhaitez ajouter automatiquement vos zones DNS privées en fonction des entrées Kubernetes, vous pouvez utiliser un outil tel queDNS externe

Avez-vous trouvé cet article précieux?

SoutienHenrique Graceen devenant parrain. Tout montant est apprécié!