Partage via

Prise en charge du proxy HTTP dans Azure Kubernetes Service (AKS)

  • Article

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
  • La configuration de clusters AKS existants avec un proxy HTTP n’est pas prise en charge. La fonctionnalité de proxy HTTP doit être activée au moment de la création du cluster.
  • Clusters Windows
  • Pools de nœuds utilisant des groupes à haute 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

  • Vous devez disposer de la dernière version d’Azure CLI. Exécutez az --version pour rechercher la version, puis exécutez az upgrade pour mettre à niveau la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
  • Recherchez les mises à niveau disponibles pour les clusters AKS pour être sûr d’exécuter la dernière version d’AKS. Si vous devez effectuer une mise à niveau, consultez Mettre à niveau un cluster AKS.
  • Les fichiers du système d’exploitation nécessaires pour les mises à jour de la configuration du proxy peuvent être mis à jour seulement pendant le processus de mise à niveau de l’image du nœud. Après avoir configuré le proxy, vous devez mettre à niveau l’image du nœud pour appliquer les modifications. Pour plus d’informations, consultez Mettre à niveau des images de nœuds AKS.

Configurer un proxy HTTP en utilisant Azure CLI

Vous pouvez configurer un cluster AKS avec un proxy HTTP lors de la création du cluster en utilisant la commande az aks create et en passant la configuration en tant que fichier JSON.

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

{
  "httpProxy": "string",
  "httpsProxy": "string",
  "noProxy": [
    "string"
  ],
  "trustedCa": "string"
}
  • 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 : chaîne avec le contenu de certificat d’autorité de certification de remplacement 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 :

Notes

Le certificat de l’autorité de certification doit être la chaîne encodée en base64 du contenu du certificat au format PEM.

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

Créez un fichier et fournissez des valeurs pour httpProxy, httpsProxy et noProxy. Si votre environnement l’exige, fournissez une valeur pour trustedCa. Ensuite, vous pouvez déployer le cluster en utilisant la commande az aks create avec le paramètre --http-proxy-config défini sur le fichier que vous avez créé. Votre cluster doit normalement s’initialiser avec le proxy HTTP configuré sur les nœuds.

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

Configurer un 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. 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": {
        "httpProxy": "string",
        "httpsProxy": "string",
        "noProxy": [
            "string"
        ],
        "trustedCa": "string"
    }
}

Dans votre modèle, fournissez des valeurs pour httpProxy, httpsProxy et noProxy. Si nécessaire, fournissez une valeur pour trustedCa. Ensuite, vous pouvez déployer le modèle. Votre cluster doit normalement s’initialiser avec votre proxy HTTP configuré sur les nœuds.

Proxy HTTP d’extension Istio pour les services externes

Si vous utilisez le module complémentaire de maillage de services Istio pour AKS, vous devez créer une entrée de service afin de permettre à vos applications dans le maillage d’accéder à des ressources non-cluster ou externes 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

Créez un fichier et fournissez des valeurs pour PROXY_IP et PROXY_PORT. Vous pouvez déployer l’entrée de service à l’aide de

kubectl apply -f service_proxy.yaml

Mettre à jour la configuration du proxy

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.

Vous pouvez mettre à jour la configuration du proxy sur votre cluster en utilisant la commande az aks update avec le paramètre --http-proxy-config défini sur un nouveau fichier JSON avec si nécessaire des valeurs mises à jour pour httpProxy, httpsProxy, noProxy et trustedCa. 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. Pour les composants sous Kubernetes, comme containerd et le nœud lui-même, ceci ne prend pas effet tant qu’une mise à jour de l’image du nœud n’est pas effectuée.

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

Mettre à niveau des images de nœud AKS

Après avoir configuré le proxy, vous devez mettre à niveau l’image du nœud pour appliquer les modifications. Le processus de mise à niveau de l’image du nœud est le seul moyen de mettre à jour les fichiers du système d’exploitation nécessaires pour les mises à jour de la configuration du proxy. Le processus de mise à niveau de l’image du nœud est une mise à niveau propagée qui met à jour l’image du système d’exploitation sur chaque nœud du pool de nœuds. Le plan de contrôle AKS gère le processus de mise à niveau, qui ne perturbe pas les applications en cours d’exécution.

Pour mettre à niveau des images de nœud AKS, consultez Mise à niveau des images de nœud Azure Kubernetes Service (AKS).

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 authentification par nom d’utilisateur et mot de passe
  • Proxy sortant avec certificat approuvé pour le point de terminaison Log Analytics

Les configurations suivantes ne sont pas prises 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.