Mise en réseau dans un environnement Azure Container Apps

Azure Container Apps s’exécute dans le contexte d’un environnement, avec son propre réseau virtuel (VNet).

Par défaut, votre environnement d’Application Conteneur est créé avec un VNet qui est automatiquement généré pour vous. Pour un contrôle plus précis de votre réseau, vous pouvez fournir un VNet existant lorsque vous créez un environnement. Une fois que vous créez un environnement avec un VNet généré ou existant, le type de réseau ne peut pas être changé.

Les réseaux virtuels générés ont les caractéristiques suivantes.

Il s’agit de :

• Inaccessibles pour vous car ils sont créés dans le locataire de Microsoft.
• Accessibles publiquement sur Internet.
• Uniquement capables d’atteindre des points de terminaison accessibles à Internet.

En outre, ils prennent uniquement en charge un sous-ensemble limité de fonctionnalités réseau, telles que les restrictions IP d’entrée et les contrôles d’entrée au niveau de l’application conteneur.

Utilisez un réseau virtuel existant si vous avez besoin d’autres fonctionnalités réseau Azure telles que :

• Intégration à Application Gateway
• Network Security Group
• Communication avec des ressources situées derrière des points de terminaison privés dans votre réseau virtuel

Les fonctionnalités de réseau virtuel disponibles dépendent de la sélection de votre environnement.

Sélection de l’environnement

Container Apps a deux types d’environnement différents, qui partagent de nombreuses caractéristiques réseau avec certaines différences clés.

Niveaux d’accessibilité

Vous pouvez configurer si votre application conteneur autorise l’entrée publique ou l’entrée uniquement à partir de votre réseau virtuel au niveau de l’environnement.

Configuration de réseau virtuel personnalisé

Lorsque vous créez un réseau virtuel personnalisé, gardez à l’esprit les situations suivantes :

• Si vous souhaitez que votre application de conteneur limite tout accès extérieur, créez un environnement Container Apps interne.

• Si vous utilisez votre propre réseau virtuel, vous devez fournir un sous-réseau dédié exclusivement à l’environnement Container Apps que déployez. Ce sous-réseau n’est pas accessible à d’autres services.

• Des adresses réseau sont attribuées à partir d’une plage de sous-réseau que vous définissez lors de la création de l’environnement.

  • Vous pouvez définir la plage de sous-réseau utilisée par l’environnement Container Apps.

  • Vous pouvez restreindre les requêtes entrantes dans l’environnement exclusivement au réseau virtuel en déployant l’environnement en interne.

Lorsque vous commencez à concevoir le réseau autour de votre application conteneur, reportez-vous à Planifier des réseaux virtuels.

Comportement du proxy de périmètre HTTP

Azure Container Apps utilise le proxy Envoy comme proxy HTTP de périphérie. TLS (Transport Layer Security) est arrêté à la périphérie, les requêtes sont routées en fonction de leurs règles de fractionnement du trafic, et le trafic est routé vers l’application correcte.

Les applications HTTP sont mises à l’échelle en fonction du nombre de requêtes et de connexions HTTP. Envoy achemine le trafic interne à l’intérieur de clusters.

Les connexions en aval prennent en charge HTTP1.1 et HTTP2, et Envoy détecte et met à niveau automatiquement les connexions si la connexion cliente exige une mise à niveau.

Les connexions en amont sont définies en définissant la propriété transport sur l’objet ingress.

Configuration de l’entrée

Dans la section entrée, vous pouvez configurer les paramètres suivants :

• Niveau d’accessibilité : vous pouvez définir votre application de conteneur comme accessible en externe ou en interne dans l’environnement. Une variable d’environnement CONTAINER_APP_ENV_DNS_SUFFIX est utilisée pour résoudre automatiquement le suffixe de nom de domaine complet (FQDN) pour votre environnement. Lors des communications entre des applications conteneur au sein du même environnement, vous pouvez également utiliser le nom de l’application. Pour plus d’informations sur la façon d’accéder à vos applications, consultez Entrée dans Azure Container Apps.

• Règles de fractionnement du trafic : vous pouvez définir des règles de fractionnement du trafic entre différentes révisions de votre application. Pour plus d’informations, consultez Fractionnement du trafic.

Pour plus d’informations sur différents scénarios réseau, consultez Entrée dans Azure Container Apps.

Dépendances du portail

Il existe deux URL pour chaque application dans Azure Container Apps.

Le runtime Container Apps génère initialement un nom de domaine complet utilisé pour accéder à votre application. Consultez l’URL de l’application dans la fenêtre Vue d’ensemble de votre application conteneur dans le portail Azure pour connaître le nom de domaine complet de votre application conteneur.

Une deuxième URL est également générée pour vous. Cet emplacement accorde l’accès au service de streaming de journaux et à la console. Si nécessaire, vous devrez peut-être ajouter https://azurecontainerapps.dev/ à la liste d’autorisation de votre pare-feu ou proxy.

Ports et adresses IP

Les ports suivants sont exposés pour les connexions entrantes.

Les adresses IP sont décomposées selon les types suivants :

Sous-réseau

L’intégration au réseau virtuel dépend d’un sous-réseau dédié. Le mode d’allocation des adresses IP dans un sous-réseau et les tailles de sous-réseau prises en charge dépendent du plan que vous utilisez dans Azure Container Apps.

Sélectionnez soigneusement la taille de votre sous-réseau. Les tailles de sous-réseau ne peuvent pas être modifiées après que vous avez créé un environnement Container Apps.

Différents types d’environnement ont des exigences de sous-réseau différentes :

Restrictions de plage d’adresses de sous-réseau

Configuration de sous-réseau avec l’interface CLI

Quand vous créez un environnement Container Apps, vous indiquez des ID de ressource pour un seul sous-réseau.

Si vous utilisez l’interface CLI, le paramètre infrastructure-subnet-resource-id permet de définir l’ID de ressource de sous-réseau. Le sous-réseau héberge les composants d’infrastructure et les conteneurs d’application utilisateur.

Si vous utilisez Azure CLI avec un environnement Consommation uniquement et que la plage platformReservedCidr est définie, le sous-réseau ne doit pas chevaucher la plage d’adresses IP définie dans platformReservedCidr.

Itinéraires

Routes définies par l’utilisateur (UDR)

Les Routes Définies par l’Utilisateur (UDR) et la gestion contrôlée de la sortie via la passerelle NAT sont prises en charge dans l’environnement des profils de charge de travail. Dans l’environnement « Consommation uniquement », ces fonctionnalités ne sont pas prises en charge.

• Vous pouvez utiliser UDR avec les environnements des profils de charge de travail pour restreindre le trafic sortant de votre application conteneur via le pare-feu Azure ou d’autres dispositifs réseau.

• La configuration d’UDR se fait en dehors du périmètre de l’environnement Container Apps.

Azure crée une table de routage par défaut pour vos réseaux virtuels lors de la création. En implémentant une table de routage définie par l’utilisateur, vous pouvez contrôler comment le trafic est routé au sein de votre réseau virtuel. Par exemple, vous pouvez créer une route définie par l’utilisateur qui route tout le trafic vers le pare-feu.

Configuration de routes définies par l’utilisateur avec le Pare-feu Azure

Les routes définies par l’utilisateur sont prises en charge uniquement dans un environnement de profils de charge de travail. Les règles d’application et de réseau suivantes doivent être ajoutées à la liste verte de votre pare-feu en fonction des ressources que vous utilisez.

Règles d’application

Les règles d’application autorisent ou refusent le trafic en fonction de la couche Application. Les règles d’application de pare-feu sortantes suivantes sont requises en fonction du scénario.

Règles de réseau

Les règles réseau autorisent ou refusent le trafic en fonction de la couche de transport et réseau. Les règles réseau de pare-feu sortantes suivantes sont requises en fonction du scénario.

Intégration de la passerelle NAT

Vous pouvez utiliser NAT Gateway afin de simplifier la connectivité sortante pour votre trafic Internet sortant dans votre réseau virtuel dans un environnement de profils de charge de travail.

Lorsque vous configurez NAT Gateway sur votre sous-réseau, NAT Gateway fournit une adresse IP publique statique pour votre environnement. Tout le trafic sortant de votre application conteneur est routé via l’adresse IP publique statique de NAT Gateway.

Sécurité des environnements

Vous pouvez sécuriser entièrement votre environnement de profils de charge de travail de trafic réseau d’entrée et de sortie en effectuant les actions suivantes :

• Créez votre environnement d’application conteneur interne dans un environnement de profils de charge de travail. Pour connaître les étapes, consultez Gérer des profils de charge de travail avec Azure CLI.

• Intégrez vos applications conteneur à une passerelle Application Gateway.

• Configurez des routes définies par l’utilisateur afin de router tout le trafic via Pare-feu Azure.

Chiffrement pair à pair dans l’environnement Azure Container Apps

Azure Container Apps prend en charge le chiffrement TLS pair à pair au sein de l’environnement. L’activation de cette fonctionnalité chiffre tout le trafic réseau au sein de l’environnement avec un certificat privé valide dans l’étendue de l’environnement Azure Container Apps. Ces certificats sont gérés automatiquement par Azure Container Apps.

L’exemple suivant montre un environnement avec le chiffrement pair à pair activé.

¹ Le trafic TLS entrant est arrêté au niveau du proxy d’entrée sur la périphérie de l’environnement.

² Le trafic vers et depuis le proxy d’entrée au sein de l’environnement est chiffré par TLS avec un certificat privé et déchiffré par le récepteur.

³ Les appels effectués à partir de l’application A au nom de domaine complet de l’application B sont d’abord envoyés au proxy d’entrée en périphérie et sont chiffrés par TLS.

⁴ Les appels effectués à partir de l’application A vers l’application B avec le nom de l’application B sont envoyés directement à l’application B et sont chiffrés par TLS.

Les applications dans un environnement Container Apps sont automatiquement authentifiées. Toutefois, le runtime Container Apps ne prend pas en charge l’autorisation pour le contrôle d’accès entre les applications à l’aide du chiffrement pair à pair intégré.

Lorsque vos applications communiquent avec un client en dehors de l’environnement, l’authentification bidirectionnelle avec mTLS est prise en charge. Pour plus d’informations, consultez Configurer des certificats clients.

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

{
  ...
  "properties": {
       "peerTrafficConfiguration":{
            "encryption": {
                "enabled": "true|false"
            }
        }
  ...
}

DNS

• DNS personnalisé : si votre réseau virtuel utilise un serveur DNS personnalisé plutôt que le serveur DNS fourni par Azure par défaut, configurez votre serveur DNS de façon à transférer les requêtes DNS non résolues vers 168.63.129.16. Les résolveurs récursifs Azure utilisent cette adresse IP pour résoudre les requêtes. Lorsque vous configurez votre groupe de sécurité réseau ou votre pare-feu, ne bloquez pas l’adresse 168.63.129.16, car dans ce cas votre environnement Container Apps ne fonctionnerait pas correctement.

• Entrée d’étendue de réseau virtuel : si vous envisagez d’utiliser des entrées d’étendue de réseau virtuel dans un environnement interne, configurez vos domaines de l’une des façons suivantes :

  1. Domaines non personnalisés : si vous ne prévoyez pas d’utiliser de domaine personnalisé, créez une zone DNS privée qui résout le domaine par défaut de l’environnement Container Apps sur l’adresse IP statique de l’environnement Container Apps. Vous pouvez utiliser un serveur DNS privé Azure ou votre propre serveur DNS. Si vous utilisez un serveur DNS privé Azure, créez une zone DNS privée nommée comme domaine par défaut de l’environnement Container Apps (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), avec un enregistrement A. L’enregistrement A contenant le nom *<DNS Suffix> et l’adresse IP statique de l’environnement Container Apps.

  2. Domaines personnalisés : si vous envisagez d’utiliser des domaines personnalisés et que vous utilisez un environnement Container Apps externe, utilisez un domaine pouvant être résolu publiquement pour ajouter un domaine personnalisé et un certificat à l’application conteneur. Si vous utilisez un environnement interne des Container Apps, il n’y a pas de validation pour la liaison DNS, car le cluster ne peut être accessible que depuis le réseau virtuel. En outre, créez une zone DNS privée qui résout le domaine apex à l’adresse IP statique de l’environnement Container Apps. Vous pouvez utiliser un serveur DNS privé Azure ou votre propre serveur DNS. Si vous utilisez un serveur DNS privé Azure, créez une zone DNS privée nommée « domaine apex » avec un enregistrement A qui pointe vers l’adresse IP statique de l’environnement Container Apps.

L’adresse IP statique de l’environnement Container Apps est accessible dans le portail Azure dans Suffixe DNS personnalisé, dans la page de l’application conteneur, ou à l’aide de la commande Azure CLI az containerapp env list.

Ressources managées

Quand vous déployez un environnement interne ou externe dans votre propre réseau, un nouveau groupe de ressources est créé dans l’abonnement Azure où votre environnement est hébergé. Ce groupe de ressources contient les composants d’infrastructure managés par la plateforme Azure Container Apps. Ne modifiez ni les services de ce groupe, ni le groupe de ressources lui-même.

Environnements de profils de charge de travail

Le nom du groupe de ressources créé dans l’abonnement Azure où votre environnement est hébergé est précédé par défaut de ME_, et le nom du groupe de ressources peut être personnalisé lorsque vous créez votre environnement d’application conteneur.

Pour les environnements externes, le groupe de ressources contient une adresse IP publique utilisée spécifiquement pour la connectivité entrante à votre environnement externe et un équilibreur de charge. Pour les environnements internes, le groupe de ressources contient uniquement un équilibreur de charge.

En plus de la facturation standard pour Azure Container Apps, vous êtes facturé pour :

• Une adresse IP publique statique standard pour la sortie si vous utilisez un environnement interne ou externe, plus une adresse IP publique statique standard pour l’entrée si vous utilisez un environnement externe. Si vous avez besoin de davantage d’adresses IP publiques pour la sortie en raison de problèmes SNAT (Source Network Address Translation), ouvrez un ticket de support pour demander un remplacement.

• Un équilibreur de charge standard.

• Le coût des données traitées (Go) inclut à la fois les entrées et les sorties pour les opérations de gestion.

Environnement de consommation uniquement

Le nom du groupe de ressources créé dans l’abonnement Azure où votre environnement est hébergé est précédé par défaut de MC_, et le nom du groupe de ressources ne peut pas être personnalisé lorsque vous créez une application conteneur. Le groupe de ressources contient des adresses IP publiques utilisées spécifiquement pour la connectivité sortante de votre environnement, ainsi qu’un équilibreur de charge.

En plus de la facturation standard pour Azure Container Apps, vous êtes facturé pour :

• Une adresse IP publique statique standard pour la sortie. Si vous avez besoin de davantage d’adresses IP pour la sortie en raison de problèmes SNAT, ouvrez un ticket de support pour demander un remplacement.

• Deux équilibreurs de charge standard si vous utilisez un environnement interne, ou un équilibreur de charge standard si vous utilisez un environnement externe. Chaque équilibreur de charge a moins de six règles. Le coût des données traitées (Go) inclut à la fois les entrées et les sorties pour les opérations de gestion.

Étapes suivantes

• Effectuer un déploiement avec un environnement externe
• Effectuer un déploiement avec un environnement interne