Un'azienda utilizza AWS Organizations ed esegue cluster Amazon Elastic Kubernetes Service (Amazon EKS) in più account AWS. Un ingegnere della sicurezza ha integrato Amazon EKS con AWS CloudTrail, archiviando i trail in un bucket Amazon S3 in ogni account per monitorare le chiamate API. Tuttavia, i log di CloudTrail non mostrano gli eventi di creazione dei pod di Kubernetes. Per visualizzare gli eventi di Kubernetes in Amazon CloudWatch, cosa dovrebbe fare l'ingegnere della sicurezza?

L'opzione corretta è abilitare i log dei componenti del server API di Kubernetes (control plane) per ogni cluster EKS. Questo perché gli eventi di creazione dei pod di Kubernetes non sono eventi AWS API e quindi non vengono registrati da CloudTrail. Sono eventi a livello di Kubernetes che vengono generati dal server API di Kubernetes. Abilitando la registrazione del piano di controllo per EKS, questi eventi vengono inviati a CloudWatch Logs, dove possono essere monitorati. Le altre opzioni sono errate: Configurare i cluster EKS per utilizzare gli endpoint VPC privati di Amazon S3 e abilitare la registrazione dei bucket S3: Questa opzione riguarda la connettività di S3 e la registrazione degli accessi ai bucket S3, non la registrazione degli eventi interni di Kubernetes. Abilitare la condivisione delle risorse tra origini (CORS) sul bucket S3 utilizzato per la registrazione: CORS è una misura di sicurezza del browser per le richieste tra domini e non ha alcuna relazione con la registrazione degli eventi di Kubernetes. Configurare Amazon CloudWatch e visualizzare gli eventi nella console di CloudWatch: Sebbene CloudWatch sia il servizio corretto per visualizzare i log, questa opzione non risolve il problema principale della mancata acquisizione degli eventi di Kubernetes. È necessario abilitare la fonte dei log (i log del piano di controllo EKS) prima che CloudWatch possa visualizzarli.