Netzwerk in der Azure Container Apps-Umgebung

Artikel
11/19/2024

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.

Umgebungstyp	Unterstützte Plantypen	Beschreibung
Workloadprofile	Verbrauch, dediziert	Unterstützt benutzerdefinierte Routen (User-Defined Routes; UDR), den Ausgang über NAT Gateway und das Erstellen privater Endpunkte in der Container-App-Umgebung. Die minimale erforderliche Subnetzgröße ist `/27`.
Nur Verbrauch	Verbrauch	Unterstützt keine benutzerdefinierten Routen (User Defined Routes, UDR), den Ausgang über NAT-Gateway, Peering über ein Remotegateway oder einen anderen benutzerdefinierten Ausgang. Die minimale erforderliche Subnetzgröße ist `/23`.

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.

Zugriffsebene	Beschreibung
Extern	Ermöglicht Ihrer Container-App, öffentliche Anforderungen zu akzeptieren. Externe Umgebungen werden mit einer virtuellen IP-Adresse unter einer externen, über das Internet zugänglichen IP-Adresse bereitgestellt.
Intern	Interne Umgebungen haben keine öffentlichen Endpunkte und werden mit einer virtuellen IP-Adresse (VIP) bereitgestellt, die einer internen IP-Adresse zugeordnet ist. Der interne Endpunkt ist ein interner Azure Load Balancer (ILB); IP-Adressen werden aus der Liste der privaten IP-Adressen des benutzerdefinierten VNet ausgegeben.

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.

Hinweis

Wenn Sie Ihr eigenes virtuelles Netzwerk bereitstellen, werden zusätzliche verwaltete Ressourcen erstellt. Diese Ressourcen verursachen Kosten zu ihren zugeordneten Tarifen.

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

Diagram, wie Azure Container Apps-Umgebungen ein bestehendes V NET verwenden, oder Sie können Ihr eigenes angeben.

Hinweis

Das Verschieben von VNets zwischen verschiedenen Ressourcengruppen oder Abonnements wird nicht erlaubt, wenn das VNet von einer Container Apps-Umgebung verwendet wird.

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.

Protokoll	Port(s)
HTTP/HTTPS	80, 443

IP-Adressen werden in die folgenden Typen unterteilt:

type	Beschreibung
Öffentliche IP-Adresse für eingehenden Datenverkehr	Wird für den Anwendungsdatenverkehr in einer externen ASE und für den Verwaltungsdatenverkehr sowohl in externen als auch in internen Bereitstellungen verwendet.
Öffentliche IP-Adresse für ausgehenden Datenverkehr	Wird als „von“-IP-Adresse für ausgehende Verbindungen verwendet, die das virtuelle Netzwerk verlassen. Diese Verbindungen werden nicht über ein VPN weitergeleitet. Ausgehende IPs können sich im Laufe der Zeit ändern. Die Verwendung eines NAT-Gateways oder eines anderen Proxys für ausgehenden Datenverkehr aus einer Container-Apps-Umgebung wird nur in einer Workloadprofilumgebung unterstützt.
IP-Adresse des internen Lastenausgleichs	Diese Adresse ist nur in einer internen Bereitstellung vorhanden.

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:

Arbeitsauslastungsprofile-Umgebungen
Verbrauchsumgebung

/27 ist die minimale Subnetzgröße, die für die Integration des virtuellen Netzwerks erforderlich ist.
Ihr Subnetz muss an Microsoft.App/environments delegiert werden.
Wenn Sie eine externe Umgebung mit externem Eingang verwenden, wird der eingehende Datenverkehr über die öffentliche IP-Adresse der Infrastruktur und nicht über Ihr Subnetz geleitet.
Container-Apps reserviert automatisch 12 IP-Adressen für die Integration in das Subnetz. Die Anzahl der für die Infrastrukturintegration erforderlichen IP-Adressen variiert nicht basierend auf den Skalierungsanforderungen der Umgebung. Zusätzliche IP-Adressen werden nach den folgenden Regeln zugewiesen, je nach Art des von Ihnen verwendeten Workloadprofils werden je nach Workloadprofil Ihrer Umgebung mehr IP-Adressen zugewiesen:
- Dediziertes Workloadprofil: Wenn Ihre Container-App skaliert wird, weist jeder Knoten eine IP-Adresse zu.
- Arbeitsauslastungsprofil: Jede IP-Adresse kann für mehrere Replikate freigegeben werden. Wenn Sie planen, wie viele IP-Adressen für Ihre Anwendung benötigt werden, planen Sie 1 IP-Adresse pro 10 Replikate ein.

Wenn Sie eine Änderung an einer Überarbeitung im Einzelrevisionsmodus vornehmen, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt, um Bereitstellungen ohne Ausfallzeiten zu unterstützen. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Replikate oder Knoten für eine bestimmte Subnetzgröße aus. Die folgende Tabelle zeigt sowohl die maximal verfügbaren Adressen pro CIDR-Block als auch die Auswirkungen auf die horizontale Skalierung.

Subnetzgröße	Verfügbare IP-Adressen¹	Max. Knoten (Dediziertes Workloadprofil)²	Max. Replikate (Verbrauchs-Workloadprofil)²
/23	500	250	2\.500
/24	244	122	1.220
/25	116	58	580
/26	52	26	260
/27	20	10	100

¹ Die verfügbaren IP-Adressen sind die Größe des Subnetzes abzüglich der 12 IP-Adressen, die für die Azure-Container-Apps-Infrastruktur erforderlich sind.
² Dies ist die Rechnung für Apps im Einzelrevisionsmodus.

/23 ist die minimale Subnetzgröße, die für die Integration des virtuellen Netzwerks erforderlich ist.
Ihr Subnetz darf nicht an Dienste delegiert werden.
Die Container-Apps-Laufzeit reserviert mindestens 60 IPs für die Infrastruktur in Ihrem VNet. Die reservierte Menge kann sich auf bis zu 256 Adressen erhöhen, wenn die Anwendungen in Ihrer Umgebung wachsen.
Wenn Ihre Apps skaliert werden, wird für jedes neue Replikat eine neue IP-Adresse zugewiesen.
Wenn Sie eine Änderung an einer Überarbeitung im Einzelrevisionsmodus vornehmen, wird der erforderliche Adressraum für einen kurzen Zeitraum verdoppelt, um Bereitstellungen ohne Ausfallzeiten zu unterstützen. Dies wirkt sich auf die tatsächlichen, verfügbaren unterstützten Replikate für eine bestimmte Subnetzgröße aus.

Einschränkungen des Subnetzadressbereichs

Arbeitsauslastungsprofile-Umgebungen
Verbrauchsumgebung

Subnetzadressbereiche können sich nicht mit den folgenden Bereichen überschneiden, die von Azure Kubernetes Services reserviert sind:

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

Darüber hinaus behält sich eine Workloadprofil-Umgebung die folgenden Adressen vor:

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

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.

Hinweis

Wenn Sie UDR mit Azure Firewall in Azure Container Apps verwenden, müssen Sie bestimmte FQDNs und Service-Tags zur Erlaubnisliste für die Firewall hinzufügen. Weitere Informationen finden Sie unter Konfigurieren von UDR mit Azure Firewall.

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

Diagramm der Implementierung von UDR für 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.

Hinweis

Eine Anleitung zum Einrichten von UDR mit Container-Apps, um ausgehenden Datenverkehr mit Azure Firewall einzuschränken, finden Sie unter Vorgehensweise für Container-Apps und Azure-Firewall.

Anwendungsregeln

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

Szenarien	FQDNs	Beschreibung
Alle Szenarien	`mcr.microsoft.com`, `*.data.mcr.microsoft.com`	Diese FQDNs für die Microsoft Container Registry (MCR) werden von Azure-Container-Apps verwendet, und es müssen entweder diese Anwendungsregeln oder die Netzwerkregeln für MCR der Zulassungsliste hinzugefügt werden, wenn Sie Azure Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR)	Your-ACR-address, `*.blob.core.windows.net`, `login.microsoft.com`	Diese FQDNs sind erforderlich, wenn Sie Azure-Container-Apps mit ACR und Azure Firewall verwenden.
Azure Key Vault	Your-Azure-Key-Vault-address, `login.microsoft.com`	Diese FQDNs sind zusätzlich zu dem Diensttag erforderlich, das für die Netzwerkregel für Azure Key Vault erforderlich ist.
Verwaltete Identität	`.identity.azure.net`, `login.microsoftonline.com`, `.login.microsoftonline.com`, `*.login.microsoft.com`	Diese FQDNs sind erforderlich, wenn sie eine verwaltete Identität mit Azure Firewall in Azure-Container-Apps verwenden.
Docker Hub-Registrierung	`hub.docker.com`, `registry-1.docker.io`, `production.cloudflare.docker.com`	Wenn Sie die Docker Hub-Registrierung verwenden und über die Firewall darauf zugreifen möchten, müssen Sie diese FQDNs zur Firewall hinzufügen.

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.

Szenarien	Diensttag	Beschreibung
Alle Szenarien	`MicrosoftContainerRegistry`, `AzureFrontDoorFirstParty`	Diese Servicetags für die Microsoft Container Registry (MCR) werden von Azure-Container-Apps verwendet, und es müssen entweder diese Netzwerkregeln oder die Anwendungsregeln für MCR der Zulassungsliste hinzugefügt werden, wenn Sie Azure Container-Apps mit Azure Firewall verwenden.
Azure Container Registry (ACR)	`AzureContainerRegistry`, `AzureActiveDirectory`	Wenn Sie ACR mit Azure-Container-Apps verwenden, müssen Sie diese Anwendungsregeln konfigurieren, die von der Azure Container Registry verwendet werden.
Azure Key Vault	`AzureKeyVault`, `AzureActiveDirectory`	Diese Servicetags sind zusätzlich zum FQDN für die Anwendungsregel für Azure Key Vault erforderlich.
Verwaltete Identität	`AzureActiveDirectory`	Wenn Sie Managed Identity mit Azure-Container-Apps verwenden, müssen Sie diese Anwendungsregeln konfigurieren, die von der Managed Identity verwendet werden.

Hinweis

Für Azure-Ressourcen, die Sie mit Azure Firewall verwenden, die nicht in diesem Artikel aufgeführt sind, finden Sie in der Dokumentation zu Servicetags.

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.

Virtuelle IP-Adresse	Unterstützter öffentlicher Netzwerkzugriff	Beschreibung
Extern	`Enabled`, `Disabled`	Die Container Apps-Umgebung wurde mit einem über das Internet zugänglichen Endpunkt erstellt. Die Einstellung für öffentlichen Netzwerkzugriff bestimmt, ob Datenverkehr über den öffentlichen Endpunkt oder nur über private Endpunkte akzeptiert wird. Die Einstellung für den öffentlichen Netzwerkzugriff kann nach dem Erstellen der Umgebung geändert werden.
Intern	`Disabled`	Die Container Apps-Umgebung wurde ohne einen über das Internet zugänglichen Endpunkt erstellt. Die Einstellung für den öffentlichen Netzwerkzugriff kann nicht geändert werden, um Datenverkehr aus dem Internet zu akzeptieren.

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)

Hinweis

Dieses Feature wird für alle öffentlichen Regionen unterstützt. Government-Regionen und Regionen in China werden nicht unterstützt.

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.

Dienst	Unterressource	Name der privaten DNS-Zone
Azure Container Apps (Microsoft.App/ManagedEnvironments)	managedEnvironment	privatelink.{regionName}.azurecontainerapps.io

Umgebungssicherheit

Hinweis

Um den eingehenden Datenverkehr zu steuern, können Sie auch private Endpunkte mit einer privaten Verbindung mit Azure Front Door anstelle von Application Gateway verwenden. Dieses Feature befindet sich in der Vorschau.

Diagramm, wie Sie Ihr Netzwerk für Container-Apps vollständig sperren.

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.

Hinweis

Standardmäßig ist die Peer-to-Peer-Verschlüsselung deaktiviert. Das Aktivieren der Peer-to-Peer-Verschlüsselung für Ihre Anwendungen kann die Antwortlatenz erhöhen und den maximalen Durchsatz in Szenarien mit hoher Auslastung verringern.

Das folgende Beispiel zeigt eine Umgebung mit aktivierter Peer-to-Peer-Verschlüsselung. Diagramm, wie Datenverkehr mit aktivierter Peer-zu-Peer-Verschlüsselung verschlüsselt/entschlüsselt wird.

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

Azure-Befehlszeilenschnittstelle
ARM-Vorlage

Sie können die Peer-to-Peer-Verschlüsselung mit den folgenden Befehlen aktivieren.

Beim Erstellen:

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

Für eine vorhandene Container-App:

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

Sie können mTLS in der ARM-Vorlage für Container-Apps-Umgebungen mithilfe der folgenden Konfiguration aktivieren.

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

Freigeben über

Netzwerk in der Azure Container Apps-Umgebung

Umgebungsauswahl

Virtuelle IP-Adresse

Benutzerdefinierte VNet-Konfiguration

Verhalten des HTTP-Edgeproxys

Konfiguration des eingehenden Datenverkehrs

Portalabhängigkeiten

Ports und IP-Adressen

Subnet

Einschränkungen des Subnetzadressbereichs

Subnetzkonfiguration mit CLI

Routen

Benutzerdefinierte Routen (UDR)

Konfigurieren von UDR mit Azure Firewall

Anwendungsregeln

Netzwerkregeln

NAT-Gatewayintegration

Öffentlicher Netzwerkzugriff (Vorschau)

Privater Endpunkt (Vorschau)

Lernprogramme

Überlegungen

Umgebungssicherheit

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

Domain Name System

Verwaltete Ressourcen

Arbeitsauslastungsprofile-Umgebungen

Verbrauchsumgebung

Nächste Schritte

Feedback

Zusätzliche Ressourcen