View a markdown version of this page

Behebung der EKS-Schutzfeststellungen - Amazon GuardDuty
Mögliche KonfigurationsproblemeBehebung potenziell gefährdeter Kubernetes-BenutzerBehebung potenziell kompromittierter Kubernetes-PodsBehebung potenziell kompromittierter Container-ImagesBehebung potenziell kompromittierter Kubernetes-Knoten

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Behebung der EKS-Schutzfeststellungen

Amazon GuardDuty generiert Ergebnisse, die auf potenzielle Kubernetes-Sicherheitsprobleme hinweisen, wenn EKS Protection für Ihr Konto aktiviert ist. Weitere Informationen finden Sie unter EKS-Schutz. In den folgenden Abschnitten werden die empfohlenen Schritte zur Behebung für alle Szenarien beschrieben. Spezifische Behebungsmaßnahmen werden im Eintrag für diesen spezifischen Erkenntnistyp beschrieben. Sie können auf die vollständigen Informationen zu einem Erkenntnistyp zugreifen, indem Sie ihn aus der Tabelle für aktive Erkenntnistypen auswählen.

Wenn einer der EKS-Protection-Erkennungstypen erwartungsgemäß generiert wurde, können Sie erwägen, ihn hinzuzufügen, um zukünftige Warnmeldungen Unterdrückungsregeln in GuardDuty zu vermeiden.

Verschiedene Arten von Angriffen und Konfigurationsproblemen können zu Ergebnissen von GuardDuty EKS Protection führen. Dieses Handbuch hilft Ihnen dabei, die Hauptursachen von GuardDuty Ergebnissen in Ihrem Cluster zu identifizieren, und enthält geeignete Anleitungen zur Problembehebung. Im Folgenden sind die Hauptursachen aufgeführt, die zu den Ergebnissen von GuardDuty Kubernetes geführt haben:

Anmerkung

Vor Kubernetes-Version 1.14 war die system:unauthenticated Gruppe standardmäßig mit und verknüpft. system:discovery system:basic-user ClusterRoles Dies könnte unbeabsichtigten Zugriff durch anonyme Benutzer ermöglichen. Durch Cluster-Updates werden diese Berechtigungen nicht aufgehoben. Das bedeutet, dass diese Berechtigungen auch dann noch gültig sind, wenn Sie Ihren Cluster auf Version 1.14 oder höher aktualisiert haben. Wir empfehlen, dass Sie die Zuordnung dieser Berechtigungen zu der system:unauthenticated-Gruppe aufheben.

Weitere Informationen zum Entfernen dieser Berechtigungen finden Sie unter Sichern von Amazon EKS-Clustern mit bewährten Methoden im Amazon EKS-Benutzerhandbuch.

Mögliche Konfigurationsprobleme

Wenn eine Erkenntnis auf ein Konfigurationsproblem hindeutet, finden Sie im Abschnitt zur Behebung dieses Fehlers Anleitungen zur Lösung dieses speziellen Problems. Weitere Informationen finden Sie unter den folgenden Erkenntnistypen, die auf Konfigurationsprobleme hinweisen:

Behebung potenziell gefährdeter Kubernetes-Benutzer

Ein GuardDuty Ergebnis kann auf einen kompromittierten Kubernetes-Benutzer hinweisen, wenn ein in dem Ergebnis identifizierter Benutzer eine unerwartete API-Aktion ausgeführt hat. Sie können den Benutzer im Bereich Kubernetes-Benutzerdetails im Erkenntnisfenster der Konsole oder in der resource.kubernetesDetails.kubernetesUserDetails der JSON-Datei mit den Erkenntnissen identifizieren. Zu diesen Benutzerdetails gehören user name, uid und die Kubernetes-Gruppen, zu denen der Benutzer gehört.

Wenn der Benutzer mit einer IAM-Entität auf den Workload zugegriffen hat, können Sie den Access Key details-Abschnitt verwenden, um die Details einer IAM-Rolle oder eines IAM-Benutzers zu identifizieren. Sehen Sie sich die folgenden Benutzertypen und deren Anleitungen zur Problembehebung an.

Anmerkung

Sie können Amazon Detective verwenden, um die in der Erkenntnis identifizierte IAM-Rolle oder den IAM-Benutzer genauer zu untersuchen. Wählen Sie „In Detective untersuchen“, während Sie sich die Befunddetails in der GuardDuty Konsole ansehen. Wählen Sie dann den AWS Benutzer oder die Rolle aus den aufgelisteten Objekten aus, um den Vorgang in Detective zu untersuchen.

Built-in Kubernetes-Admin — Der Standardbenutzer, der von Amazon EKS der IAM-Identität zugewiesen wurde, die den Cluster erstellt hat. Dieser Benutzertyp wird durch den Benutzernamen identifiziert kubernetes-admin.

Wie Sie einem integrierten Kubernetes-Administrator den Zugriff entziehen:

OIDC-authentifizierter Benutzer – Ein Benutzer, dem der Zugriff über einen OIDC-Anbieter gewährt wurde. In der Regel hat ein OIDC-Benutzer eine E-Mail-Adresse als Benutzernamen. Sie können mit den folgenden Befehl überprüfen, ob Ihr Cluster OIDC verwendet: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Um einem OIDC-authentifizierten Benutzer den Zugriff zu entziehen:

  1. Rotieren Sie die Anmeldeinformationen dieses Benutzers im OIDC-Anbieter.

  2. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.

AWS ConfigMap -Auth-definierter Benutzer — Ein IAM-Benutzer, dem der Zugriff über ein -auth gewährt wurde. AWS ConfigMap Weitere Informationen finden Sie im Amazon EKS-Benutzerhandbuch unter Benutzer oder IAM-Rollen für Ihren Cluster https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html verwalten. Sie können ihre Berechtigungen überprüfen, indem Sie den folgenden Befehl verwenden: kubectl edit configmaps aws-auth --namespace kube-system

So entziehen Sie einem AWS ConfigMap Benutzer den Zugriff:

  1. Verwenden Sie den folgenden Befehl, um das zu öffnen ConfigMap. 

    kubectl edit configmaps aws-auth --namespace kube-system

  2. Identifizieren Sie die Rolle oder den Benutzereintrag im Abschnitt MapRoles oder MapUsers mit demselben Benutzernamen wie dem, der im Abschnitt mit den Kubernetes-Benutzerdetails Ihres Ergebnisses angegeben wurde. GuardDuty Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer in einer Erkenntnis identifiziert wurde. 

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      user name: system:node:EC2_PrivateDNSName
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::123456789012:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  3. Entfernen Sie diesen Benutzer aus dem. ConfigMap Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer entfernt wurde.

    apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

  4. Wenn es sich bei userType um einen Benutzer handelt oder um eine Rolle, die von einem Benutzer übernommen wurde:

    1. Rotieren Sie den Zugriffsschlüssel dieses Benutzers.

    2. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.

    3. Weitere Informationen finden Sie unter Mein AWS Konto ist möglicherweise kompromittiert.

Wenn die Erkenntnis keinen resource.accessKeyDetails-Abschnitt enthält, handelt es sich bei dem Benutzer um ein Kubernetes-Servicekonto.

Servicekonto – Das Servicekonto stellt eine Identität für Pods bereit und kann anhand eines Benutzernamens mit dem folgenden Format identifiziert werden: system:serviceaccount:namespace:service_account_name.

Um den Zugriff auf ein Servicekonto zu widerrufen:

  1. Rotieren Sie die Anmeldeinformationen für das Servicekonto.

  2. Lesen Sie die Hinweise zur Pod-Kompromittierung im folgenden Abschnitt.

Behebung potenziell kompromittierter Kubernetes-Pods

Wenn in dem resource.kubernetesDetails.kubernetesWorkloadDetails Abschnitt Details zu einem Pod oder einer Workload-Ressource GuardDuty angegeben sind, wurde dieser Pod oder diese Workload-Ressource potenziell gefährdet. Ein GuardDuty Ergebnis kann darauf hindeuten, dass ein einzelner Pod kompromittiert wurde oder dass mehrere Pods durch eine übergeordnete Ressource kompromittiert wurden. In den folgenden Kompromissszenarien finden Sie Anleitungen zur Identifizierung des oder der Pods, die kompromittiert wurden.

Kompromittierung einzelner Pods

Wenn es sich bei dem type-Feld innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails-Abschnitts um Pods handelt, identifiziert die Erkenntnis einzelne Pods. Das Namensfeld ist der name der Pods und das namespace-Feld ist sein Namespace.

Informationen zur Identifizierung des Worker-Knotens, auf dem die Pods ausgeführt werden, finden Sie im Amazon EKS-Handbuch mit den Best Practices unter Identifizieren der fehlerhaften Pods und des Worker-Knotens.

Pods wurden über die Workload-Ressource kompromittiert

Wenn das type-Feld innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails-Abschnitts eine Workload-Ressource identifiziert, z. B. eine Deployment, ist es wahrscheinlich, dass alle Pods innerhalb dieser Workload-Ressource kompromittiert wurden.

Informationen zur Identifizierung aller Pods der Workload-Ressource und der Knoten, auf denen sie ausgeführt werden, finden Sie im Amazon EKS-Handbuch mit den Best Practices unter Identifizieren der fehlerhaften Pods und Worker-Knoten anhand des Workload-Namens.

Pods wurden über das Servicekonto kompromittiert

Wenn GuardDuty bei einer Entdeckung im resource.kubernetesDetails.kubernetesUserDetails Abschnitt ein Servicekonto identifiziert wird, ist es wahrscheinlich, dass Pods, die das identifizierte Dienstkonto verwenden, gefährdet sind. Der durch eine Erkenntnis gemeldete Benutzername ist ein Servicekonto, wenn er das folgende Format hat: system:serviceaccount:namespace:service_account_name.

Informationen zur Identifizierung aller Pods, die das Dienstkonto verwenden, und der Knoten, auf denen sie ausgeführt werden, finden Sie im Amazon EKS-Handbuch mit den Best Practices unter Identifizieren der problematischen Pods und Worker-Nodes anhand des Dienstkontonamens.

Nachdem Sie alle gefährdeten Pods und die Knoten, auf denen sie ausgeführt werden, identifiziert haben, finden Sie im Amazon EKS Best Practices-Leitfaden unter Isolieren Sie den Pod, indem Sie eine Netzwerkrichtlinie erstellen, die den gesamten ein- und ausgehenden Datenverkehr zum Pod ablehnt.

So beheben Sie einen potenziell kompromittierten Pod:

  1. Identifizieren Sie die Schwachstelle, durch die die Pods gefährdet wurden.

  2. Implementieren Sie das Update für diese Schwachstelle und starten Sie neue Ersatz-Pods.

  3. Löschen Sie die anfälligen Pods.

    Weitere Informationen finden Sie im Amazon EKS-Leitfaden zu Best Practices unter Redeploy Compromitted Pod oder Workload-Ressource.

Wenn dem Worker-Knoten eine IAM-Rolle zugewiesen wurde, die es Pods ermöglicht, auf andere AWS Ressourcen zuzugreifen, entfernen Sie diese Rollen aus der Instance, um weiteren Schaden durch den Angriff zu verhindern. Wenn dem Pod eine IAM-Rolle zugewiesen wurde, sollten Sie ebenfalls prüfen, ob Sie die IAM-Richtlinien sicher aus der Rolle entfernen können, ohne andere Workloads zu beeinträchtigen.

Behebung potenziell kompromittierter Container-Images

Wenn ein GuardDuty Befund darauf hindeutet, dass der Pod kompromittiert wurde, könnte das zum Starten des Pods verwendete Image potenziell bösartig oder kompromittiert sein. GuardDuty Die Ergebnisse identifizieren das Container-Image innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image Felds. Sie können feststellen, ob das Image bösartig ist, indem Sie es auf Malware scannen.

So beheben Sie ein potenziell kompromittiertes Container-Image:

  1. Beenden Sie sofort die Verwendung des Images und entfernen Sie es aus Ihrem Image-Repository.

  2. Identifizieren Sie alle Pods, die das potenziell kompromittierte Image verwenden.

    Weitere Informationen finden Sie im Amazon EKS Best Practices Guide unter Identifizieren von Pods mit anfälligen oder gefährdeten Images und Worker-Knoten.

  3. Isolieren Sie die potenziell gefährdeten Pods, rotieren Sie die Anmeldeinformationen und sammeln Sie Daten für die Analyse. Weitere Informationen finden Sie im Amazon EKS Best Practices Guide unter Isolieren Sie den Pod, indem Sie eine Netzwerkrichtlinie erstellen, die den gesamten ein- und ausgehenden Datenverkehr zum Pod ablehnt.

  4. Löschen Sie alle Pods, die das potenziell kompromittierte Image verwenden.

Behebung potenziell kompromittierter Kubernetes-Knoten

Ein GuardDuty Ergebnis kann auf eine Node-Kompromittierung hinweisen, wenn der im Ergebnis identifizierte Benutzer eine Node-Identität repräsentiert oder wenn das Ergebnis auf die Verwendung eines privilegierten Containers hindeutet.

Die Benutzeridentität ist ein Worker-Knoten, wenn das Feld für den Benutzernamen das folgende Format hat: system:node:node name. Beispiel, system:node:ip-192-168-3-201.ec2.internal. Dies weist darauf hin, dass der Angreifer Zugriff auf den Knoten erhalten hat und die Anmeldeinformationen des Knotens verwendet, um mit dem Kubernetes-API-Endpunkt zu kommunizieren.

Eine Erkenntnis weist auf die Verwendung eines privilegierten Containers hin, wenn für einen oder mehrere der in der Erkenntnis aufgelisteten Container das Erkenntnisfeld resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged auf True gesetzt ist.

Gehen Sie wie folgt vor, um einen potenziell kompromittierten Knoten zu beheben:

  1. Isolieren Sie den Pod, wechseln Sie seine Anmeldeinformationen und sammeln Sie Daten für die forensische Analyse.

    Weitere Informationen finden Sie im Amazon EKS Best Practices Guide unter Isolieren Sie den Pod, indem Sie eine Netzwerkrichtlinie erstellen, die den gesamten ein- und ausgehenden Datenverkehr zum Pod ablehnt.

  2. Identifizieren Sie die Dienstkonten, die von allen Pods verwendet werden, die auf dem potenziell gefährdeten Knoten ausgeführt werden. Überprüfen Sie ihre Berechtigungen und rotieren Sie die Servicekonten bei Bedarf.

  3. Beenden Sie den potenziell gefährdeten Knoten.