¿Quién iba a decir que llegaríamos al cuarto post?🥳¡Increíble!🥳Pero, aquí entre nosotros, hemos decidido hacer un pacto con la pausa y bajarle un poco al estrés. A partir de ahora, intentaremos publicar de forma mensual para que nadie termine en la locura, nosotros incluidos!🕵️
En nuestro último post, exploramos cómo desplegar sin miedo con un ejemplo sobre App Runner. Sin embargo, en estos últimos meses, ha surgido un susurro constante en nuestras conversaciones técnicas:

🚨EKS Pod Identities🚨
Esta nueva funcionalidad se presenta como una herramienta que simplifica la configuración de permisos de IAM para aplicaciones Kubernetes en AWS. Como era de esperar, nos sumergiremos para comprender cómo funciona y compartiremos algunas novedades adicionales que se han publicado en referencia al servicio de EKS.
¡Así que, vamos a por ello! 🚀💻

Requisitos

• Clúster EKS
• El rol de nodo debe tener permisos para que el agente realice la acción de AssumeRoleForPodIdentity en la API de autenticación de EKS
• Bucket S3

https://docs.aws.amazon.com/es_es/eks/latest/userguide/pod-id-agent-setup.html

Para este ejemplo, crearemos un rol de IAM con permisos de lectura sobre S3 y configuraremos todo lo necesario para que un pod de prueba pueda asumir este rol y realizar una lista (list) en un bucket de S3. En este caso, hemos creado un bucket con el nombre "test-pod-demo".

Accedemos a nuestro clúster y añadimos el complemento "Amazon EKS Pod Identity Agent".


Una vez añadimos el complemento al clúster, los pods asociados a este se desplegarán. Deberemos verificar que se han desplegado correctamente revisando su estado.

Creamos el rol de IAM “iam-pod-identities-demo” con los permisos necesarios.



Una vez creado el rol de IAM, regresamos al clúster y configuramos la asociación de la identidad del pod.

• IAM role: Rol creado previamente
• Namespace: Namespace donde vamos a desplegar el pod (puede estar creado previamente o crearlo más tarde)
• ServiceAccount: ServiceAccount que vamos a asociar (puede estar creada o no) En este caso, hemos utilizado la siguiente configuración: Si accedemos nuevamente al clúster, podemos observar que la asociación ya ha sido generada. En caso de no contar con el namespace y la service account, procedemos a crearlos. Podemos realizar esta acción a través de comandos (kubectl) o mediante la definición de un archivo YAML. kubectl create namespace test-demo kubectl create serviceaccount sa-test-demo -n test-demo Creamos un pod de prueba que desplegaremos en el namespace creado previamente y le asociaremos la service account. En este caso, para realizar las pruebas correspondientes, utilizaremos la imagen de aws-cli y le añadiremos un comando de "sleep infinity" para que el pod no se detenga y podamos acceder sin problemas. Verificamos que el pod se ha iniciado correctamente. Accedemos al pod para realizar las validaciones necesarias. Ejecutamos el comando de la CLI de AWS aws s3 ls para listar el contenido del bucket. ¡Y con un toque de magia! El pod ha logrado listar el contenido del bucket sin ningún inconveniente.🎉

🧙‍♂️Ventajas de las identidades de Pod de EKS🧙‍♂️

• Privilegio mínimo: puede limitar los permisos de IAM a una cuenta de servicio y solo los Pods que utilizan esa cuenta de servicio tienen acceso a esos permisos.
• Aislamiento de credenciales: los contenedores de un Pod's solo pueden recuperar las credenciales para el rol de IAM asociado a la cuenta de servicio que usa el contenedor. Un contenedor nunca tiene acceso a credenciales que utilizan otros contenedores de otros Pods.
• Auditabilidad: el acceso y el registro de eventos está disponible a través de AWS CloudTrail para facilitar una auditoría retrospectiva.
• No utiliza proveedores de identidad OIDC (menos gestión y más facilidad).
• Reutilización: la Pod Identity de EKS utiliza una única entidad principal de IAM en lugar de los principios independientes para cada clúster que utilizan los roles de IAM para las cuentas de servicio.
• Escalabilidad: cada conjunto de credenciales temporales lo asume el servicio de EKS Auth en Pod Identity de EKS, en lugar de cada SDK de AWS que se ejecuta en cada pod. A continuación, el agente de Pod Identity de Amazon EKS que se ejecuta en cada nodo emite las credenciales de los SDK.

😱Restricciones de Pod Identity😱

• No se admiten los pods de Linux y Windows que se ejecutan en AWS Fargate (Fargate). No se admiten pods que se ejecutan en instancias Windows Amazon EC2.
• No se admiten complementos de Amazon EKS que necesitan credenciales de IAM.
• No se admiten los clústeres Kubernetes que se crean y ejecutan en Amazon EC2. No se admiten las regiones de AWS GovCloud(EE. UU.), la región China(Beijing, operada por Sinnet) y China(Ningxia, operada por NWCD)
• Disponible para las versiones enumeradas en https://docs.aws.amazon.com/es_es/eks/latest/userguide/pod-identities.html#pod-id-cluster-versions ¡Pero espera, hay más! En estos últimos meses, han surgido novedades emocionantes sobre el servicio de EKS. ¡No podíamos dejarlas pasar! 🚀
• 28/12/2023 - Amazon EKS ahora admite la asignación de grupos de seguridad de EC2 a pods de Kubernetes IPv6
• 28/12/2023 - Amazon EKS ahora muestra los detalles del estado del clúster
• 20/12/2023 - Amazon EKS presenta la información sobre actualizaciones ¡Pero eso no es todo! Puedes echarle un vistazo a https://aws.amazon.com/es/new/?whats-new-content-all.sort-by=item.additionalFields.postDateTime&whats-new-content-all.sort-order=desc&awsf.whats-new-categories=*all

¡Esperamos vuestras reacciones y comentarios!