Best Practices für Podsicherheit in Azure Kubernetes Service (AKS)

Beim Entwickeln und Ausführen von Anwendungen in Azure Kubernetes Service (AKS) ist die Sicherheit Ihrer Pods ein wichtiger Aspekt. Ihre Anwendungen sollten auf das Prinzip der geringsten Anzahl von erforderlichen Berechtigungen ausgelegt sein. Die Sicherheit privater Daten ist für Kunden oberste Priorität. Sie möchten nicht zulassen, dass Anmeldeinformationen wie Datenbankverbindungszeichenfolgen, Schlüssel oder Geheimnisse und Zertifikate offengelegt werden, die Angreifer für bösartige Zwecke nutzen könnten. Fügen Sie sie nicht Ihrem Code hinzu, und betten Sie sie nicht in Containerimages ein. Dieser Ansatz würde ein Risiko der Offenlegung darstellen und die Möglichkeit einschränken, diese Anmeldeinformationen wechseln, wenn die Containerimages neu erstellt werden müssen.

Dieser Artikel mit bewährten Methoden konzentriert sich darauf, wie Sie Pods in AKS absichern. Folgendes wird vermittelt:

• Verwenden des Podsicherheitskontexts, um den Zugriff auf Prozesse und Dienste oder die Eskalation von Berechtigungen einzuschränken
• Authentifizieren mit anderen Azure-Ressourcen mithilfe der Microsoft Entra Workload-ID
• Anfordern und Abrufen von Anmeldeinformationen aus einem digitalen Tresor wie Azure Key Vault

Weitere Informationen finden Sie in den bewährten Methoden für Clustersicherheit und Verwaltung von Containerimages.

Absichern des Podzugriffs auf Ressourcen

Best Practices-Anleitung: Für die Ausführung als ein anderer Benutzer oder eine andere Gruppe und um den Zugriff auf die zugrunde liegenden Knotenprozesse und -dienste zu beschränken, definieren Sie Einstellungen für den Podsicherheitskontext. Weisen Sie die geringste Anzahl von erforderlichen Berechtigungen zu.

Damit Ihre Anwendungen korrekt ausgeführt werden, sollten Pods als definierter Benutzer oder definierte Gruppe und nicht als root ausgeführt werden. Mit dem securityContext für einen Pod oder Container können Sie Einstellungen wie runAsUser oder fsGroup definieren, um die entsprechenden Berechtigungen zu übernehmen. Vergeben Sie nur die erforderlichen Benutzer- oder Gruppenberechtigungen und verwenden Sie den Sicherheitskontext nicht als Mittel, um zusätzliche Berechtigungen zu erhalten. RunAsUser, die Berechtigungsausweitung und andere Linux-Funktionseinstellungen sind nur auf Linux-Knoten und -Pods verfügbar.

Wenn Sie als Nicht-Root-Benutzer ausgeführt werden, können sich Container nicht an die privilegierten Ports unter 1024 binden. In diesem Szenario können Kubernetes-Dienste verwendet werden, um die Tatsache zu verschleiern, dass eine App auf einem bestimmten Port läuft.

Ein Podsicherheitskontext kann auch zusätzliche Funktionen oder Berechtigungen für den Zugriff auf Prozesse und Dienste definieren. Die folgenden allgemeinen Sicherheitsskontextdefinitionen können festgelegt werden:

• allowPrivilegeEscalation definiert, ob der Pod root-Berechtigungen übernehmen kann. Gestalten Sie Ihre Anwendungen so, dass diese Einstellung immer auf false festgelegt ist.
• Mithilfe von Linux-Funktionen kann der Pod auf zugrunde liegende Knotenprozesse zugreifen. Gehen Sie mit der Zuweisung dieser Funktionen umsichtig um. Weisen Sie die geringste Anzahl von benötigten Berechtigungen zu. Weitere Informationen finden Sie unter Linux-Funktionen.
• Mit dem Linux-Kernelsicherheitsmodul SELinux-Bezeichnungen können Sie Zugriffsrichtlinien für Dienste, Prozesse und den Dateisystemzugriff definieren. Auch hier gilt: Weisen Sie die geringste Anzahl von benötigten Berechtigungen zu. Weitere Informationen finden Sie unter SELinux-Optionen in Kubernetes.

Das folgende Beispielpod-YAML-Manifest legt die Sicherheitskontexteinstellungen folgendermaßen fest:

• Der Pod wird als Benutzer-ID 1000 und Teil der Gruppen-ID 2000 ausgeführt.
• Es können keine Berechtigungen für die Verwendung von root eskaliert werden.
• Erlaubt Linux-Funktionen den Zugriff auf Netzwerkschnittstellen und die Echtzeituhr (Hardwareuhr) des Hosts.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Arbeiten Sie mit Ihrem Clusteroperator zusammen, um zu ermitteln, welche Sicherheitskontexteinstellungen Sie benötigen. Versuchen Sie, Ihre Anwendungen so zu gestalten, dass die vom Pod benötigten zusätzlichen Berechtigungen und Zugriffsrechte minimiert werden. Es gibt zusätzliche Sicherheitsfeatures, um den Zugriff mit AppArmor und seccomp (sicheres Computing) zu beschränken, die von Clusteroperatoren implementiert werden können. Weitere Informationen finden Sie unter Sicherer Containerzugriff auf Ressourcen.

Beschränken der Offenlegung von Anmeldeinformationen

Best Practices-Anleitung: Definieren Sie keine Anmeldeinformationen in Ihrem Anwendungscode. Verwenden Sie verwaltete Identitäten für Azure-Ressourcen, damit Ihr Pod Zugriff auf andere Ressourcen anfordern kann. Außerdem sollte ein digitaler Tresor, wie z.B. Azure Key Vault, zum Speichern und Abrufen digitaler Schlüssel und Anmeldeinformationen verwendet werden. Podseitig verwaltete Identitäten sind nur für die Verwendung mit Linux-Pods und -Containerimages vorgesehen.

Um das Risiko zu begrenzen, dass Anmeldeinformationen in Ihrem Anwendungscode offengelegt werden, vermeiden Sie die Verwendung von festen oder gemeinsamen Anmeldeinformationen. Anmeldeinformationen oder Schlüssel sollten nicht direkt in Ihrem Code enthalten sein. Wenn diese Anmeldeinformationen offengelegt werden, muss die Anwendung aktualisiert und neu bereitgestellt werden. Ein besserer Ansatz ist es, den Pods eine eigene Identität und eine Möglichkeit zu geben, sich selbst zu authentifizieren oder automatisch Anmeldeinformationen aus einem digitalen Tresor abzurufen.

Verwenden einer Microsoft Entra Workload-ID

Eine Workloadidentität ist eine Identität, die von einer auf einem Pod ausgeführten Anwendung verwendet wird, die sich selbst bei anderen Azure-Diensten authentifizieren kann, die sie unterstützen, z. B. Storage oder SQL. Sie lässt sich in die nativen Funktionen von Kubernetes integrieren, um mit externen Identitätsanbietern einen Verbund zu bilden. In diesem Sicherheitsmodell fungiert der AKS-Cluster als Tokenaussteller. Microsoft Entra ID verwendet OpenID Connect, um öffentliche Signaturschlüssel zu ermitteln und die Authentizität des Dienstkontotokens zu überprüfen, bevor es gegen ein Microsoft Entra-Token ausgetauscht wird. Ihre Workload kann das Azure SDK oder die Microsoft Authentication Library (MSAL) verwenden, um ein auf ihr Volumen projiziertes Dienstkontotoken gegen ein Microsoft Entra-Token zu tauschen, das die Azure Identity-Clientbibliothek verwendet.

Weitere Informationen zu Workloadidentitäten finden Sie unter Konfigurieren eines AKS-Clusters für die Verwendung von Microsoft Entra Workload ID mit Ihren Anwendungen

Verwenden von Azure Key Vault mit dem Secrets Store CSI-Treiber

Die Verwendung der Microsoft Entra Workload ID ermöglicht die Authentifizierung bei unterstützenden Azure-Diensten. Bei Ihren eigenen Diensten oder Anwendungen ohne verwaltete Identitäten für Azure-Ressourcen können Sie sich weiterhin mit Anmeldeinformationen oder Schlüsseln authentifizieren. Ein digitaler Tresor kann verwendet werden, um diese Geheimnisinhalte zu speichern.

Wenn Anwendungen Anmeldeinformationen benötigen, kommunizieren sie mit dem digitalen Tresor, rufen die neuesten Geheimnisinhalte ab und stellen dann die Verbindung mit dem gewünschten Dienst her. Azure Key Vault kann dieser digitale Tresor sein. Der vereinfachte Workflow zum Abrufen von Anmeldeinformationen aus Azure Key Vault unter Verwendung von verwalteten Podidentitäten ist im folgenden Diagramm dargestellt:

Mit Key Vault werden Geheimnisse wie Anmeldeinformationen, Speicherkontenschlüssel oder Zertifikate gespeichert und regelmäßig rotiert. Sie können Azure Key Vault mit einem AKS-Cluster unter Verwendung des Azure Key Vault-Anbieters für den Secrets Store CSI-Treiber integrieren. Mit dem Secrets Store CSI-Treiber kann der AKS-Cluster nativ Geheimnisinhalte aus Azure Key Vault abrufen und diese ausschließlich dem anfordernden Pod sicher zur Verfügung stellen. Arbeiten Sie mit Ihrem Clusteroperator zusammen, um den Secrets Store CSI-Treiber auf AKS-Workerknoten bereitzustellen. Sie können eine Microsoft Entra Workload ID verwenden, um Zugriff auf Key Vault anzufordern und die erforderlichen Geheimnisinhalte über den Secrets Store CSI-Treiber abzurufen.

Nächste Schritte

In diesem Artikel wurde erläutert, wie Pods gesichert werden. Wenn Sie einige dieser Best Practices implementieren möchten, lesen Sie folgende Artikel:

• Verwenden von Microsoft Entra Workload ID für Azure-Ressourcen mit AKS
• Integrieren von Azure Key Vault in AKS