He intentado añadir un comentario al artículo How to Connect to EC2 with SSM (Session Manager)? pero no ha habido manera…
El autor indica que es necesario configurar la instancia para aceptar tráfico de entrada HTTPS 443 desde cualquier origen…
Aws
Photo by Mabel Amber
Actualizado 24 Julio 2020.
Al eliminar un stack de CloudFormation todos los recursos creados por el stack se eliminan automáticamente. Esto te puede provocar un buen susto cuando eliminas uno por error…
En esta entrada indico cómo prevenir esas situaciones a diferentes niveles: aplicando stack policies a todo el stack o de forma individual en algunos recursos con DeletionPolicy.
El acceso a los objetos almacenados en buckets S3, como en la mayoría de recursos en AWS, está restringido a aquellos usuarios con permisos para realizar acciones sobre ellos.
Sin embargo, en algunas situaciones, puedes tener que proporcionar acceso a ficheros en un bucket pero no es viable asignar permisos a quien tiene que acceder (por ejemplo, son usuarios anónimos). La solución más sencilla sería proporcionar acceso público a esos ficheros, pero esta opción no siempre es posible (por ejemplo, cuando se trata de datos específicos para un usuario).
Afortunadamente, existe una solución para este aparente dilema: las URLs “pre-firmadas” (presigned URLs).
Tipos de Principals en AWS
- post
- Xavi Aznar
En la entrada anterior Prueba de Concepto de notificaciones via CloudWatch Events desde CloudFormation (sin Lambdas) el primer intento de enviar notificaciones al topic a través de CloudFormation falló, aunque estaba autenticado en AWS con un usuario Administrador y las pruebas realizadas de envío de la consola habían sido un éxito.
El problema estaba en el Principal con permisos sobre el topic, por lo que tuve que cambiar de
"Principal": {"AWS": "*" }a"Principal": { "Service": "events.amazonaws.com" }.En esta entrada intento explicar la diferencia entre estos los diferentes tipos de Principals y su uso en las políticas.
En la entrada Envío de eventos de CloudFormation a CloudWatch Events explicaba una manera alternativa -sin Lambdas- para enviar notificaciones SNS con información de ARNs de recursos generados en CloudFormation a través de CloudWatch Events.
En esta entrada explico cómo he realizado una prueba de concepto para validar que es viable.
Recientemente ha surgido la necesidad de notificar por correo valores como respuesta a la creación de recursos vía CloudFormation. En la notificación debe incluirse información relativa a los recursos creados en el stack (como el ARN de un rol o el ID de un security group).
La solución habitual/recomendada es ejecutar una Lambda que envíe un mensaje a un topic SNS configurado para enviar un correo con el ARN del rol recién creado, por ejemplo. En la propuesta del Soporte Premium de AWS se lanza la notificación cuando se produce un rollback del stack, pero se podría modificar el evento para lanzar la notificación con
CREATION_COMPLETE.En este ejemplo se envía el error que se ha producido en la notificación, pero podría modificarse para incluir alguna otra información generada en tiempo de ejecución (como el ARN o ID de algún recurso creado por el stack).
Sin embargo en este artículo exploro una vía alternativa que, en mi opinión, puede ser más adecuada en determinados escenarios y que permite no tener que escribir ni una línea de código (usando sólo servicios de AWS).
AWS ofrece, como parte del servicio Systems Manager (y ¡gratis!) Parameter Store. Como su nombre indica, es un almacén de parámetros que podemos usar para evitar hardcodear valores de configuración de aplicaciones o scripts.
La documentación de Boto3, el SDK de AWS para Python es muy buena, pero es tedioso tener que ir consultándola a cada momento.
Esta entrada es una especie de recordatorio personal sencillo sobre cómo acceder a Parameter Store para leer el valor de un parámetro.
Cambio de rol en AWS
- post
- Xavi Aznar
IAM es el servicio de gestión de identidades y accesos de AWS.
Como todo lo que coloques en el cloud está, por definición, expuesto a internet, la gestión de los permisos es uno de los puntos críticos que debes tener en cuenta.
A la hora de asignar permisos, siempre hay que aplicar el principio de least privilege, es decir, sólo proporcionar los mínimos permisos necesarios para realizar la tarea a realizar.
Sin embargo, esto es más sencillo de decir que de hacer, así que muchas veces se trata de un proceso iterativo: asignas permisos a un rol, intentas realizar alguna acción, la acción falla porque falta algún permiso… Como sólo puedes tener asignado un rol en cada momento, tienes que buscar una forma en la que cambiar entre el rol con permisos y el rol que estás creando de manera sencilla y ágil.
En esta entrada, creamos un rol de laboratorio asumible desde la misma cuenta en el que ir asignando políticas para realizar el refinado de las políticas de la manera más cómoda posible.
También puedes crear roles específicos para tareas de administración, etc y así usar un rol con permisos acotados en cada momento, cambiando al rol adecuado para realizar cada tarea.
Configuración de awscli-login
- post
- Xavi Aznar
Uno de los problemas de usar usuarios IAM con acceso programático a los recursos en AWS es la seguridad de la secret key (incluso habilitando la seguridad con varios factores de autenticación (MFA)).
Cuando un trabajador deja de estar vinculado a la empresa, existen procesos que se encargan de decomisionar los elementos asociados al ex-trabajador; en particular, se elimina el acceso a los sistemas a los que tuviera acceso mediante la desactivación de las cuentas del usuario.
El problema es que los usuarios IAM tienen claves de acceso programático que permiten el acceso a los recursos de manera independiente a los sistemas de gestión de identidad corporativa (generalmente un LDAP) sin necesidad de estar conectados a la red de la empresa.
Aunque la solución más directa parece la modificación del proceso de baja para incluir anulación de los usuarios IAM, lo ideal es conseguir acceso programático a AWS con credenciales federadas, es decir, centralizando la autenticación en el sistema de gestión de identidades de la empresa.
Nuevo usuario IAM en AWS
- post
- Xavi Aznar
Al final de la entrada anterior indicaba que para empezar a usar tu cuenta de AWS necesitas un usuario.
A continuación comento cómo crear un usuario IAM.