Netzwerk in der Azure Container Apps-Umgebung

Azure Container-Apps werden im Kontext einer Umgebung mit einem eigenen virtuellen Netzwerk (VNet) ausgeführt.

Die Container-App-Umgebung wird standardmäßig mit einem automatisch erzeugten VNET erstellt. Zur fein abgestimmten Kontrolle über Ihr Netzwerk können Sie beim Erstellen einer Umgebung eine vorhandene VNet bereitstellen. Nach der Erstellung der Umgebung, ob mit erzeugtem oder vorhandenem VNET, können Sie den Netzwerktyp nicht mehr ändern.

Generierte VNets übernehmen die folgenden Merkmale.

Sie lauten wie folgt:

• für Sie nicht zugänglich, da sie im Mandanten von Microsoft erstellt werden
• Öffentlich zugänglich über das Internet
• nur in der Lage, internetfähige Endpunkte zu erreichen

Darüber hinaus unterstützen sie nur eine begrenzte Teilmenge von Netzwerkfunktionen, z. B. eingehende IP-Einschränkungen und Eingangssteuerelemente auf Container-App-Ebene.

Verwenden Sie ein vorhandenes VNet, wenn Sie weitere Azure-Netzwerkfeatures benötigen, z. B.:

• Integration in Application Gateway
• Netzwerksicherheitsgruppen
• Kommunikation mit Ressourcen hinter privaten Endpunkten in Ihrem virtuellen Netzwerk

Die verfügbaren VNet-Features hängen von Ihrer Umgebungsauswahl ab.

Umgebungsauswahl

Container-Apps verfügen über zwei verschiedene Umgebungstypen, die viele der gleichen Netzwerkmerkmale mit einigen wichtigen Unterschieden aufweisen.

Virtuelle IP-Adresse

Je nach Ihrer Konfiguration der virtuellen IP können Sie auf der Umgebungsebene konfigurieren, ob Ihre Container-App-Umgebung öffentlichen Eingang oder Eingang nur aus Ihrem VNet zulässt. Diese Konfiguration kann nicht geändert werden, nachdem Ihre Umgebung erstellt wurde.

Benutzerdefinierte VNet-Konfiguration

Wenn Sie ein benutzerdefiniertes Vnet erstellen, berücksichtigen Sie die folgenden Situationen:

• Wenn Sie möchten, dass Ihre Container-App den gesamten externen Zugriff einschränken soll, erstellen Sie eine interne Container Apps-Umgebung.

• Wenn Sie Ihr eigenes VNet nutzen, müssen Sie ein Subnetz bereitstellen, das ausschließlich der Container-App-Umgebung zugeordnet ist, die Sie bereitstellen. Dieses Subnetz steht anderen Diensten nicht zur Verfügung.

• Netzwerkadressen werden aus einem Subnetzbereich zugewiesen, den Sie beim Erstellen der Umgebung definieren.

  • Sie können den Subnetzbereich definieren, der von der Container Apps-Umgebung verwendet wird.

  • Sie können eingehende Anforderungen an die Umgebung ausschließlich auf das Vnet beschränken, indem Sie die Umgebung als intern bereitstellen.

Wenn Sie mit dem Entwerfen des Netzwerks für Ihre Container-App beginnen, lesen Sie Planen virtueller Netzwerke.

Verhalten des HTTP-Edgeproxys

Azure Container Apps verwendet den Envoy Proxy als HTTP-Edgeproxy. Transport Layer Security (TLS) endet am Edge, und Anforderungen werden gemäß ihren Datenverkehrs-Aufteilungsregeln weitergeleitet, und der Datenverkehr wird an die richtige Anwendung weitergeleitet.

HTTP-Anwendungen werden basierend auf der Anzahl der HTTP-Anforderungen und -Verbindungen skaliert. Envoy leitet den internen Datenverkehr innerhalb von Clustern weiter.

Downstreamverbindungen unterstützen HTTP1.1 und HTTP2, und Envoy erkennt und aktualisiert Verbindungen automatisch, falls für die Clientverbindung ein Upgrade erforderlich ist.

Die Upstreamverbindungen werden durch Festlegen der transport-Eigenschaft im Eingangs-Objekt definiert.

Konfiguration des eingehenden Datenverkehrs

Im Abschnitt ingress (Eingang) können Sie die folgenden Einstellungen konfigurieren:

• Zugriffsebene: Sie können Ihre Container-App als extern oder intern zugänglich in der Umgebung festlegen. Die Umgebungsvariable CONTAINER_APP_ENV_DNS_SUFFIX wird verwendet, um das vollqualifizierte Domänennamen FQDN-Suffix (fully qualified domain name) für Ihre Umgebung automatisch aufzulösen. Bei der Kommunikation zwischen Container-Apps innerhalb derselben Umgebung können Sie auch den App-Namen verwenden. Weitere Informationen zum Zugreifen auf Ihre Apps finden Sie unter Eingang in Azure Container Apps.

• Datenverkehrs-Aufteilungsregeln: Sie können Datenverkehrs-Aufteilungsregeln zwischen verschiedenen Revisionen Ihrer Anwendung definieren. Weitere Informationen finden Sie unter Datenverkehrsaufteilung.

Weitere Informationen zu verschiedenen Netzwerkszenarien finden Sie unter Eingang in Azure Container Apps.

Portalabhängigkeiten

Für jede App in Azure Container Apps gibt es zwei URLs.

Die Container-Apps-Laufzeit generiert zunächst einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN), der für den Zugriff auf Ihre App verwendet wird. Sehen Sie sich die Anwendungs-URL im Übersichtsfenster Ihrer Container-App im Azure-Portal für den FQDN Ihrer Container-App an.

Eine zweite URL wird auch für Sie generiert. Dieser Speicherort gewährt Zugriff auf den Protokollstreamingdienst und die Konsole. Falls erforderlich, müssen Sie möglicherweise https://azurecontainerapps.dev/ der Zulassungsliste Ihrer Firewall oder Ihres Proxys hinzufügen.

Ports und IP-Adressen

Die folgenden Ports werden für eingehende Verbindungen verfügbar gemacht.

IP-Adressen werden in die folgenden Typen unterteilt:

Subnet

Die Integration virtueller Netzwerke hängt von der Verwendung eines dedizierten Subnetzes ab. Wie IP-Adressen in einem Subnetz zugeordnet werden und welche Subnetzgrößen unterstützt werden, hängt davon ab, welchen Plan Sie in Azure-Container-Apps verwenden.

Wählen Sie Ihre Subnetzgröße sorgfältig aus. Subnetzgrößen können nicht geändert werden, nachdem Sie eine Container-Apps-Umgebung erstellt haben.

Unterschiedliche Umgebungstypen weisen unterschiedliche Subnetzanforderungen auf:

Einschränkungen des Subnetzadressbereichs

Subnetzkonfiguration mit CLI

Wenn eine Container Apps-Umgebung erstellt wird, geben Sie Ressourcen-IDs für ein einzelnes Subnetz an.

Wenn Sie die CLI verwenden, ist infrastructure-subnet-resource-id der Parameter zum Definieren der Subnetzressourcen-ID. Das Subnetz hostet Infrastrukturkomponenten und Benutzer-App-Container.

Wenn Sie die Azure CLI mit einer Nur-Verbrauchs-Umgebung verwenden und der platformReservedCidr-Bereich definiert ist, dürfen sich die Subnetze nicht mit dem in platformReservedCidr definierten IP-Adressbereich überschneiden.

Routen

Benutzerdefinierte Routen (UDR)

Benutzerdefinierte Routen (UDR) und kontrollierter Ausgang über das NAT Gateway werden in der Workload-Profilumgebung unterstützt. In der verbrauchsorientierten Umgebung werden diese Funktionen nicht unterstützt.

• Sie können UDR mit Workload-Profilumgebungen verwenden, um ausgehenden Datenverkehr von Ihrer Container-App über Azure Firewall oder andere Netzwerkgeräte einzuschränken.

• Das Konfigurieren von UDR erfolgt außerhalb des Bereichs „Container Apps“.

Azure erstellt beim Erstellen eine Standardroutentabelle für Ihre virtuellen Netzwerke. Durch die Implementierung einer benutzerdefinierten Routentabelle können Sie steuern, wie Datenverkehr innerhalb Ihres virtuellen Netzwerks weitergeleitet wird. Sie können z. B. ein UDR erstellen, das den gesamten Datenverkehr an die Firewall weiterleitet.

Konfigurieren von UDR mit Azure Firewall

Benutzerdefinierte Routen werden nur in einer Workloadprofilumgebung unterstützt. Die folgenden Anwendungs- und Netzwerkregeln müssen der Zulassungsliste für Ihre Firewall hinzugefügt werden, je nachdem, welche Ressourcen Sie verwenden.

Anwendungsregeln

Anwendungsregeln erlauben oder verweigern Datenverkehr basierend auf der Anwendungsschicht. Die folgenden Regeln für ausgehende Firewallanwendungen sind basierend auf einem Szenario erforderlich.

Netzwerkregeln

Netzwerkregeln ermöglichen oder verweigern Datenverkehr basierend auf der Netzwerk- und Transportschicht. Die folgenden Regeln für ausgehende Firewallnetzwerke sind basierend auf einem Szenario erforderlich.

NAT-Gatewayintegration

Sie können das NAT-Gateway verwenden, um die ausgehende Konnektivität für Ihren ausgehenden Internetdatenverkehr in Ihrem virtuellen Netzwerk in einer Workloadprofilumgebung zu vereinfachen.

Wenn Sie ein NAT-Gateway in Ihrem Subnetz konfigurieren, stellt das NAT-Gateway eine statische öffentliche IP-Adresse für Ihre Umgebung bereit. Der gesamte ausgehende Datenverkehr aus Ihrer Container-App wird über die statische öffentliche IP-Adresse des NAT-Gateways weitergeleitet.

Öffentlicher Netzwerkzugriff (Vorschau)

Die Einstellung für den öffentlichen Netzwerkzugriff bestimmt, ob aus dem öffentlichen Internet auf Ihre Container Apps-Umgebung zugegriffen werden kann. Ob Sie diese Einstellung nach dem Erstellen Ihrer Umgebung ändern können, hängt von der Konfiguration der virtuellen IP der Umgebung ab. In der folgenden Tabelle sind gültige Werte für den öffentlichen Netzwerkzugriff aufgeführt, je nach Konfiguration der virtuellen IP Ihrer Umgebung.

Um private Endpunkte in Ihrer Azure Container Apps-Umgebung zu erstellen, muss der öffentliche Netzwerkzugriff auf Disabled festgelegt werden.

Azure-Netzwerkrichtlinien werden mit dem Flag für den öffentlichen Netzwerkzugriff unterstützt.

Privater Endpunkt (Vorschau)

Der private Azure-Endpunkt ermöglicht es Clients, die sich in Ihrem privaten Netzwerk befinden, über Azure Private Link eine sichere Verbindung mit Ihrer Azure Container Apps-Umgebung herzustellen. Bei einer Private Link-Verbindung wird der Datenverkehr also vom öffentlichen Internet isoliert. Private Endpunkte verwenden eine private IP-Adresse aus dem Adressraum Ihres virtuellen Azure-Netzwerks.

Dieses Feature wird sowohl für Verbrauchspläne als auch für dedizierte Pläne in Workloadprofilumgebungen unterstützt.

Lernprogramme

• Weitere Informationen zum Konfigurieren privater Endpunkte in Azure Container Apps finden Sie im Tutorial Verwenden eines privaten Endpunkts mit einer Azure Container Apps-Umgebung.
• Konnektivität über eine private Verbindung mit Azure Front Door wird für Azure Container Apps unterstützt. Weitere Informationen finden Sie unter Erstellen einer privaten Verbindung mit Azure Front Door.

Überlegungen

• Private Endpunkte in Azure Container Apps unterstützen nur eingehenden HTTP-Datenverkehr. TCP-Datenverkehr wird nicht unterstützt.
• Um einen privaten Endpunkt mit einer benutzerdefinierten Domäne und einer Apex-Domäne als Datensatztyp „Hostname“ zu verwenden, müssen Sie eine private DNS-Zone mit demselben Namen wie Ihr öffentliches DNS konfigurieren. Konfigurieren Sie im Recordset die private IP-Adresse Ihres privaten Endpunkts anstelle der IP-Adresse der Container-App-Umgebung. Beim Konfigurieren Ihrer benutzerdefinierten Domäne mit CNAME bleibt das Setup unverändert. Weitere Informationen finden Sie unter Einrichten einer benutzerdefinierten Domäne mit einem vorhandenen Zertifikat.
• Das VNet Ihres privaten Endpunkts kann von dem in Ihre Container-App integrierten VNet getrennt werden.
• Sie können einen privaten Endpunkt sowohl zu neuen als auch vorhandenen Workloadprofilumgebungen hinzufügen.

Um eine Verbindung mit Ihren Container-Apps über einen privaten Endpunkt herzustellen, müssen Sie eine private DNS-Zone konfigurieren.

Umgebungssicherheit

Sie können Ihre Umgebung für den Eingangs- und Ausgangs-Netzwerkdatenverkehr vollständig schützen, indem Sie die folgenden Aktionen ausführen:

• Erstellen Sie Ihre interne Container-App-Umgebung in einer Workloadprofilumgebung. Schritte finden Sie unter Verwalten von Workloadprofilen mit der Azure CLI.

• Integrieren Sie Ihre Container-Apps in ein Application Gateway.

• Konfigurieren Sie UDR, um den gesamten Datenverkehr über die Azure Firewall weiterzuleiten.

Peer-to-Peer-Verschlüsselung in der Azure-Container-Apps-Umgebung

Azure-Container-Apps unterstützen die Peer-to-Peer-TLS-Verschlüsselung innerhalb der Umgebung. Durch Aktivieren dieses Features wird der gesamte Netzwerkdatenverkehr innerhalb der Umgebung mit einem privaten Zertifikat verschlüsselt, das innerhalb des Azure-Container-Apps-Umgebungsbereichs gültig ist. Diese Zertifikate werden automatisch von Azure Container-Apps verwaltet.

Das folgende Beispiel zeigt eine Umgebung mit aktivierter Peer-to-Peer-Verschlüsselung.

¹ Eingehender TLS-Datenverkehr wird am Eingangsproxy am Rand der Umgebung beendet.

² Datenverkehr zum und vom Eingangsproxy innerhalb der Umgebung wird mit einem privaten Zertifikat TLS-verschlüsselt und vom Empfänger entschlüsselt.

³ Aufrufe von App A an den FQDN von App B werden zuerst an den Edge-Eingangsproxy gesendet und sind TLS verschlüsselt.

⁴ Aufrufe von App A an App B mithilfe des App-B-App-Namens werden direkt an App B gesendet und TLS verschlüsselt.

Anwendungen in einer Container-Apps-Umgebung werden automatisch authentifiziert. Die Container-Apps-Laufzeit unterstützt jedoch keine Autorisierung für die Zugriffssteuerung zwischen Anwendungen, welche die integrierte Peer-to-Peer-Verschlüsselung verwenden.

Wenn Ihre Apps mit einem Client außerhalb der Umgebung kommunizieren, wird die bidirektionale Authentifizierung mit mTLS unterstützt. Weitere Informationen finden Sie unter Konfigurieren von Clientzertifikaten.

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"
            }
        }
  ...
}

Domain Name System

• Benutzerdefiniertes DNS: Wenn Ihr VNet anstelle des standardmäßigen von Azure bereitgestellten DNS-Servers einen benutzerdefinierten DNS-Server verwendet, konfigurieren Sie Ihren DNS-Server so, dass nicht aufgelöste DNS-Abfragen an 168.63.129.16 weitergeleitet werden. Rekursive Resolver von Azure verwendet diese IP-Adresse, um Anforderungen aufzulösen. Wenn Sie Ihre NSG oder Firewall konfigurieren, blockieren Sie die 168.63.129.16-Adresse nicht, andernfalls funktioniert Ihre Container-Apps-Umgebung nicht ordnungsgemäß.

• VNet-Eingangsbereich: Wenn Sie den eingehenden VNet-Bereich in einer internen Umgebung verwenden möchten, konfigurieren Sie Ihre Domänen auf eine der folgenden Arten:

  1. Nicht benutzerdefinierte Domänen: Wenn Sie nicht planen, eine benutzerdefinierte Domäne zu verwenden, erstellen Sie eine private DNS-Zone, die die Standarddomäne der Container Apps-Umgebung in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie Azure Private DNS verwenden, erstellen Sie eine private DNS-Zone, die als die Standarddomäne der Container-App (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) mit einem A-Eintrag bezeichnet wird. Der A-Datensatz enthält den Namen *<DNS Suffix> und die statische IP-Adresse der Container-Apps-Umgebung. Weitere Informationen finden Sie unter Erstellen und Konfigurieren einer Azure Private DNS-Zone.

  2. Benutzerdefinierte Domänen: Wenn Sie benutzerdefinierte Domänen verwenden und eine externe Container-Apps-Umgebung verwenden möchten, verwenden Sie eine öffentlich auflösbare Domäne, um der Container-App eine benutzerdefinierte Domäne und ein Zertifikat hinzuzufügen. Bei Verwendung einer internen Container Apps-Umgebung wird die DNS-Bindung nicht validiert, weil der Zugriff auf den Cluster nur innerhalb des virtuellen Netzwerks möglich ist. Erstellen Sie außerdem eine private DNS-Zone, die die apex-Domäne in die statische IP-Adresse der Container Apps-Umgebung auflöst. Sie können das private Azure-DNS oder Ihren eigenen DNS-Server verwenden. Wenn Sie privates Azure-DNS verwenden, erstellen Sie eine private DNS Zone mit demselben Namen wie die apex-Domäne und einen A-Datensatz, der auf die statische IP-Adresse der Container Apps-Umgebung verweist.

Die statische IP-Adresse der Container-Apps-Umgebung ist im Azure-Portal im benutzerdefinierten DNS-Suffix der Container-App-Seite oder mit dem Azure CLI-Befehl az containerapp env list verfügbar.

Verwaltete Ressourcen

Wenn Sie eine interne oder externe Umgebung in Ihrem eigenen Netzwerk bereitstellen, wird im Azure-Abonnement, in dem Ihre Umgebung gehostet wird, eine neue Ressourcengruppe erstellt. Diese Ressourcengruppe enthält Infrastrukturkomponenten, die von der Azure Container Apps-Plattform verwaltet werden. Ändern Sie nicht die Dienste in dieser Gruppe oder die Ressourcengruppe selbst.

Arbeitsauslastungsprofile-Umgebungen

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit ME_ präfixiert, und der Ressourcengruppenname kann angepasst werden, wenn Sie Ihre Container-App-Umgebung erstellen.

Für externe Umgebungen enthält die Ressourcengruppe eine öffentliche IP-Adresse, die speziell für eingehende Verbindungen mit Ihrer externen Umgebung und einem Lastenausgleich verwendet wird. Für interne Umgebungen enthält die Ressourcengruppe nur einen Lastenausgleich.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

• Eine statische öffentliche Standard-IP für den Ausgang, wenn eine interne oder externe Umgebung verwendet wird, sowie eine statische öffentliche Standard-IP für den Ausgang bei Verwendung einer externen Umgebung. Wenn Sie aufgrund von SNAT-Problemen zusätzliche ausgehende öffentliche IP-Adressen benötigen, erstellen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

• Kein Standard-Load Balancer.

• Die Kosten der verarbeiteten Daten (in GBs) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Verbrauchsumgebung

Der Name der Ressourcengruppe, die im Azure-Abonnement erstellt wurde, in dem Ihre Umgebung gehostet wird, ist standardmäßig mit MC_ präfixiert, und der Ressourcengruppenname kann nicht angepasst werden, wenn Sie eine Container-App erstellen. Die Ressourcengruppe enthält öffentliche IP-Adressen, die speziell für ausgehende Verbindungen aus Ihrer Umgebung sowie einen Lastenausgleich verwendet werden.

Zusätzlich zur standardmäßigen Azure Container Apps-Abrechnung werden Ihnen folgende Abrechnungen in Rechnung gestellt:

• Eine statische öffentliche Standard-IP für den Ausgang. Wenn Sie aufgrund von Problemen mit der Quellnetzwerkadressübersetzung (Source Network Address Translation, SNAT) zusätzliche ausgehende IPs benötigen, öffnen Sie ein Supportticket, um eine Außerkraftsetzung anzufordern.

• Zwei standardmäßige Load Balancers, wenn eine interne Umgebung verwendet wird, oder ein standardmäßiger Load Balancer, wenn eine externe Umgebung verwendet wird. Jeder Lastenausgleich hat weniger als sechs Regeln. Die Kosten der verarbeiteten Daten (in GBs) umfassen sowohl den Eingang als auch den Ausgang für Verwaltungsvorgänge.

Nächste Schritte

• Verwenden eines benutzerdefinierten virtuellen Netzwerks