Une entreprise utilise AWS Organizations et exécute des clusters Amazon Elastic Kubernetes Service (Amazon EKS) dans plusieurs comptes AWS. Un ingénieur en sécurité a intégré Amazon EKS à AWS CloudTrail, stockant les journaux d'activité dans un compartiment Amazon S3 dans chaque compte pour surveiller les appels d'API. Cependant, les journaux CloudTrail n'affichent pas les événements de création de pods Kubernetes. Pour afficher les événements Kubernetes dans Amazon CloudWatch, que doit faire l'ingénieur en sécurité ?

La bonne réponse est d'activer les journaux des composants du serveur d'API Kubernetes (plan de contrôle) pour chaque cluster EKS. Les événements Kubernetes, tels que la création de pods, sont générés par le plan de contrôle EKS et ne sont pas capturés par défaut par CloudTrail. CloudTrail enregistre les appels d'API AWS, tandis que les journaux du plan de contrôle EKS fournissent des informations détaillées sur les activités internes de Kubernetes. L'activation de ces journaux permettra de les envoyer à CloudWatch Logs, où ils pourront être surveillés. Les autres options sont incorrectes : Configurer les clusters EKS pour utiliser des points de terminaison VPC Amazon S3 privés et activer la journalisation des compartiments S3 n'affecte pas la capture des événements Kubernetes, mais plutôt la manière dont les clusters accèdent à S3 et la journalisation des accès au compartiment S3 lui-même. Activer le partage de ressources entre origines (CORS) sur le compartiment S3 utilisé pour la journalisation est pertinent pour l'accès web aux objets S3, pas pour la collecte des journaux du plan de contrôle EKS. Configurer Amazon CloudWatch et afficher les événements dans la console CloudWatch est une étape nécessaire après l'activation des journaux, mais cela ne résout pas le problème de la collecte des événements Kubernetes en premier lieu.