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.
Conditions requises pour la prise en charge des clusters Amazon EKS
Cette section inclut les prérequis pour surveiller le comportement d'exécution de vos ressources Amazon EKS. Ces prérequis sont essentiels pour que l' GuardDuty agent fonctionne comme prévu. Une fois ces conditions préalables remplies, consultez la section Activer la surveillance du GuardDuty temps d'exécution pour commencer à surveiller vos ressources.
Prise en charge des fonctionnalités d'Amazon EKS
Runtime Monitoring prend en charge les clusters Amazon EKS exécutés sur des instances Amazon EC2 et Amazon EKS Auto Mode.
Runtime Monitoring ne prend pas en charge les clusters Amazon EKS dotés de nœuds hybrides Amazon EKS, ni ceux qui s'exécutent sur AWS Fargate.
Pour plus d'informations sur ces fonctionnalités d'Amazon EKS, consultez Qu'est-ce qu'Amazon EKS ? dans le guide de l'utilisateur Amazon EKS .
Validation des exigences architecturales
La plate-forme que vous utilisez peut avoir un impact sur GuardDuty la manière dont les agents de sécurité GuardDuty prennent en charge la réception des événements d'exécution de vos clusters EKS. Vous devez confirmer que vous utilisez l'une des plateformes vérifiées. Si vous gérez l' GuardDuty agent manuellement, assurez-vous que la version de Kubernetes prend en charge la version de l' GuardDuty agent actuellement utilisée.
Plateformes vérifiées
La distribution du système d'exploitation, la version du noyau et l'architecture du processeur affectent le support fourni par l'agent GuardDuty de sécurité. La prise en charge du noyau incluteBPF, Tracepoints etKprobe. Pour les architectures CPU, Runtime Monitoring prend en charge AMD64 (x64) et ARM64 (Graviton2 et versions ultérieures). 1
Le tableau suivant présente la configuration vérifiée pour le déploiement de l'agent de GuardDuty sécurité et la configuration d'EKS Runtime Monitoring.
| Distribution du système d'exploitation 2 | Version du noyau 3 | Version de Kubernetes prise en charge |
|---|---|---|
|
Fusée à bouteilles |
5,4, 5,10, 5,15 et 6,1 4 |
V1.23 à v1.36 |
|
Ubuntu |
5,4, 5,10, 5,15, 6,1, 6,15, 6,16, 6,17, 6,18 4 |
V1.21 à v1.36 |
|
Amazon Linux 2 |
5,4, 5,10, 5,15 et 6,1 4 |
V1.21 à v1.36 |
|
Amazon Linux 2023 5 |
5,4, 5,10, 5,15, 6,1, 6,8, 6,12 4 |
V1.21 à v1.36 |
|
RedHat 9,4 |
5,14 4 |
V1.21 à v1.36 |
|
Fedora 34 |
5,11 et 5,17 |
V1.21 à v1.36 |
|
Fedora 40 |
6.8 |
V1,28 à V1,36 |
|
Fedora 41 |
6,12 |
V1,28 à V1,36 |
|
CentOS Stream 9 |
5,14 |
V1.21 à v1.36 |
-
La surveillance de l'exécution pour les clusters Amazon EKS ne prend pas en charge les instances Graviton de première génération, telles que les types d'instances A1.
-
Prise en charge de différents systèmes d'exploitation : GuardDuty a vérifié la prise en charge de Runtime Monitoring pour la distribution d'exploitation répertoriée dans le tableau précédent. Bien que l'agent GuardDuty de sécurité puisse s'exécuter sur des systèmes d'exploitation non répertoriés dans le tableau précédent, l' GuardDuty équipe ne peut garantir la valeur de sécurité attendue.
-
Quelle que soit la version du noyau, vous devez définir l'
CONFIG_DEBUG_INFO_BTFindicateur sury(c'est-à-dire vrai). Cela est nécessaire pour que l'agent GuardDuty de sécurité puisse fonctionner comme prévu. -
Actuellement, avec la version Kernel
6.1, GuardDuty impossible de générer GuardDuty Types de résultats de surveillance de l'exécution des fichiers liés àÉvénements du système de noms de domaine (DNS). -
Runtime Monitoring prend en charge AL2023 avec la sortie de l'agent de GuardDuty sécurité v1.6.0 et versions ultérieures. Pour de plus amples informations, veuillez consulter GuardDuty versions des agents de sécurité pour les ressources Amazon EKS.
Versions de Kubernetes prises en charge par l'agent de sécurité GuardDuty
Le tableau suivant présente les versions de Kubernetes pour vos clusters EKS qui sont prises en charge par GuardDuty l'agent de sécurité.
| Version de l'agent GuardDuty de sécurité complémentaire Amazon EKS | Version de Kubernetes |
|---|---|
|
v1.16.0 (dernière version - v1.16.0-eksbuild.2) |
1,28 à 1,36 |
|
v1.15.0 (dernière version - v1.15.0-eksbuild.2) |
1,28 à 1,36 |
|
v1.12.2 (dernière version - v1.12.2-eksbuild.2) |
1,28 à 1,36 |
|
v1.12.1 (dernière version - v1.12.1-eksbuild.4) |
1,28 à 1,35 |
|
v1.11.0 (dernière version - v1.11.0-eksbuild.4) |
1,28 à 1,34 |
|
v1.10.0 (dernière version - v1.10.0-eksbuild.2) |
1,21 à 1,33 |
|
v1.9.0 (dernière version - v1.9.0-eksbuild.2) v1.8.1 (dernière version - v1.8.1-eksbuild.2) |
1,21 à 1,32 |
|
v1.7.1 V1.7.0 v1.6.1 |
1,21 à 1,31 |
|
v1.6.0 V1.5.0 v1.4.1 V1.4.0 v1.3.1 |
1,21 à 1,29 |
|
v1.3.0 v1.2.0 |
1,21 à 1,28 |
|
v1.1.0 |
1,21 à 1,26 |
|
v1.0.0 |
1,21 à 1,25 |
Le support standard de certaines versions des agents de GuardDuty sécurité ne sera plus pris en charge.
Pour plus d'informations sur les versions des versions de l'agent, consultezGuardDuty versions des agents de sécurité pour les ressources Amazon EKS.
Limites de processeur et de mémoire
Le tableau suivant indique les limites de processeur et de mémoire pour le module complémentaire Amazon EKS pour GuardDuty (aws-guardduty-agent).
| Paramètre | Limite minimum | Limite maximum |
|---|---|---|
CPU |
200 m |
1 000 m |
Mémoire |
256 milles |
1 024 milles |
Lorsque vous utilisez le module complémentaire Amazon EKS version 1.5.0 ou supérieure, il est GuardDuty possible de configurer le schéma du module complémentaire pour les valeurs de votre processeur et de votre mémoire. Pour plus d'informations sur la plage configurable, consultezParamètres et valeurs configurables.
Une fois que vous avez activé la surveillance d'exécution EKS et évalué l'état de couverture de vos clusters EKS, vous pouvez configurer et consulter les métriques d'aperçu des conteneurs. Pour de plus amples informations, veuillez consulter Configuration de la surveillance du processeur et de la mémoire.
Validation de la politique de contrôle des services de votre organisation
Si vous avez mis en place une politique de contrôle des services (SCP) pour gérer les autorisations dans votre organisation, vérifiez que la limite des autorisations n'est pas restrictiveguardduty:SendSecurityTelemetry. GuardDuty nécessite cette autorisation pour prendre en charge la surveillance de l'exécution sur différents types de ressources.
Si votre compte est un compte de membre, contactez l'administrateur délégué associé. Pour plus d'informations sur la gestion des SCP pour votre organisation, consultez la section Politiques de contrôle des services (SCP).
