Übersicht über azure Kubernetes Application Network Security (Vorschau)

Von Bedeutung

AKS-Vorschaufunktionen sind auf Selbstbedienungsbasis und freiwillig verfügbar. Vorschauversionen werden „im Istzustand“ und „wie verfügbar“ bereitgestellt und sind von den Service Level Agreements und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Das Azure Kubernetes-Anwendungsnetzwerk sichert die Kommunikation zwischen Diensten in verbundenen Azure Kubernetes Service -Clustern (AKS) über automatische gegenseitige TLS (mTLS) und identitätsbasierte Autorisierung. Sie stellt Arbeitslast-Identitäten aus und verwaltet die Zertifikatausstellung, Rotation und Validierung, um eine verschlüsselte, authentifizierte und explizit autorisierte Dienst-zu-Dienst-Kommunikation ohne manuelle Konfiguration zu ermöglichen, mit FIPS-konformer Verschlüsselung während der Übertragung.

Dieser Artikel enthält eine Übersicht über die Sicherheitsfeatures im Azure Kubernetes-Anwendungsnetzwerk, einschließlich mTLS, Workloadidentitäten, Zertifikatverwaltungs- und Autorisierungsrichtlinien. Außerdem werden Einschränkungen und nächste Schritte für die Implementierung der sicheren Kommunikation in Ihrer Azure Kubernetes-Anwendungsnetzwerkumgebung beschrieben.

Einschränkungen

Zertifikate werden derzeit von einer azure Kubernetes Application Network-verwalteten Zertifizierungsstelle (Ca) ausgestellt und werden nicht an eine öffentliche Zertifizierungsstelle verkettet.

mTLS

Anwendungsnetzwerk verwendet mTLS, um identitätsbasierte, verschlüsselte Kommunikation zwischen Workloads bereitzustellen. Jeder Dienst in einem mit einem Anwendungsnetzwerk verbundenen Cluster erhält automatisch ein Zertifikat, das es ermöglicht, seine Identität zu beweisen und vertrauenswürdige, verschlüsselte Verbindungen mit anderen Diensten im selben Anwendungsnetzwerk herzustellen. Verschlüsselung während der Übertragung verwendet FIPS-kompatible Kryptografie.

mTLS-Migrationsstrategie

Das Anwendungsnetzwerk ermöglicht derzeit sowohl verschlüsselten als auch unverschlüsselten Datenverkehr. Dieser Ansatz stellt sicher, dass vorhandene Workloads weiterhin normal funktionieren, während neue oder aktualisierte Workloads automatisch mTLS für die sichere Kommunikation verwenden. Dies bedeutet, dass Sie mTLS für die sichere Kommunikation über Ihre Workloads ohne Ausfallzeiten einführen können. Nach Abschluss der Migration können Sie in den strikten Modus wechseln, sodass die Authentifizierung erzwungen wird.

Vorteile von mTLS in Azure Kubernetes Application Network

mTLS in Azure Kubernetes Application Network hilft Ihnen bei:

Schützen von Daten während der Übertragung: Der gesamte Dienst-zu-Dienst-Datenverkehr kann automatisch verschlüsselt werden (FIPS-konform).
Überprüfen der Dienstidentität: Jede Workload verfügt über ein eindeutiges vom Anwendungsnetzwerk verwaltetes Stamm- und Zwischenzertifikat.
Vorgänge vereinfachen: Das Anwendungsnetzwerk verarbeitet die Ausstellung, Erneuerung und den Widerruf von Zertifikaten für Benutzer.

Zertifikatverwaltung

Das Azure Kubernetes-Anwendungsnetzwerk stellt die vom Azure Key Vault gesicherte Zertifikatverwaltung bereit, die die für mTLS verwendeten Zertifikate ausgibt und verwaltet. Dieser Dienst richtet eine gemeinsame Vertrauensgrenze für alle AKS-Cluster ein, die mit derselben Anwendungsnetzwerkressource verbunden sind.

Das Anwendungsnetzwerk verwaltet automatisch den gesamten Lebenszyklus von Stamm- und Zwischenzertifikaten, einschließlich Bereitstellung, Erneuerung und Rotation. Dadurch wird sichergestellt, dass Arbeitsauslastungsidentitäten gültig bleiben und die Kommunikation im Laufe der Zeit sicher bleibt. Sie müssen keine Zertifikate manuell erstellen, speichern oder drehen.

Das folgende Diagramm veranschaulicht die Zertifikathierarchie im Anwendungsnetzwerk, die zeigt, wie die Stammzertifizierungsstelle, Zwischenzertifizierungsstellen und Arbeitsauslastungszertifikate strukturiert sind, um eine Vertrauensstellung über verbundene Cluster hinweg herzustellen:

Zertifikathierarchie und Lebenszyklus

Wenn eine Anwendungsnetzwerkressource erstellt wird, wird eine Stammzertifizierungsstelle bereitgestellt, die als Vertrauensanker für das Anwendungsnetzwerk dient. Wenn ein AKS-Cluster dem Anwendungsnetzwerk als Mitglied beitritt, gibt Anwendungsnetzwerk ein Zwischenzertifikat für dieses Mitglied aus, das von der Stammzertifizierungsstelle des Anwendungsnetzwerks signiert ist. Jeder verbundene AKS-Cluster verwendet sein vom Anwendungsnetzwerk verwaltetes Zwischenzertifikat, um kurzlebige Workloadzertifikate für Workloads in diesem Cluster auszustellen.

Alle Workloadzertifikate erben Vertrauen von der Stammzertifizierungsstelle des Anwendungsnetzwerks, wobei eine einheitliche Vertrauensgrenze über die Ressourcen hinweg beibehalten wird. Die Erneuerung von Stamm- und Zwischenzertifikaten wird für Benutzer transparent gehandhabt, ohne Ausfallzeiten oder Unterbrechungen zu verursachen. Diese verwaltete Hierarchie stellt eine konsistente, überprüfbare Vertrauensstellung in allen Clustern in einem Anwendungsnetzwerk sicher, während die Gültigkeit jedes Zertifikats automatisch beibehalten wird.

Aus jedem Mitgliedscluster können Sie das Stammzertifikat von der Konfigurationskarte istio-root-cert unter dem Namespace applink-system abrufen.

Zertifikattypen und Drehzeiträume

Zertifikattyp	Bereich	Gültigkeitsdauer	Drehungszeitraum	Purpose
Root CA	Azure Kubernetes-Anwendungsnetzwerk	12 Monate	6 Monate	Richtet die Vertrauensgrenze für alle Cluster ein, die mit dem Azure Kubernetes-Anwendungsnetzwerk verbunden sind.
Zwischenzertifizierungsstelle	Cluster	90 Tage	45 Tage	Erteilt Workload-Zertifikate für Workloads innerhalb dieses Clusters
Workload-Zertifikat	Arbeitsbelastung	24 Stunden	12 Stunden	Authentifiziert Workloads und sichert die Dienst-zu-Dienst-Kommunikation

Workload-Identität und Autorisierung

Da Anwendungen wachsen, müssen Dienste häufig innerhalb derselben Bereitstellung sicher über verschiedene Namespaces und Umgebungen hinweg kommunizieren. Verwalten von Zertifikaten und sicherstellen, dass jeder Dienst überprüfen kann, mit wem es spricht, kann schnell komplex und fehleranfällig werden. Das Azure Kubernetes-Anwendungsnetzwerk beseitigt diesen Aufwand, indem Arbeitsauslastungsidentitäten automatisch zugewiesen und verwaltet werden.

Innerhalb einer mit dem Anwendungsnetzwerk verbundenen Umgebung kommunizieren Workloads sicher innerhalb und über Namespaces hinweg. Um sicherzustellen, dass jeder Dienst vertrauenswürdig und authentifiziert werden kann, weist das Anwendungsnetzwerk jeder Workload eine überprüfbare Identität zu, die den Namespace und das Dienstkonto darstellt.

Jede Anwendungsnetzwerk-Workload erhält automatisch eine eindeutige Identität im SPIFFE-Format , die ihren Namespace und das Dienstkonto enthält. Die Identität ist wie folgt formatiert:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Diese Identität ist in das Workloadzertifikat eingebettet und wird verwendet, um die Identität des Diensts bei der Kommunikation mit anderen Workloads zu beweisen. Das Azure Kubernetes-Anwendungsnetzwerk verwendet dieses SPIFFE-basierte Identitätsmodell mit Istio-Autorisierungsrichtlinien, sodass Sie klare, konsistente Regeln definieren können, für die Dienste kommunizieren dürfen.

Definieren von Zugriffsrichtlinien

Mit Istio AuthorizationPolicies können Sie steuern, welche Workloads innerhalb Ihrer Umgebung kommunizieren dürfen. Mit diesen Richtlinien können Sie den Zugriff basierend auf überprüften Workloadidentitäten und nicht auf Netzwerkspeicherorten oder IP-Adressen definieren. Mit diesem Ansatz können Sie einheitliche Zugriffssteuerungen auch dann erzwingen, wenn Dienste über Knoten skaliert und verschoben werden. Sie können z. B. nur bestimmte Gateways oder Workloads aus vertrauenswürdigen Namespaces zulassen, einen Dienst aufzurufen, indem Sie auf ihre SPIFFE-Identitäten in der Prinzipalliste der Richtlinie verweisen, wie im folgenden Beispiel gezeigt:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Richtlinienentwurfsleitfaden

Beachten Sie beim Entwerfen von Autorisierungsrichtlinien die folgenden bewährten Methoden:

Geben Sie immer sowohl Namespace- als auch Dienstkonto an, um unbeabsichtigten namespaceübergreifenden Zugriff zu verhindern.
Verwenden Sie Prinzipale , um explizite Workloadidentitäten für feinkörnigen Zugriff zu definieren.
Verwenden Sie Namespaces , um bei Bedarf breitere Vertrauensgrenzen zu definieren.
Vermeiden Sie Regeln, die nur mit Dienstkontonamen ohne Namespaces übereinstimmen, da dies den Zugriff über Cluster oder Umgebungen hinweg gewähren kann.
Kombinieren Sie AuthorizationPolicies mit Kubernetes NetworkPolicies, um sowohl identitätsbasierte als auch netzwerkbasierte Isolation zu erzwingen.

Hinweis

Die Azure Kubernetes-Anwendungsnetzwerkautorisierung basiert auf der überprüften Workloadidentität und nicht auf der IP-Adresse. Dadurch wird eine konsistente Erzwingung auch dann sichergestellt, wenn Workloads über Knoten skaliert oder verschoben werden.

Durch die Kombination von vom Azure Kubernetes-Anwendungsnetzwerk verwalteten Identitäten, Zertifikaten und Richtliniensteuerelementen können Sie identitätsbasierte, am wenigsten privilegierte Dienstkommunikation implementieren, authentifizierten, verschlüsselten und explizit autorisierten Datenverkehr zwischen Workloads über Cluster hinweg sicherstellen.

Weitere Informationen zum Azure Kubernetes-Anwendungsnetzwerk finden Sie in den folgenden Artikeln:

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-03-23