Implementieren von Sicherheitskontrollen für Azure Container Apps
Azure Container Apps bietet eine verwaltete Plattform zum Ausführen von containerisierten Microservices, APIs und ereignisgesteuerten Workloads. Im Gegensatz zu Container Instances, die einzelne Workloads isoliert ausführen, gruppieren Container-Apps-Umgebungen mehrere Dienste zusammen und teilen die Infrastruktur. Für dieses gemeinsame Modell ist eine bewusste Konfiguration erforderlich, um zu verhindern, dass Dienste mit unterschiedlichen Vertrauensebenen miteinander beeinträchtigt werden, und um sicherzustellen, dass interne Dienste nicht unbeabsichtigt dem Internet ausgesetzt sind.
Verstehen Sie die Container-Apps-Umgebung als Isolationsgrenze
Jede Container-App wird in einer Container-Apps-Umgebung ausgeführt. Die Umgebung definiert das Subnetz des virtuellen Netzwerks, den freigegebenen Log Analytics-Arbeitsbereich und die Dapr-Konfiguration, die von allen Apps in der Umgebung gemeinsam genutzt werden. Apps innerhalb derselben Umgebung können über einen privaten internen Adressraum kommunizieren. Apps in verschiedenen Umgebungen sind standardmäßig isoliert.
Diese Architektur hat eine direkte Sicherheitsimplikation: Apps mit unterschiedlichen Vertrauensstufen sollten keine Umgebung teilen. Eine E-Commerce-Plattform, die sowohl öffentlich zugängliche APIs als auch interne Back-End-Dienste ausführt, sollte separate Umgebungen verwenden – die Back-End-Umgebung, die für den reinen VNet-Zugriff konfiguriert ist, die Frontend-Umgebung für den externen Eingangsbereich. Das Mischen von Diensten mit unterschiedlichen Expositionsanforderungen in einer einzigen Umgebung bedeutet, dass eine falsch konfigurierte Eingangsregel für eine App andere Dienste in derselben Umgebung verfügbar machen könnte.
Zuweisen verwalteter Identitäten zu Container-Apps
Container-Apps unterstützen sowohl vom System zugewiesene als auch vom Benutzer zugewiesene verwaltete Identitäten. Verwenden Sie verwaltete Identitäten, um Containerimages aus Azure Container Registry abzurufen, Geheimnisse aus Azure Key Vault abzurufen, Azure OpenAI- und Azure AI Foundry -Endpunkte aufzurufen und mit jedem anderen Azure-Dienst zu interagieren, der die Microsoft Entra-Authentifizierung unterstützt.
So weisen Sie einer Container-App eine vom System zugewiesene Identität zu:
az containerapp identity assign \
--name <app-name> \
--resource-group <rg> \
--system-assigned
Gewähren Sie der Identität die benötigten Rollen. Für den Image-Abruf aus Azure Container Registry (ACR):
az role assignment create \
--assignee <managed-identity-principal-id> \
--role AcrPull \
--scope /subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.ContainerRegistry/registries/<registry-name>
Vom Benutzer zugewiesene Identitäten sind nützlich, wenn mehrere Container-Apps dieselben Berechtigungen nutzen. Erstellen Sie die Identität einmal, weisen Sie sie den erforderlichen Rollen zu, und fügen Sie sie an jede App an, die sie benötigt. Dies ist effizienter als das Erstellen separater vom System zugewiesener Identitäten, die jeweils dieselben Rollenzuweisungen benötigen.
Steuern des Eingangszugriffs
Ingress bestimmt, wie eine Container-App Netzwerkdatenverkehr empfängt. Es stehen zwei Eingangsmodi zur Verfügung:
- Externer Ausgang: Auf die App kann über das öffentliche Internet zugegriffen werden. Es erhält einen öffentlichen FQDN und kann über Azure Front Door oder Azure Application Gateway bereitgestellt werden.
- Interner Eingang: Auf die App kann nur innerhalb der Container-Apps-Umgebung oder aus anderen Ressourcen im selben virtuellen Netzwerk zugegriffen werden. Es wird keine öffentliche IP-Adresse zugewiesen.
Legen Sie Back-End-APIs, Warteschlangenprozessoren und Datendienste auf einen internen Eingangswert fest. Nur Dienste, die tatsächlich von außerhalb Ihres Netzwerks erreichbar sein müssen, sollten externen Ingress verwenden. In der Contoso Retail-Umgebung waren alle Dienste auf „extern“ gesetzt, wodurch interne Dienste ohne geschäftlichen Grund im öffentlichen Internet offengelegt wurden – interner Ingress beseitigt diese Gefährdung mit einer einzigen Konfigurationsänderung.
Sie können den externen Eingangsmodus weiter einschränken, indem Sie IP-Sicherheitseinschränkungen verwenden. Konfigurieren Sie eine Zulassungsliste mit vertrauenswürdigen IP-Adressen oder CIDR-Bereichen:
az containerapp ingress access-restriction set \
--name <app-name> \
--resource-group <rg> \
--rule-name allow-corporate \
--ip-address 203.0.113.0/24 \
--action Allow
Verwenden Sie für Apps für authentifizierte Benutzer die integrierte Authentifizierungs-Middleware (häufig EasyAuth genannt), um die Anmeldung mit Microsoft Entra ID zu erzwingen, bevor eine Anforderung Ihren Containercode erreicht. Konfigurieren Sie sie im Azure-Portal unter Authentication in Ihrer Container-App oder mit der CLI. Die Middleware fängt nicht authentifizierten Anfragen ab und leitet Benutzer zur Microsoft Entra ID-Anmeldeseite weiter. Es sind keine Anwendungscodeänderungen erforderlich.
Geheimnisse mit Key Vault-Verweisen verwalten
Container Apps bieten zwei Mechanismen zum Verwalten von Geheimnissen.
Geheime Schlüssel auf Umgebungsebene werden innerhalb der Container-Apps-Plattform gespeichert und zur Laufzeit als Umgebungsvariablen oder Volume-Mounts eingefügt. Sie eignen sich für Konfigurationswerte, die sich selten ändern und keine zentrale Rotation oder Auditierung erfordern.
Key Vault-Verweise verweisen anhand des URI auf ein Geheimnis in Azure Key Vault und rufen den Wert zur Laufzeit mithilfe der verwalteten Identität der App ab. Der geheime Wert wird nie in der Container-Apps-Konfiguration gespeichert – die Plattform ruft ihn jedes Mal ab, wenn er benötigt wird. Dies ist der empfohlene Ansatz für Anmeldeinformationen, Verbindungszeichenfolgen und jeden Wert, der zentral überprüft oder rotiert werden muss.
So Verweisen Sie auf ein Schlüsseltresorgeheimnis:
az containerapp secret set \
--name <app-name> \
--resource-group <rg> \
--secrets "db-connection=keyvaultref:<key-vault-secret-uri>,identityref:<managed-identity-resource-id>"
Wenn Sie den geheimen Wert in Key Vault drehen, ruft die Container-App den aktualisierten Wert beim nächsten Containerneustart ab. Sie aktualisieren die Container-App-Konfiguration nicht, um das neue Secret zu übernehmen – die Key Vault-URI bleibt gleich; nur der Wert, auf den sie verweist, ändert sich.
Sichere Service-to-Service-Kommunikation mit Dapr
Dapr (Distributed Application Runtime) ist ein CNCF-Projekt (Cloud Native Computing Foundation), das Funktionen auf Anwendungsebene über eine Sidecar-Architektur bereitstellt. In Azure Container Apps wird beim Aktivieren von Dapr zusätzlich zu Ihrem Anwendungscontainer ein Sidecar-Container hinzugefügt. Das Sidecar verarbeitet Dienst-zu-Dienst-Aufrufe, Pub/Sub-Nachrichten, Zustandsverwaltung und externe Bindungen – Ihre Anwendung kommuniziert mit dem Sidecar über localhost anstatt direkt mit anderen Diensten oder Infrastruktur.
Das wichtigste Sicherheitsverhalten, das Dapr bereitstellt, ist gegenseitiges TLS (mTLS). Dapr Sidecars verhandeln und erzwingen mTLS automatisch für alle Dienst-zu-Dienst-Kommunikation innerhalb der Container-Apps-Umgebung. Der Datenverkehr zwischen zwei Dapr-fähigen Apps wird während der Übertragung ohne erforderliche Konfiguration im Anwendungscode verschlüsselt. Sie verwalten keine Zertifikate oder implementieren TLS in Ihren Diensten – Dapr behandelt sie.
Wenn Sie eine Container-Apps-Umgebung bewerten, die Dapr verwendet, überprüfen Sie die folgenden Sicherheitskonfigurationen:
- Geltungsbereich von Komponenten: Dapr-Komponenten – z. B. Statusspeicher, Pub/Sub-Broker und Geheimnisspeicher – können auf bestimmte Apps beschränkt werden. Ohne Bereichsdefinition kann jede Dapr-fähige App in der Umgebung eine beliebige Komponente verwenden. Wenden Sie die Bereichsdefinition auf App-Ebene an, um jede Komponente auf die Apps zu beschränken, die sie legitim benötigen.
- Secret Store-Konfiguration: Konfigurieren Sie die Komponente des geheimen Speichers von Dapr, um Azure Key Vault zu verwenden, die von der verwalteten Identität der App unterstützt wird. Dadurch werden hartcodierte Anmeldeinformationen in der Dapr-Komponentenkonfiguration entfernt.
- Dapr-Dashboard-Freigabe: Das Dapr-Dashboard bietet Einblick in laufende Dapr-Komponenten und aktive Dienste. Vergewissern Sie sich, dass sie nicht über einen externen Ausgang verfügbar gemacht wird– sie sollte nur innerhalb der Umgebung oder über eine private Netzwerkverbindung zugänglich sein.
Tip
Eine vollständige Übersicht über die Dapr-Integration in Container-Apps, einschließlich der Konfiguration von Komponenten und Aktivieren von Dapr für eine vorhandene App, finden Sie unter Dapr-Integration mit Azure Container Apps.