Behebung von EKS Schutzfeststellungen - Amazon GuardDuty
Mögliche KonfigurationsproblemeBehebung potenziell gefährdeter Kubernetes-BenutzerBehebung potenziell gefährdeter Kubernetes-PodsBehebung potenziell gefährdeter Container-ImagesBehebung potenziell gefährdeter 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 von EKS Schutzfeststellungen

Amazon GuardDuty generiert Ergebnisse, die auf potenzielle Kubernetes-Sicherheitsprobleme hinweisen, wenn der EKS Schutz für Ihr Konto aktiviert ist. Weitere Informationen finden Sie unter EKSSchutz. 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 Schutzsuchtypen erwartungsgemäß generiert wurde, können Sie erwägen, ihn hinzuzufügen, Unterdrückungsregeln in GuardDuty um future Warnmeldungen zu verhindern.

Verschiedene Arten von Angriffen und Konfigurationsprobleme können Sicherheitslücken auslösen GuardDuty EKS. Dieser Leitfaden hilft Ihnen dabei, die Hauptursachen von Sicherheitslücken in GuardDuty Ihrem Cluster zu ermitteln, und enthält entsprechende 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 Bewährte Sicherheitsmethoden für Amazon EKS im EKSAmazon-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 Befund kann auf einen kompromittierten Kubernetes-Benutzer hinweisen, wenn ein im Ergebnis identifizierter Benutzer eine unerwartete Aktion ausgeführt hat. API Sie können den Benutzer in den Kubernetes-Benutzerdetails der Ergebnisdetails in der Konsole oder in den Ergebnissen identifizieren. resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails JSON Zu diesen Benutzerdetails gehören user name, uid und die Kubernetes-Gruppen, zu denen der Benutzer gehört.

Wenn der Benutzer über eine 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 Benutzers zu identifizieren. Sehen Sie sich die folgenden Benutzertypen und deren Anleitungen zur Problembehebung an.

Anmerkung

Sie können Amazon Detective verwenden, um die im Ergebnis identifizierte IAM Rolle oder den Benutzer weiter zu untersuchen. Wählen Sie beim Anzeigen der Ergebnisdetails in der GuardDuty Konsole Investigate in Detective aus. Wählen Sie dann einen AWS Benutzer oder eine Rolle aus den aufgelisteten Elementen aus, um sie in Detective zu untersuchen.

Integrierter 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:

OIDCauthentifizierter 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 OIDC mit dem folgenden Befehl überprüfen, ob Ihr Cluster verwendet: aws eks list-identity-provider-configs --cluster-name your-cluster-name

Um einem OIDC authentifizierten Benutzer den Zugriff zu entziehen:

  1. Wechseln Sie die Anmeldeinformationen dieses Benutzers im OIDC Anbieter ab.

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

AWS ConfigMap -Auth-definierter Benutzer — Ein IAM Benutzer, dem über eine AWS-Auth Zugriff gewährt wurde. ConfigMap Weitere Informationen finden Sie unter Benutzer oder IAM Rollen für Ihren Cluster verwalten im &EKS; -Benutzerhandbuch. Sie können ihre Berechtigungen überprüfen, indem Sie den folgenden Befehl verwenden: kubectl edit configmaps aws-auth --namespace kube-system

Um einem AWS ConfigMap Benutzer den Zugriff zu entziehen:

  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 mapUsersAbschnitt mapRolesoder mit demselben Benutzernamen wie im Abschnitt Kubernetes-Benutzerdetails Ihres GuardDuty Ergebnisses. 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 in den Informationen AWS unter Mein Konto ist möglicherweise gefährdet.

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 gefährdeter Kubernetes-Pods

Wenn in dem resource.kubernetesDetails.kubernetesWorkloadDetails Abschnitt Details zu einer Pod- oder Workload-Ressource GuardDuty angegeben sind, wurde diese Pod- oder Workload-Ressource potenziell kompromittiert. Ein GuardDuty Ergebnis kann darauf hinweisen, dass ein einzelner Pod kompromittiert wurde oder dass mehrere Pods durch eine Ressource auf höherer Ebene 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 unter Identifizieren der betroffenen 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 unter Identifizieren der problematischen Pods und Worker-Knoten anhand des Workload-Namens.

Pods wurden über das Servicekonto kompromittiert

Wenn aufgrund eines GuardDuty Befundes ein Dienstkonto in dem resource.kubernetesDetails.kubernetesUserDetails Abschnitt identifiziert wird, ist es wahrscheinlich, dass Pods, die das identifizierte Dienstkonto verwenden, kompromittiert wurden. 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 unter Identifizieren der fehlerhaften Pods und Worker-Knoten anhand des Dienstkontonamens.

Nachdem Sie alle kompromittierten Pods und die Knoten, auf denen sie ausgeführt werden, identifiziert haben, finden Sie im EKSAmazon-Best-Practice-Leitfaden Informationen zum Isolieren des Pods, zum Wechseln seiner Anmeldeinformationen und zum Sammeln von Daten für forensische Analysen.

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 unter Kompromittierte Pod- oder Workload-Ressource erneut bereitstellen.

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 gefährdeter Container-Images

Wenn ein GuardDuty Ergebnis auf eine Pod-Kompromittierung hindeutet, könnte das Image, das zum Starten des Pods verwendet wurde, potenziell bösartig oder kompromittiert sein. GuardDuty Die Ergebnisse identifizieren das Container-Image innerhalb des resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image Feldes. 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 gefährdete Image verwenden.

    Weitere Informationen finden Sie unter Identifizieren von Pods mit potenziell anfälligen oder gefährdeten Container-Images und Worker-Knoten.

  3. Isolieren Sie die potenziell gefährdeten Pods, wechseln Sie die Anmeldeinformationen ab und sammeln Sie Daten für die Analyse. Weitere Informationen finden Sie im Amazon EKS Best Practices-Leitfaden.

  4. Löschen Sie alle Pods, die das potenziell gefährdete Image verwenden.

Behebung potenziell gefährdeter Kubernetes-Knoten

Ein GuardDuty Befund kann auf eine Kompromittierung eines Knotens hinweisen, wenn der im Befund identifizierte Benutzer eine Knotenidentität darstellt 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 deutet darauf hin, dass der Angreifer Zugriff auf den Knoten erlangt hat und die Anmeldeinformationen des Knotens verwendet, um mit dem API Kubernetes-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.

So beheben Sie einen potenziell kompromittierten Knoten:

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

    Weitere Informationen finden Sie im Amazon EKS Best Practices-Leitfaden.

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

  3. Beenden Sie den potenziell gefährdeten Knoten.