Partage via

Mise en réseau dans un environnement Azure Container Apps

  • Article

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.

Type d’environnement Description Types de plans pris en charge
Profils de charge de travail Prend en charge les routes définies par l’utilisateur (UDR) et la sortie via NAT Gateway. La taille minimale requise du sous-réseau est /27. Consommation, Dédié
Consommation uniquement Ne prend pas en charge les routes définies par l’utilisateur, la sortie via NAT Gateway, le peering par le biais d’une passerelle distante ou d’autres sorties personnalisées. La taille minimale requise du sous-réseau est /23. Consommation

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.

Niveau d’accessibilité Description
Externe Autorise votre application conteneur à accepter les requêtes publiques. Les environnements externes sont déployés avec une adresse IP virtuelle sur une adresse IP publique externe.
Interne Les environnements internes n’ont pas de point de terminaison public et sont déployés avec une adresse IP virtuelle (VIP) mappée à une adresse IP interne. Le point de terminaison interne est un équilibreur de charge interne Azure, et les adresses IP sont émises à partir de la liste des adresses IP privées du réseau virtuel personnalisé.

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.

Remarque

Lorsque vous fournissez votre propre réseau virtuel, des ressources managées supplémentaires sont créées. Ces ressources entraînent des coûts à leurs tarifs associés.

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

Diagramme montrant comment les environnements Azure Container Apps utilisent un réseau virtuel existant, ou comment vous pouvez fournir le vôtre.

Remarque

Le déplacement de réseaux virtuels entre différents groupes de ressources ou abonnements n’est pas autorisé si le réseau virtuel est utilisé par un environnement Container Apps.

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.

Protocol Port(s)
HTTP/HTTPS 80, 443

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

Type Description
Adresse IP entrante publique Utilisée pour le trafic d’application dans un déploiement externe, et pour le trafic de gestion dans les déploiements internes et externes.
Adresse IP publique sortante Utilisée en tant qu’adresse IP source pour les connexions sortantes quittant le réseau virtuel. Ces connexions ne sont pas routées vers un réseau privé virtuel. Les adresses IP sortantes peuvent changer au fil du temps. L’utilisation d’une passerelle NAT ou d’un autre proxy pour le trafic sortant à partir d’un environnement Container Apps est uniquement prise en charge dans un environnement de profils de charge de travail.
Adresse IP de l’équilibreur de charge interne Cette adresse n’existe que dans un environnement interne.

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 :

  • /27 est la taille minimale du sous-réseau requise pour l’intégration de réseau virtuel.

  • Votre sous-réseau doit être délégué à Microsoft.App/environments.

  • Lorsque vous utilisez un environnement externe avec une entrée externe, le trafic entrant est routé via l’adresse IP publique de l’infrastructure plutôt que via votre sous-réseau.

  • Container Apps réserve automatiquement 12 adresses IP pour l’intégration au sous-réseau. Le nombre d’adresses IP requises pour l’intégration de l’infrastructure ne varie pas en fonction des exigences de mise à l’échelle de l’environnement. Des adresses IP supplémentaires sont allouées conformément aux règles suivantes, en fonction du type de profil de charge de travail que vous utilisez. Le nombre d’adresses IP allouées dépend du profil de charge de travail de votre environnement :

  • Lorsque vous apportez une modification à une révision en mode révision unique, l’espace d’adressage requis est doublé pendant une courte période afin de prendre en charge les déploiements sans temps d’arrêt. Cela affecte les réplicas ou nœuds pris en charge réels et disponibles pour une taille de sous-réseau donnée. Le tableau suivant indique à la fois le nombre maximal d’adresses disponibles par bloc CIDR et l’effet sur la mise à l’échelle horizontale.

    Taille du sous-réseau Adresses IP disponibles 1 Nombre maximal de nœuds (profil de charge de travail dédiée)2 Nombre maximal de réplicas (profil de charge de travail de consommation)2
    /23 500 250 2 500
    /24 244 122 1220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Le nombre d’adresses IP disponibles est égal à la taille du sous-réseau moins les 12 adresses IP requises pour l’infrastructure Azure Container Apps.
    2 Ceci prend en compte les applications en mode révision unique.

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

Les plages d’adresses de sous-réseau ne peuvent pas chevaucher les plages suivantes réservées par Azure Kubernetes Services :

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

En outre, un environnement de profils de charge de travail réserve les adresses suivantes :

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

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.

Remarque

Lorsque vous utilisez des routes définies par l’utilisateur avec le Pare-feu Azure dans Azure Container Apps, vous devez ajouter certaines étiquettes de service et noms de domaine complet à la liste verte du pare-feu. Pour en savoir plus, consultez Configuration de routes définies par l’utilisateur avec le Pare-feu Azure.

  • 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.

Diagramme de la façon dont la route UDR est implémentée pour 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.

Remarque

Pour obtenir des instructions sur la façon de configurer des routes définies par l’utilisateur avec Container Apps pour restreindre le trafic sortant avec le Pare-feu Azure, consultez la procédure pour Container Apps et Pare-feu Azure.

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.

Scénarios Noms de domaine complets Description
Tous les scénarios mcr.microsoft.com, *.data.mcr.microsoft.com Ces noms de domaine complets pour Microsoft Container Registry (MCR) sont utilisés par Azure Container Apps, et ces règles d’application ou les règles réseau pour MCR doivent être ajoutées à la liste verte lors de l’utilisation d’Azure Container Apps avec le Pare-feu Azure.
Azure Container Registry (ACR) votre_adresse_ACR, *.blob.core.windows.net, login.microsoft.com Ces noms de domaine complets sont requis lors de l’utilisation d’Azure Container Apps avec ACR et Pare-feu Azure.
Azure Key Vault Votre_adresse_Azure_Key_Vault, login.microsoft.com Ces noms de domaine complets sont requis en plus de l’étiquette de service requise pour la règle de réseau pour Azure Key Vault.
Identité managée *.identity.azure.net, login.microsoftonline.com, *.login.microsoftonline.com, *.login.microsoft.com Ces noms de domaine complets sont requis lors de l’utilisation d’une identité managée avec Pare-feu Azure dans Azure Container Apps.
Registre Docker Hub hub.docker.com, registry-1.docker.io, production.cloudflare.docker.com Si vous utilisez le registre Docker Hub et que vous souhaitez y accéder via le pare-feu, vous devez ajouter ces noms de domaine complets au pare-feu.
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.

Scénarios Étiquette du service Description
Tous les scénarios MicrosoftContainerRegistry, AzureFrontDoorFirstParty Ces étiquettes de service pour Microsoft Container Registry (MCR) sont utilisées par Azure Container Apps, et ces règles réseau ou les règles d’application pour MCR doivent être ajoutées à la liste verte lors de l’utilisation d’Azure Container Apps avec le Pare-feu Azure.
Azure Container Registry (ACR) AzureContainerRegistry, AzureActiveDirectory Lorsque vous utilisez ACR avec Azure Container Apps, vous devez configurer ces règles d’application utilisées par Azure Container Registry.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Ces étiquettes de service sont requises en plus du nom de domaine complet pour la règle d’application pour Azure Key Vault.
Identité managée AzureActiveDirectory Lors de l’utilisation de Managed Identity avec Azure Container Apps, vous devez configurer ces règles d’application utilisées par Managed Identity.

Remarque

Pour les ressources Azure que vous utilisez avec le Pare-feu Azure non répertoriées dans cet article, reportez-vous à la documentation sur les étiquettes de service.

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

Diagramme montrant comment verrouiller entièrement votre réseau pour Container Apps.

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 :

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.

Remarque

Par défaut, le chiffrement pair à pair est désactivé. L’activation du chiffrement pair à pair pour vos applications peut augmenter la latence de réponse et réduire le débit maximal dans les scénarios à charge élevée.

L’exemple suivant montre un environnement avec le chiffrement pair à pair activé. Diagramme de la façon dont le trafic est chiffré/déchiffré avec le chiffrement pair à pair activé.

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

2 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.

3 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.

4 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.

Vous pouvez activer le chiffrement pair à pair en utilisant les commandes suivantes.

Lors de la création :

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

Pour une application conteneur existante :

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

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 :

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 :

Étapes suivantes