Una empresa utiliza AWS Organizations y ejecuta clústeres de Amazon Elastic Kubernetes Service (Amazon EKS) en varias cuentas de AWS. Un ingeniero de seguridad ha integrado Amazon EKS con AWS CloudTrail, almacenando los registros (trails) en un bucket de Amazon S3 en cada cuenta para monitorear las llamadas a la API. Sin embargo, los logs de CloudTrail no muestran los eventos de creación de pods de Kubernetes. Para ver los eventos de Kubernetes en Amazon CloudWatch, ¿qué debe hacer el ingeniero de seguridad?

La respuesta correcta es habilitar los logs de los componentes del servidor de la API de Kubernetes (control plane) para cada clúster de EKS. Los eventos de creación de pods de Kubernetes son generados por el servidor de la API de Kubernetes, que es parte del plano de control de EKS. Para que estos eventos sean visibles en CloudWatch (o CloudTrail), es necesario habilitar explícitamente el registro del plano de control de EKS, específicamente el componente del servidor de la API. Las otras opciones son incorrectas: Configurar VPC endpoints privados de Amazon S3 y habilitar el registro de buckets de S3 no capturará los eventos internos de Kubernetes; solo afectaría la forma en que se accede y se registran las operaciones del bucket S3. Habilitar CORS en el bucket de S3 es irrelevante para la captura de logs del plano de control de EKS; CORS se relaciona con la seguridad del navegador web para solicitudes entre dominios. Configurar Amazon CloudWatch y ver los eventos en la consola de CloudWatch es el destino final, pero no el mecanismo para generar los logs de eventos de Kubernetes en primer lugar.