Correction des résultats de la surveillance des journaux d'audit EKS

Amazon GuardDuty génère des résultats qui indiquent les problèmes de sécurité potentiels liés à Kubernetes lorsque la surveillance du journal d'audit EKS est activée pour votre compte. Pour de plus amples informations, veuillez consulter Surveillance des journaux d'audit EKS. 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ésultat de surveillance des journaux d'audit EKS a été généré comme prévu, vous pouvez envisager d'ajouter une Règles de suppression pour éviter de futures alertes.

Différents types d'attaques et de problèmes de configuration peuvent déclencher les découvertes de GuardDuty Kubernetes. 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 :

• Problèmes de configuration potentiels

• Corriger les utilisateurs Kubernetes potentiellement compromis

• Corriger les pods Kubernetes potentiellement compromis

• Corriger les nœuds Kubernetes potentiellement compromis

• Corriger les images de conteneurs potentiellement compromises

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 l'utilisateur Amazon EKS.

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 :

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• Toute découverte qui se termine par SuccessfulAnonymousAccess

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 d'API inattendue. Vous pouvez identifier l'utilisateur dans la section Détails de l'utilisateur Kubernetes des détails d'un résultat dans la console, ou dans les resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails des 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 entité IAM, vous pouvez utiliser la section Access Key details pour identifier les détails d'un utilisateur ou d'un rôle IAM. 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 l'utilisateur ou le rôle IAM 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'identité IAM 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é :

• Identifiez le userType dans la section Access Key details.

  • Si le userType est Rôle et que le rôle appartient à un rôle d'instance EC2 :

    • Identifiez cette instance, puis suivez les instructions fournies dans Corriger une instance Amazon EC2 potentiellement compromise.

  • 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.

Utilisateur authentifié OIDC : utilisateur auquel l'accès a été accordé par un fournisseur OIDC. Généralement, le nom d'utilisateur OIDC est une adresse e-mail. Vous pouvez vérifier si votre cluster utilise OIDC avec la commande suivante : aws eks list-identity-provider-configs --cluster-name your-cluster-name .

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

1. Effectuez une rotation des informations d'identification de cet utilisateur dans le fournisseur OIDC.

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

AWS-Utilisateur ConfigMap défini par -Auth : utilisateur IAM auquel l'accès a été accordé par le biais d'un -auth. AWSConfigMap Pour plus d'informations, veuillez consulter Autorisation d'un principal IAM à accéder à votre cluster dans le guide de l'utilisateur &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 dans la section MapRoles ou MapUsers 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 meilleures pratiques d'Amazon EKS 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 :

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 un rôle IAM a été attribué au nœud de travail qui permet 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 rôle IAM a été attribué au pod, déterminez si vous pouvez supprimer les politiques IAM 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 meilleures pratiques Amazon EKS.

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 de l'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 meilleures pratiques Amazon EKS.

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.