Partager via


Support du proxy HTTP dans le service Azure Kubernetes (AKS)

Dans cet article, vous découvrez comment configurer des clusters Azure Kubernetes Service (AKS) afin d’utiliser un proxy HTTP pour l’accès Internet sortant.

Les clusters AKS déployés dans des réseaux virtuels managés ou personnalisés ont certaines dépendances sortantes nécessaires pour fonctionner correctement, ce qui créait des problèmes dans les environnements nécessitant un accès Internet pour le routage via des proxys HTTP. Les nœuds n’avaient aucun moyen de démarrer la configuration, les variables d’environnement et les certificats nécessaires pour accéder aux services Internet.

La fonctionnalité de proxy HTTP ajoute la prise en charge des proxys HTTP aux clusters AKS, exposant une interface simple que vous pouvez utiliser pour sécuriser le trafic réseau dont a besoin AKS dans les environnements dépendant d’un proxy. Avec cette fonctionnalité, les nœuds et les pods AKS sont configurés pour utiliser le proxy HTTP. La fonctionnalité permet également d’installer une autorité de certification approuvée sur les nœuds dans le cadre du démarrage de cluster. Des solutions plus complexes peuvent nécessiter la création d’une chaîne d’approbation pour établir des communications sécurisées sur le réseau.

Limitations et considérations

Les scénarios suivants ne sont pas pris en charge :

  • Configurations de proxy différentes par pool de nœuds
  • Authentification par nom d’utilisateur/mot de passe
  • Autorités de certification personnalisées pour la communication du serveur d’API
  • Clusters AKS avec des pools de nœuds Windows
  • Pools de nœuds utilisant des ensembles de disponibilité de machines virtuelles (VMAS)
  • Utilisation de * comme caractère générique attaché à un suffixe de domaine pour noProxy

httpProxy, httpsProxy et trustedCa n’ont pas de valeur par défaut. Les variables d’environnement suivantes sont injectées dans les pods :

  • HTTP_PROXY
  • http_proxy
  • HTTPS_PROXY
  • https_proxy
  • NO_PROXY
  • no_proxy

Pour désactiver l’injection des variables d’environnement de proxy, vous devez annoter le pod avec "kubernetes.azure.com/no-http-proxy-vars":"true".

Avant de commencer

Créer un fichier config avec des valeurs de proxy HTTP

Créez un fichier et fournissez des valeurs pour httpProxy, httpsProxy et noProxy. Si votre environnement l’exige, fournissez une valeur pour trustedCa.

Le schéma du fichier config est du type suivant :

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}

Passez en revue les conditions requises pour chaque paramètre :

  • httpProxy : URL de proxy à utiliser pour créer des connexions HTTP à l’extérieur du cluster. Le schéma d’URL doit être http.
  • httpsProxy : URL de proxy à utiliser pour créer des connexions HTTPS à l’extérieur du cluster. Si la valeur n’est pas spécifiée, httpProxy est utilisé à la fois pour les connexions HTTP et HTTPS.
  • noProxy : liste des noms de domaine de destination, des domaines, des adresses IP ou d’autres CIDR réseau à exclure de la mise en proxy.
  • trustedCa : Une chaîne contenant le contenu de remplacement du certificat de l'autorité de certification base64 encoded. Actuellement, seul le format PEM est pris en charge.

Important

Dans un souci de compatibilité avec les composants basés sur Go qui font partie du système Kubernetes, le certificat doit prendre en charge Subject Alternative Names(SANs) à la place des certificats de noms communs déconseillés.

Il existe des différences dans les applications sur la façon de se conformer aux variables d’environnement http_proxy, https_proxyet no_proxy. Curl et Python ne prennent pas en charge CIDR dans no_proxy, contrairement à Ruby.

Exemple d’entrée :

{
  "httpProxy": "http://myproxy.server.com:8080", 
  "httpsProxy": "https://myproxy.server.com:8080", 
  "noProxy": [
    "localhost",
    "127.0.0.1"
  ],
  "trustedCA": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUgvVENDQmVXZ0F3SUJB...S0tLS0="
}

Créer un cluster avec une configuration de proxy HTTP en utilisant l’interface Azure CLI

Vous pouvez configurer un cluster AKS avec une configuration de proxy HTTP lorsque vous créez un cluster.

  1. Utilisez la commande az aks create et passez votre configuration en tant que fichier JSON.

    az aks create \
        --name $clusterName \
        --resource-group $resourceGroup \
        --http-proxy-config aks-proxy-config.json \
        --generate-ssh-keys
    

    Votre cluster doit normalement s’initialiser avec le proxy HTTP configuré sur les nœuds.

  2. Vérifiez que la configuration du proxy HTTP se trouve sur les pods et les nœuds en vérifiant que les variables d’environnement contiennent les valeurs appropriées pour http_proxy, https_proxy et no_proxy en tirant parti de la commande kubectl describe pod.

    kubectl describe {any pod} -n kube-system
    

    Pour valider la définition des variables de proxy dans les pods, vous pouvez vérifier les variables d’environnement présentes sur les nœuds.

    kubectl get nodes
    kubectl node-shell {node name}
    cat /etc/environment
    

Mettre à jour une configuration de proxy HTTP

Vous pouvez mettre à jour les configurations de proxy HTTP sur des clusters existants, notamment :

  • Mise à jour d’un cluster existant pour activer le proxy HTTP et ajouter une nouvelle configuration de proxy HTTP.
  • Mise à jour d’un cluster existant pour modifier une configuration de proxy HTTP.

Considérations concernant la mise à jour d’un proxy HTTP

Le --http-proxy-config paramètre doit être défini sur un nouveau fichier JSON avec des valeurs mises à jour pour httpProxy, httpsProxy, noProxyet trustedCa si nécessaire. La mise à jour injecte de nouvelles variables d’environnement dans les pods avec les nouvelles valeurs de httpProxy, httpsProxy ou noProxy. Les pods doivent faire l’objet d’une rotation pour que les applications la détecte, car les valeurs des variables d’environnement sont injectées par un webhook d’admission mutant.

Remarque

Si vous basculez vers un nouveau proxy, celui-ci doit déjà exister pour que la mise à jour réussisse. Une fois la mise à niveau terminée, vous pouvez supprimer l’ancien proxy.

Mettre à jour un cluster pour mettre à jour ou activer le proxy HTTP

  1. Activez ou mettez à jour les configurations de proxy HTTP sur un cluster existant en utilisant la commande az aks update.

    Par exemple, supposons que vous avez créé un fichier avec la chaîne encodée en base64 du nouveau certificat d’autorité de certification appelé aks-proxy-config-2.json. Vous pouvez mettre à jour la configuration du proxy sur votre cluster avec la commande suivante :

    az aks update --name $clusterName --resource-group $resourceGroup --http-proxy-config aks-proxy-config-2.json
    

Avertissement

AKS réinitialise automatiquement tous les pools de nœuds dans le cluster lorsque vous mettez à jour la configuration du proxy sur votre cluster en tirant parti de la commande az aks update. Vous pouvez utiliser des budgets d’interruption de pod (PDB) pour protéger les perturbations des pods critiques lors de la réimage.

  1. Vérifiez que la configuration du proxy HTTP se trouve sur les pods et les nœuds en vérifiant que les variables d’environnement contiennent les valeurs appropriées pour http_proxy, https_proxy et no_proxy en tirant parti de la commande kubectl describe pod.

    kubectl describe {any pod} -n kube-system
    

    Pour valider la définition des variables de proxy dans les pods, vous pouvez vérifier les variables d’environnement présentes sur les nœuds.

    kubectl get nodes
    kubectl node-shell {node name}
    cat /etc/environment
    

Désactiver un proxy HTTP sur un cluster existant (Préversion)

Installer l’extension aks-preview

  1. Installez l’extension aks-preview Azure CLI en utilisant la commande az extension add.

    Important

    Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

    az extension add --name aks-preview
    
  2. Mettez à jour vers la dernière version de l’extension à l’aide de la commande az extension update. La désactivation du proxy HTTP nécessite la version 18.0.0b13 au minimum.

    az extension update --name aks-preview
    

Inscrire l’indicateur de fonctionnalité DisableHTTPProxyPreview

  1. Inscrivez l’indicateur de fonctionnalité DisableHTTPProxyPreview à l’aide de la commande az feature register.

    az feature register --namespace Microsoft.ContainerService --name DisableHTTPProxyPreview
    
  2. Vérifiez l’état de l’inscription en utilisant la commande az feature show. Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

    az feature show --namespace Microsoft.ContainerService --name DisableHTTPProxyPreview
    
  3. Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace Microsoft.ContainerService
    

Mettre à jour le cluster pour désactiver le proxy HTTP (préversion)

  1. Mettez à jour votre cluster pour désactiver le proxy HTTP en tirant parti de la commande az aks update avec l’indicateur --disable-http-proxy.

    az aks update --name $clusterName --resource-group $resourceGroup --disable-http-proxy
    

Avertissement

AKS réinitialise automatiquement tous les pools de nœuds dans le cluster lorsque vous mettez à jour la configuration du proxy sur votre cluster en tirant parti de la commande az aks update. Vous pouvez utiliser des budgets d’interruption de pod (PDB) pour protéger les perturbations des pods critiques lors de la réimage.

  1. Vérifiez que le proxy HTTP est désactivé en validant que la configuration du proxy HTTP n’est pas définie sur les pods et les nœuds via la commande kubectl describe pod.

    kubectl describe {any pod} -n kube-system
    

    Pour valider que les variables proxy ne sont pas définies dans les pods, vous pouvez vérifier les variables d’environnement présentes sur les nœuds.

    kubectl get nodes
    kubectl node-shell {node name}
    cat /etc/environment
    

Réactiver le proxy HTTP sur un cluster existant

Lorsque vous créez un cluster, le proxy HTTP est activé par défaut. Après désactivation du proxy HTTP sur un cluster, la configuration du proxy est enregistrée dans la base de données, mais les variables de proxy sont supprimées des pods et des nœuds.

Pour réactiver le proxy HTTP sur un cluster existant, utilisez la commande az aks update avec l’indicateur --enable-http-proxy.

az aks update --name $clusterName --resource-group $resourceGroup --enable-http-proxy

Avertissement

AKS réinitialise automatiquement tous les pools de nœuds dans le cluster lorsque vous mettez à jour la configuration du proxy sur votre cluster en tirant parti de la commande az aks update. Vous pouvez utiliser des budgets d’interruption de pod (PDB) pour protéger les perturbations des pods critiques lors de la réimage.

Important

Si vous aviez une configuration de proxy HTTP sur votre cluster avant la désactivation, la configuration de proxy HTTP existante s’applique automatiquement lorsque vous réactivez le proxy HTTP sur ce cluster. Nous vous recommandons de vérifier la configuration pour veiller à ce qu’elle réponde à vos exigences actuelles avant de continuer. Si vous souhaitez modifier votre configuration de proxy HTTP après avoir réactivé le proxy HTTP, suivez la procédure pour Mettre à jour la configuration du proxy HTTP sur un cluster existant.

Configurer une configuration de proxy HTTP en utilisant un modèle Azure Resource Manager (ARM)

Vous pouvez déployer un cluster AKS avec un proxy HTTP en utilisant un modèle ARM.

  1. Passez en revue les conditions requises pour chaque paramètre :

    • httpProxy : URL de proxy à utiliser pour créer des connexions HTTP à l’extérieur du cluster. Le schéma d’URL doit être http.
    • httpsProxy : URL de proxy à utiliser pour créer des connexions HTTPS à l’extérieur du cluster. Si la valeur n’est pas spécifiée, httpProxy est utilisé à la fois pour les connexions HTTP et HTTPS.
    • noProxy : liste des noms de domaine de destination, des domaines, des adresses IP ou d’autres CIDR réseau à exclure de la mise en proxy.
    • trustedCa : Une chaîne contenant le contenu de remplacement du certificat de l'autorité de certification base64 encoded. Actuellement, seul le format PEM est pris en charge.

    Important

    Dans un souci de compatibilité avec les composants basés sur Go qui font partie du système Kubernetes, le certificat doit prendre en charge Subject Alternative Names (SANs) à la place des certificats de noms communs déconseillés.

    Il existe des différences dans les applications sur la façon de se conformer aux variables d’environnement http_proxy, https_proxyet no_proxy. Curl et Python ne prennent pas en charge CIDR dans no_proxy, contrairement à Ruby.

  2. Créez un modèle avec des paramètres de proxy HTTP. Dans votre modèle, fournissez des valeurs pour httpProxy, httpsProxy et noProxy. Si nécessaire, fournissez une valeur pour trustedCa. Le même schéma que celui utilisé pour le déploiement avec l’interface CLI existe dans la définition Microsoft.ContainerService/managedClusters sous "properties", comme illustré dans l’exemple suivant :

    "properties": {
        ...,
        "httpProxyConfig": {
          "enabled": "true",
            "httpProxy": "string",
            "httpsProxy": "string",
            "noProxy": [
                "string"
            ],
            "trustedCa": "string"
        }
    }
    
  3. Déployez votre modèle ARM avec la configuration du proxy HTTP. Votre cluster doit normalement s’initialiser avec votre proxy HTTP configuré sur les nœuds.

Mettre à jour une configuration de proxy HTTP

Vous pouvez mettre à jour les configurations de proxy HTTP sur des clusters existants, notamment :

  • Mise à jour d’un cluster existant pour activer le proxy HTTP et ajouter une nouvelle configuration de proxy HTTP.
  • Mise à jour d’un cluster existant pour modifier une configuration de proxy HTTP.

Considérations concernant la mise à jour d’un proxy HTTP

Le --http-proxy-config paramètre doit être défini sur un nouveau fichier JSON avec des valeurs mises à jour pour httpProxy, httpsProxy, noProxyet trustedCa si nécessaire. La mise à jour injecte de nouvelles variables d’environnement dans les pods avec les nouvelles valeurs de httpProxy, httpsProxy ou noProxy. Les pods doivent faire l’objet d’une rotation pour que les applications la détecte, car les valeurs des variables d’environnement sont injectées par un webhook d’admission mutant.

Remarque

Si vous basculez vers un nouveau proxy, celui-ci doit déjà exister pour que la mise à jour réussisse. Une fois la mise à niveau terminée, vous pouvez supprimer l’ancien proxy.

Mettre à jour un modèle ARM pour configurer le proxy HTTP

  1. Dans votre modèle, fournissez de nouvelles valeurs pour httpProxy, httpsProxy et noProxy. Si nécessaire, fournissez une valeur pour trustedCa.

    Le même schéma que celui utilisé pour le déploiement avec l’interface CLI existe dans la définition Microsoft.ContainerService/managedClusters sous "properties", comme illustré dans l’exemple suivant :

    "properties": {
        ...,
        "httpProxyConfig": {
            "enabled": "true",
            "httpProxy": "string",
            "httpsProxy": "string",
            "noProxy": [
                "string"
            ],
            "trustedCa": "string"
        }
    }
    
  2. Déployez votre modèle ARM avec la configuration du proxy HTTP mise à jour.

Avertissement

AKS réinitialise automatiquement tous les pools de nœuds dans le cluster lorsque vous mettez à jour la configuration du proxy sur votre cluster en tirant parti de la commande az aks update. Vous pouvez utiliser des budgets d’interruption de pod (PDB) pour protéger les perturbations des pods critiques lors de la réimage.

  1. Vérifiez que la configuration du proxy HTTP se trouve sur les pods et les nœuds en vérifiant que les variables d’environnement contiennent les valeurs appropriées pour http_proxy, https_proxy et no_proxy en tirant parti de la commande kubectl describe pod.

    kubectl describe {any pod} -n kube-system
    

    Pour valider la définition des variables de proxy dans les pods, vous pouvez vérifier les variables d’environnement présentes sur les nœuds.

    kubectl get nodes
    kubectl node-shell {node name}
    cat /etc/environment
    

Désactiver le proxy HTTP sur un cluster existant en tirant parti d’un modèle ARM (Préversion)

Installer l’extension aks-preview

  1. Installez l’extension aks-preview Azure CLI en utilisant la commande az extension add.

    Important

    Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Telles quelles, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

    az extension add --name aks-preview
    
  2. Mettez à jour vers la dernière version de l’extension à l’aide de la commande az extension update. La désactivation du proxy HTTP nécessite la version 18.0.0b13 au minimum.

    az extension update --name aks-preview
    

Inscrire l’indicateur de fonctionnalité DisableHTTPProxyPreview

  1. Inscrivez l’indicateur de fonctionnalité DisableHTTPProxyPreview à l’aide de la commande az feature register.

    az feature register --namespace Microsoft.ContainerService --name DisableHTTPProxyPreview
    
  2. Vérifiez l’état de l’inscription en utilisant la commande az feature show. Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

    az feature show --namespace Microsoft.ContainerService --name DisableHTTPProxyPreview
    
  3. Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace Microsoft.ContainerService
    

Mettre à jour le cluster pour désactiver le proxy HTTP

  1. Mettez à jour votre modèle ARM de cluster pour désactiver le proxy HTTP en définissant enabled sur false. Le même schéma que celui utilisé pour le déploiement avec l’interface CLI existe dans la définition Microsoft.ContainerService/managedClusters sous "properties", comme illustré dans l’exemple suivant :

    "properties": {
        ...,
        "httpProxyConfig": {
           "enabled": "false",
        }
    }
    
  2. Déployez votre modèle ARM avec le proxy HTTP désactivé.

Avertissement

AKS réinitialise automatiquement tous les pools de nœuds dans le cluster lorsque vous mettez à jour la configuration du proxy sur votre cluster en tirant parti de la commande az aks update. Vous pouvez utiliser des budgets d’interruption de pod (PDB) pour protéger les perturbations des pods critiques lors de la réimage.

  1. Vérifiez que le proxy HTTP est désactivé en validant que la configuration du proxy HTTP n’est pas définie sur les pods et les nœuds en utilisant la commande kubectl describe pod.

    kubectl describe {any pod} -n kube-system
    

    Pour valider que les variables proxy ne sont pas définies dans les pods, vous pouvez vérifier les variables d’environnement présentes sur les nœuds.

    kubectl get nodes
    kubectl node-shell {node name}
    cat /etc/environment
    

Réactiver le proxy HTTP sur un cluster existant

Lorsque vous créez un cluster, le proxy HTTP est activé par défaut. Une fois que vous avez désactivé le proxy HTTP sur un cluster, vous ne pouvez plus ajouter de configurations de proxy HTTP à ce cluster.

Si vous souhaitez réactiver le proxy HTTP, suivez la procédure pour Mettre à jour une configuration de proxy HTTP en tirant parti d’un modèle ARM.


Proxy HTTP du module complémentaire Istio pour les services externes

Si vous utilisez le module complémentaire Istio Service Mesh pour AKS, vous devez créer une entrée de service pour permettre à vos applications au sein du maillage d’accéder à des ressources externes ou non-cluster via le proxy HTTP.

Par exemple :

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
    name: proxy
spec:
    hosts:
    - my-company-proxy.com # ignored
    addresses:
    - $PROXY_IP/32
    ports:
    - number: $PROXY_PORT
        name: tcp
        protocol: TCP
    location: MESH_EXTERNAL
  1. Créez un fichier et fournissez des valeurs pour PROXY_IP et PROXY_PORT.

  2. Vous pouvez déployer l’entrée de service à l’aide de :

    kubectl apply -f service_proxy.yaml
    

Configuration du module complémentaire Monitoring

Le proxy HTTP avec le module complémentaire de monitoring prend en charge les configurations suivantes :

  • Proxy sortant sans authentification
  • Proxy sortant avec certificat approuvé pour le point de terminaison Log Analytics

La configuration suivante n’est pas prise en charge :

  • Fonctionnalités Métriques personnalisées et Alertes recommandées lors de l’utilisation d’un proxy avec des certificats approuvés

Étapes suivantes

Pour plus d’informations sur les exigences réseau pour les clusters AKS, consultez Contrôler le trafic de sortie pour les nœuds de cluster dans AKS.