Muy buenas, me llamo Miguel y aquí les traigo otro nuevo artículo.
El problema subyacente: ¿cómo se administran varias implementaciones de AWS? El ejemplo típico es desarrollo / qa / producción, pero los entornos sandbox para desarrolladores, en los que los desarrolladores tienen la libertad de experimentar con los servicios sin temor a afectar a nadie más, son quizás incluso más relevantes.
La respuesta estándar a este problema es crear varias cuentas de AWS y con el lanzamiento de Organizaciones de AWS en 2017 se volvió mucho más fácil de implementar: además de simplificar la facturación, las organizaciones le dan a la cuenta maestra más control sobre los niños a través de las políticas de control de servicios.
Pero si usa varias cuentas, ¿cómo administra los usuarios en esas cuentas? Una respuesta no muy buena es crear usuarios separados en cada cuenta.
Esto se convierte rápidamente en una pesadilla de gestión, tanto para la organización como para sus usuarios. Para la organización, debe agregar usuarios a las cuentas correspondientes, administrar sus permisos y eliminarlos si abandonan la empresa; esto se puede solucionar con la automatización.
Pero para los usuarios, es más difícil de resolver: he visto a compañeros de trabajo recorrer una lista de cuentas / contraseñas hasta que encontraron la correcta para la tarea que estaban a punto de realizar. E inevitablemente, si trabaja con varias cuentas, termina con un «¡Ups!» donde hiciste algo en la cuenta incorrecta.
2017. Con este servicio, puede administrar un solo conjunto de usuarios y otorgarles permisos variables en diferentes cuentas de AWS.
Los usuarios inician sesión a través del portal SSO y seleccionan su cuenta de destino; pueden obtener credenciales temporales para el acceso CLI / SDK o ser redirigidos a la consola de AWS para esa cuenta.
Además, puede utilizar SSO como portal para aplicaciones web como Office365 o sus propias aplicaciones basadas en SAML.
Y puede usar un servidor de Active Directory corporativo como base de datos de usuarios, que es algo que a las organizaciones más grandes les gustará (revelación: no he configurado la integración de AD, por lo que no puedo decir qué tan fácil o difícil es).
Cuando escribí esta publicación por primera vez, señalé que SSO no admitía TOTP para la autenticación multifactor. Esto cambió en octubre de 2019 y ahora puede usar cualquier proveedor de tokens MFA con SSO que pueda usar con IAM.
Sin embargo, mi segunda preocupación sigue siendo: SSO no es programable (al menos al momento de escribir este artículo) a través de CloudFormation o Terraform.
Por lo tanto, debe ingresar a sus usuarios y configurar sus permisos manualmente. Y los “conjuntos de permisos” de SSO se traducen directamente en roles de IAM, por lo que terminará con una combinación de roles con y sin script, perdiendo el beneficio del control de fuente para su infraestructura.
Dicho todo esto, sigo pensando que SSO es una buena opción para muchas organizaciones. Pero prefiero la siguiente arquitectura, en la que todos los usuarios se definen en la cuenta maestra de la organización y tienen la capacidad de asumir roles en las cuentas secundarias (nota: cada cuenta tiene un ID de cuenta inventado que se usa en los ejemplos posteriores):
Comencemos mirando los roles. La cuenta de la zona de pruebas puede tener solo una función, SandboxUser, que otorga acceso de administrador.
En comparación, la cuenta de producción puede tener múltiples roles, otorgando diferentes niveles de acceso a diferentes conjuntos de recursos.
Por ejemplo, puede definir un rol FooMonitoring que (entre otras cosas) otorga permiso para describir instancias EC2 que tienen una etiqueta Application con el valor Foo.
Lo único que todos los roles tendrán en común es una relación de confianza que les permita ser asumidos por los usuarios en la cuenta maestra:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::012345678901:root"
},
"Action": "sts:AssumeRole"
}
]
}
Esta relación de confianza significa que cualquier usuario de la cuenta maestra de la organización puede asumir el rol sts:AssumeRole acción.
Este privilegio se otorga a través de políticas en la cuenta maestra y, de acuerdo con las mejores prácticas de AWS, esas políticas deben adjuntarse a grupos en lugar de a usuarios individuales.
Como ejemplo concreto, supongamos que tenemos una aplicación llamada Alfie (me estoy cansando de Foo y Bar).
Los desarrolladores que trabajan en esa aplicación deben tener diferentes niveles de acceso a los recursos utilizados por esa aplicación según el entorno: acceso completo en desarrollo, acceso para implementaciones en QA y acceso de solo lectura en producción.
Cada nivel de acceso requerirá un rol en la cuenta relevante; los detalles de estos roles están más allá del alcance de esta publicación.
Después de crear los roles, creamos un alfie-developers grupo en la cuenta maestra, asigne los desarrolladores a ese grupo y asígnele una política de permisos similar a la siguiente:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::123456789012:role/AlfieReadOnly",
"arn:aws:iam::234567890123:role/AlfieDeployment",
"arn:aws:iam::345678901234:role/AlfieFullAccess"
]
}
]
}
Todo muy bien, pero ¿cómo trabajan sus usuarios en este entorno?
Siempre que se ciña a la consola de AWS, es fácil Cambiar roles.
Desde la línea de comandos es un poco más difícil. La opción más sencilla es actualizar su Archivos de configuración de AWS, guardado en $HOME/.aws.
Hay dos archivos, credentials y config, y aunque en la práctica puede especificar roles asumibles en cualquiera de los dos, los documentos son muy explícitos en que el primero es solo para credenciales reales.
Asumiendo que corriste aws configure, se verá así:
[default] aws_access_key_id = AKIAEXAMPLEXXXXXXXXX aws_secret_access_key = EXAMPLExxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
En el segundo archivo, config, puede especificar varios perfiles (también tiene un perfil predeterminado en este archivo, donde puede especificar su región predeterminada):
[default] region = us-east-1 [profile alfie-development] role_arn = arn:aws:iam::345678901234:role/AlfieFullAccess source_profile = default [profile alfie-qa] role_arn = arn:aws:iam::234567890123:role/AlfieDeployment source_profile = default [profile alfie-production] role_arn = arn:aws:iam::123456789012:role/AlfieReadOnly source_profile = default
Con estos perfiles configurados, puede utilizar el --profile parámetro de línea de comando para especificar qué rol desea asumir para una acción en particular:
aws s3 ls --profile alfie-development
Esto es algo oneroso y no está disponible para los programas que escribe. Como alternativa, puede utilizar el AWS_PROFILE variable de entorno para configurar su perfil:
export AWS_PROFILE=alfie-developmentaws s3 ls
Hay una advertencia final: un rol asumido tiene una duración limitada, por defecto una hora. Con las herramientas de línea de recomendación y un perfil configurado, nunca debe encontrarse con esto, porque cada invocación asume su propio rol.
Para terminar: puede considerar que el cambio de roles es mucho trabajo. Pero en la práctica, los desarrolladores se acostumbran a hacerlo en poco tiempo y prefieren no tener que hacer malabarismos con las credenciales.
Y un beneficio más importante es que luego puede introducir roles especiales para operaciones destructivas, como cerrar una instancia de RDS.
Gracias por leer este artículo.
Añadir comentario