Uma empresa usa o AWS Organizations e executa clusters do Amazon Elastic Kubernetes Service (Amazon EKS) em várias contas da AWS. Um engenheiro de segurança integrou o Amazon EKS com o AWS CloudTrail, armazenando trilhas em um bucket do Amazon S3 em cada conta para monitorar chamadas de API. No entanto, os logs do CloudTrail não mostram eventos de criação de pods do Kubernetes. Para visualizar eventos do Kubernetes no Amazon CloudWatch, o que o engenheiro de segurança deve fazer?

A resposta correta é habilitar os logs de componente do servidor de API do Kubernetes (plano de controle) para cada cluster EKS. O Amazon CloudTrail registra chamadas de API feitas aos serviços da AWS, mas não registra diretamente eventos internos do Kubernetes, como a criação de pods. Para visualizar esses eventos, é necessário habilitar o log do plano de controle do EKS, especificamente o log do servidor de API, que captura as interações com o cluster Kubernetes e as envia para o Amazon CloudWatch Logs. As outras opções estão incorretas porque: Configurar endpoints de VPC privados do Amazon S3 e habilitar o log de bucket do S3 não aborda a falta de eventos do Kubernetes no CloudTrail. Isso melhora a segurança e o log de acesso ao S3, mas não os logs do EKS. Habilitar o compartilhamento de recursos de origem cruzada (CORS) no bucket S3 é irrelevante para a coleta de logs do plano de controle do EKS. CORS é uma medida de segurança do navegador para acesso a recursos entre domínios. Configurar o Amazon CloudWatch e visualizar os eventos no console do CloudWatch é o destino final, mas não o passo para obter os eventos do Kubernetes. Primeiro, os logs precisam ser gerados e enviados para o CloudWatch.