Corriger les conclusions relatives à EKS la protection - Amazon GuardDuty
Problèmes de configuration potentielsCorriger les utilisateurs Kubernetes potentiellement compromisCorriger les pods Kubernetes potentiellement compromisCorriger les images de conteneurs potentiellement compromisesCorriger les nœuds Kubernetes potentiellement compromis

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Corriger les conclusions relatives à EKS la protection

Amazon GuardDuty génère des résultats qui indiquent les problèmes de sécurité potentiels liés à Kubernetes lorsque EKS la protection est activée pour votre compte. Pour de plus amples informations, veuillez consulter EKSProtection. Les sections suivantes décrivent les étapes de correction recommandées pour ces scénarios. Les mesures correctives spécifiques sont décrites dans l'entrée correspondant à ce type de résultat spécifique. Vous pouvez accéder aux informations complètes sur un type de résultat en le sélectionnant dans le tableau des types de résultat actifs.

Si l'un des types de résultats de EKS protection a été généré comme prévu, vous pouvez envisager d'en ajouter Règles de suppression dans GuardDuty pour éviter de futures alertes.

Différents types d'attaques et de problèmes de configuration peuvent déclencher GuardDuty EKS des constatations de protection. Ce guide vous aide à identifier les causes profondes des GuardDuty découvertes concernant votre cluster et présente des conseils de correction appropriés. Les principales causes à l'origine des découvertes de GuardDuty Kubernetes sont les suivantes :

Note

Avant la version 1.14 de Kubernetes, le system:unauthenticated groupe était associé à system:discovery et par défaut. system:basic-user ClusterRoles Cela peut autoriser un accès involontaire de la part d'utilisateurs anonymes. Les mises à jour de cluster ne révoquent pas ces autorisations, ce qui signifie que même si vous avez mis à jour votre cluster vers la version 1.14 ou ultérieure, elles peuvent toujours être en place. Nous vous recommandons de dissocier ces autorisations du groupe system:unauthenticated.

Pour plus d'informations sur la suppression de ces autorisations, consultez les meilleures pratiques de sécurité pour Amazon EKS dans le guide de EKS l'utilisateur Amazon.

Problèmes de configuration potentiels

Si un résultat indique un problème de configuration, veuillez consulter la section sur la correction de ce résultat pour obtenir des conseils sur la résolution de ce problème particulier. Pour de plus amples informations, veuillez consulter les types de résultat suivants qui indiquent des problèmes de configuration :

Corriger les utilisateurs Kubernetes potentiellement compromis

Un GuardDuty résultat peut indiquer un utilisateur Kubernetes compromis lorsqu'un utilisateur identifié dans le résultat a effectué une action inattendue. API Vous pouvez identifier l'utilisateur dans la section des informations utilisateur Kubernetes des détails d'une recherche dans la console, ou dans les resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails résultats. JSON Ces détails de l'utilisateur incluent user name, uid et les groupes Kubernetes auxquels l'utilisateur appartient.

Si l'utilisateur accédait à la charge de travail via une IAM entité, vous pouvez utiliser Access Key details cette section pour identifier les détails d'un IAM rôle ou d'un utilisateur. Consultez les types d'utilisateur suivants et leurs conseils en matière de correction.

Note

Vous pouvez utiliser Amazon Detective pour étudier plus en détail le IAM rôle ou l'utilisateur identifié dans le résultat. Lorsque vous consultez les détails de la recherche dans GuardDuty la console, choisissez Investigate in Detective. Sélectionnez ensuite un AWS utilisateur ou un rôle parmi les éléments répertoriés pour l'étudier dans Detective.

Administrateur Kubernetes intégré : utilisateur par défaut attribué par Amazon EKS à l'IAMidentité qui a créé le cluster. Ce type d'utilisateur est identifié par le nom d'utilisateur kubernetes-admin.

Pour révoquer l'accès d'un administrateur Kubernetes intégré :

OIDCutilisateur authentifié : utilisateur autorisé à accéder par l'intermédiaire d'un OIDC fournisseur. Généralement, un OIDC utilisateur possède une adresse e-mail comme nom d'utilisateur. Vous pouvez vérifier si votre cluster utilise OIDC la commande suivante : aws eks list-identity-provider-configs --cluster-name your-cluster-name

Pour révoquer l'accès d'un utilisateur OIDC authentifié :

  1. Faites pivoter les informations d'identification de cet utilisateur dans le OIDC fournisseur.

  2. Effectuez une rotation de tous les secrets auxquels l'utilisateur avait accès.

AWS-Utilisateur ConfigMap défini par -Auth : utilisateur auquel l'accès a été accordé par le biais d'un AWS-auth. IAM ConfigMap Pour plus d'informations, consultez la section Gestion des utilisateurs ou IAM des rôles pour votre cluster dans le guide de l'utilisateur de & EKS ;. Vous pouvez consulter les autorisations à l'aide de la commande suivante : kubectl edit configmaps aws-auth --namespace kube-system

Pour révoquer l'accès d'un AWS ConfigMap utilisateur :

  1. Utilisez la commande suivante pour ouvrir le ConfigMap. 

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

  2. Identifiez le rôle ou l'entrée utilisateur sous la mapUserssection mapRolesou avec le même nom d'utilisateur que celui indiqué dans la section des informations utilisateur Kubernetes de votre recherche. GuardDuty Consultez l'exemple suivant, où l'utilisateur administrateur a été identifié dans un résultat. 

    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. Supprimez cet utilisateur du ConfigMap. Consultez l'exemple suivant où l'utilisateur administrateur a été supprimé.

    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. Si le userType est Utilisateur ou un rôle assumé par un utilisateur :

    1. Effectuez une rotation de la clé d'accès de cet utilisateur.

    2. Effectuez une rotation de tous les secrets auxquels l'utilisateur avait accès.

    3. Consultez les informations dans Mon AWS compte peut être compromis pour plus de détails.

Si le résultat ne comporte pas de section resource.accessKeyDetails, l'utilisateur est un compte de service Kubernetes.

Compte de service : le compte de service fournit une identité aux pods et peut être identifié par un nom d'utilisateur au format suivant : system:serviceaccount:namespace:service_account_name.

Pour révoquer l'accès à un compte de service :

  1. Effectuez une rotation des informations d'identification du compte de service.

  2. Consultez les instructions relatives à la compromission du pod dans la section suivante.

Corriger les pods Kubernetes potentiellement compromis

Lorsque vous GuardDuty spécifiez les détails d'un pod ou d'une ressource de charge de travail dans la resource.kubernetesDetails.kubernetesWorkloadDetails section, cet espace ou cette ressource de charge de travail a été potentiellement compromis. Une GuardDuty découverte peut indiquer qu'un seul pod a été compromis ou que plusieurs pods ont été compromis par le biais d'une ressource de niveau supérieur. Consultez les scénarios de compromission suivants pour savoir comment identifier le ou les pods compromis.

Pods compromis individuels

Si le champ type dans la section resource.kubernetesDetails.kubernetesWorkloadDetails est pods, le résultat identifie un seul pod. Le champ de nom est le name des pods et le champ namespace est son espace de noms.

Pour plus d'informations sur l'identification du nœud de travail exécutant les modules, voir Identifier les modules et le nœud de travail incriminés.

Pods compromis par le biais d'une ressource de charge de travail

Si le champ type de la section resource.kubernetesDetails.kubernetesWorkloadDetails identifie une ressource de charge de travail, comme un Deployment, il est probable que tous les pods de cette ressource de charge de travail aient été compromis.

Pour plus d'informations sur l'identification de tous les pods de la ressource de charge de travail et des nœuds sur lesquels ils s'exécutent, voir Identifier les pods et nœuds de travail incriminés à l'aide du nom de la charge de travail.

Pods compromis par le biais d'un compte de service

Si un GuardDuty résultat identifie un compte de service dans la resource.kubernetesDetails.kubernetesUserDetails section, il est probable que les pods utilisant le compte de service identifié soient compromis. Le nom d'utilisateur indiqué par un résultat est un compte de service s'il a le format suivant : system:serviceaccount:namespace:service_account_name.

Pour plus d'informations sur l'identification de tous les pods à l'aide du compte de service et des nœuds sur lesquels ils s'exécutent, voir Identifier les pods et nœuds de travail incriminés à l'aide du nom du compte de service.

Une fois que vous avez identifié tous les pods compromis et les nœuds sur lesquels ils s'exécutent, consultez le guide des EKS meilleures pratiques d'Amazon pour isoler le pod, modifier ses informations d'identification et collecter des données à des fins d'analyse médico-légale.

Pour réparer un pod potentiellement compromis, procédez comme suit :

  1. Identifiez la vulnérabilité qui a compromis les pods.

  2. Mettez en œuvre le correctif pour cette vulnérabilité et démarrez de nouveaux pods de remplacement.

  3. Supprimez les pods vulnérables.

    Pour plus d'informations, consultez la section Redéploiement d'un pod ou d'une ressource de charge de travail compromise.

Si le nœud de travail s'est vu attribuer un IAM rôle permettant aux Pods d'accéder à d'autres AWS ressources, supprimez ces rôles de l'instance pour éviter que l'attaque ne cause de nouveaux dommages. De même, si un IAM rôle a été attribué au Pod, déterminez si vous pouvez supprimer les IAM politiques du rôle en toute sécurité sans affecter les autres charges de travail.

Corriger les images de conteneurs potentiellement compromises

Lorsqu'un GuardDuty résultat indique une compromission du pod, l'image utilisée pour lancer le pod peut être potentiellement malveillante ou compromise. GuardDuty les résultats identifient l'image du conteneur resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image sur le terrain. Vous pouvez déterminer si l'image est malveillante en l'analysant afin de détecter des logiciels malveillants.

Pour corriger une image de conteneur potentiellement compromise, procédez comme suit :

  1. Arrêtez immédiatement d'utiliser l'image et supprimez-la de votre référentiel d'images.

  2. Identifiez tous les pods à l'aide de l'image potentiellement compromise.

    Pour plus d'informations, voir Identifier les pods dont les images de conteneur et les nœuds de travail sont potentiellement vulnérables ou compromis.

  3. Isolez les modules potentiellement compromis, alternez les informations d'identification et collectez des données à des fins d'analyse. Pour plus d'informations, consultez le guide des EKS meilleures pratiques d'Amazon.

  4. Supprimez tous les modules utilisant l'image potentiellement compromise.

Corriger les nœuds Kubernetes potentiellement compromis

Une GuardDuty découverte peut indiquer une compromission d'un nœud si l'utilisateur identifié dans la découverte représente une identité de nœud ou si la découverte indique l'utilisation d'un conteneur privilégié.

L'identité de l'utilisateur est un composant master si le champ username a le format suivant : system:node:node name. Par exemple, system:node:ip-192-168-3-201.ec2.internal. Cela indique que l'adversaire a obtenu l'accès au nœud et qu'il utilise les informations d'identification du nœud pour communiquer avec le point de terminaison API Kubernetes.

Un résultat indique l'utilisation d'un conteneur privilégié si un ou plusieurs conteneurs répertoriés dans le résultat a le champ de résultat resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged défini sur True.

Pour remédier à un nœud potentiellement compromis, procédez comme suit :

  1. Isolez le module, modifiez ses informations d'identification et collectez des données pour une analyse médico-légale.

    Pour plus d'informations, consultez le guide des EKS meilleures pratiques d'Amazon.

  2. Identifiez les comptes de service utilisés par tous les pods exécutés sur le nœud potentiellement compromis. Vérifiez leurs autorisations et effectuez une rotation des comptes de service, si nécessaire.

  3. Mettez fin au nœud potentiellement compromis.