Autor: Guillermo Ojeda
Para organizar nuestros recursos en AWS tenemos dos opciones: Todo en la misma cuenta, todos los recursos mezclados, y un desorden para controlar costos, asignar permisos, etc; o una estructura multi-cuenta donde podemos tener una cuenta aparte por cada proyecto y/o entorno, más algunas cuentas transversales como Shared Services o Security. La estrategia
multi-cuenta incluso puede ser la mejor opción para personas individuales, si quisieran tener una cuenta Sandbox para hacer demos para los cursos de AWS, una cuenta para un workshop en particular que quieran hacer, y una cuenta para cada proyecto personal. Este blog post es una guía para pasar de una cuenta personal a una estructura multi-cuentas para uso personal.
Esta estructura o similar es lo ideal, pero para un uso personal va a tomar un tiempo hasta realmente tener esas necesidades, y no es una estructura trivial de crear manualmente. El modelo está sacado de esta charla de re:Invent sobre seguridad en una estrategia multi-cuenta.
Como parte del servicio NCMS creamos esta estructura de cuentas para nuestros clientes, pero NCMS está pensado para uso empresarial, no personal.
En este artículo nos vamos a limitar a crear una organización, crear una cuenta para usar como sandbox y configurar single sign-on para ambas cuentas con AWS SSO.
Lo primero que voy a hacer es crear una organización que agrupe todas mis cuentas. Esta organización me va a permitir gestionar de forma centralizada mis múltiples cuentas y tener una facturación consolidada (i.e. me ahorro poner los datos de mi tarjeta en cada una de las cuentas). Para esto, en la consola de AWS voy a Organizations, click en Create Organization y de nuevo en Create Organization. Finalmente verifico mi dirección de mail con el link que me envían, y listo. La cuenta desde la cual haga esto va a ser la cuenta raíz (root) de mi organización. Por defecto mi organización viene con un montón de features habilitadas, entre ellas Consolidated Billing (que es lo que necesito para que la factura de las cuentas que cree me la cobren a la cuenta root, así no tengo que estar poniendo mis datos de tarjeta en toooodas las cuentas)
Luego, en Organizations puedo invitar mis cuentas existentes o crear cuentas nuevas. En mi caso no tengo otras cuentas que quiera invitar, pero quiero una cuenta nueva para el workshop de ECS que voy a hacer. Clickeo en Add account, selecciono Create account, completo Account name e Email y click en Create.
Para no tener que manejar múltiples direcciones de email en mis múltiples cuentas, en vez de crear una dirección nueva creé un alias para mi dirección existente. Si usan GSuite ésta es la guía, y ésta si usan Gmail en su versión normal.
Ya tengo la cuenta, así que ya estaría listo para arrancar el workshop de ECS. Momento, ¿cómo accedo a la cuenta que acabo de crear? Una forma es recuperar la contraseña del usuario root mediante el email y acceder con el usuario root. Claro que esto no es recomendable, así que luego de hacerlo por única vez en la cuenta recién creada deberíamos crear un usuario IAM y nunca más usar el root. Como se trata de una cuenta tipo sandbox, es decir que vamos a usar para jugar con algunas cosas y practicar un rato (en mi caso una práctica guiada por el ECS Workshop), no habría mucho problema con darle permisos de Admin a este usuario IAM (además de restringir permisos mediante IAM, se pueden utilizar Service Control Policies para aplicar restricciones desde la organización). Si algún agente malicioso ganara acceso a nuestro usuario IAM, no perderíamos nada de valor, ¡pero podría crear mil instancias EC2 y usarlas para minar bitcoins y dejarnos pagando la factura de AWS! Existen mecanismos para imponer límites de facturación a una cuenta, pero por ahora vamos a usar la misma protección que para nuestro usuario IAM en la cuenta root: autenticación multi-factor.
Personalmente uso la app mobile Google Authenticator, más un poco de seguridad en mi teléfono. Esto son las primeras 5 cuentas, tengo 5 más. Imagínense el desorden que sería si para cada usuario root más para cada usuario IAM de cada cuenta tuviera que agregarlo acá. ¡Nunca encontraría nada!
Con la contraseña no tendría tanto problema si uso un password manager como LastPass, pero también tendría que estar recordando los números de cuenta o alias de cada cuenta!
Mucho mejor sería tener un único log in para todas las cuentas, un Single Sign On (SSO). Para eso existen un montón de soluciones, simples y complejas, versátiles y no tanto, con integración con servicios de federation o sólo stand alone. El que voy aconfigurar es AWS Single Sign-On, porque es lo suficientemente bueno para mi necesidad, es gratis y es fácil de configurar. En NCMS usamos Okta, que es un poco más potente.
Para arrancar con AWS SSO vamos a ir al servicio AWS Single Sign-On en la consola, y lo primero que vamos a hacer es habilitar este servicio clickeando el botón grande que dice Enable AWS Single Sign-On. De ahí nos van a redirigir a una amigable página que dice "Welcome to AWS Single Sign-On" y nos da 3 pasos para configurar.
El primer paso es Choose your identity source, donde podemos configurar el lugar de donde AWS SSO va a obtener los usuarios. En mi caso lo voy a dejar como AWS SSO, pero se puede elegir Active Directory o algún proveedor que use SAML 2.0. Ya que estoy acá voy a clickear en el botón Configure de la sección Multi-factor authentication, y voy a configurar para que si un usuario no tiene un dispositivo MFA configurado no se pueda loguear.
Como elegí AWS SSO como identity source, necesito crear mis usuarios en AWS SSO. Para eso voy a Users y creo los usuarios (o el usuario en mi caso, sólo yo voy a tener acceso). Luego de crear mi usuario voy a crear un grupo de Administrators y agregar mi usuario al mismo.
Una vez creado el usuario voy a entrar a la información del mismo para configurarle un dispositivo MFA. Ahí configuro mi dispositivo, y queda listo mi usuario de AWS SSO.
¡Lo único que me faltaría es darle acceso a algo!
Clickeando en Dashboard vuelvo a los amigables Recommended setup steps, y vamos con el paso 2: Manage SSO access to your AWS accounts. Clickeando ahí me aparece una tabla con las cuentas de AWS de mi organización y los Permission sets que tengo asignados. Primero voy a ir a la segunda pestaña, Permission Sets, y voy a crear uno con los permisos que yo quiero: click en Create, selecciono Create a custom permission set, ingreso el nombre y la descripción, en Relay state ingreso "https://console.aws.amazon.com/console/home?region=us-east-1" para que cuando me loguee me redirija al home de la consola con la región us-east-1 seleccionada, tildo Attach AWS managed policies, selecciono las policies que quiero y click en Create.
Luego voy a volver a la pestaña AWS Organization, seleccionar todas las cuentas a las que quiero dar permisos (en mi caso ambas) y click en Assign users. Desde ahí puedo seleccionar un usuario o un grupo, y asignarle un permission set sobre esas cuentas. En mi caso le voy a dar a mi único usuario acceso de administrador a todas las cuentas, pero si quisieran podrían darle al grupo Desarrolladores Proyecto 1 acceso de administrador a la cuenta proyecto1-dev y acceso de lectura a la cuenta proyecto1-prod, por ejemplo. Para eso tendrían que primero seleccionar una cuenta y hacer este proceso con el permission set correspondiente y luego repetirlo para la otra cuenta.
El paso 3 es para configurar otros servicios externos mediante SAML 2.0. En mi caso no voy a configurar ninguno, así que sólo me queda probar mi nuevo usuario. Desde Dashboard se puede configurar la User portal URL, que es la URL que deberán recordar o poner en marcadores. No es necesario customizarla, pero queda un poco más lindo. Cuidado, una vez que se configura no se puede modificar.
Vamos al User portal a través de la URL, ingresamos la contraseña (en mi caso la contraseña de uso único, e inmediatamente me permite configurar una contraseña permanente), el código del MFA, y ¡et voilà!
Puedo entrar a cualquiera de las dos cuentas con el rol configurado (y podría configurar varios roles para un mismo usuario y cuenta). Además, puedo obtener credenciales temporales para acceso programático o por CLI que duran por defecto 1 hora (se puede aumentar hasta 12 horas), lo cual es mucho más seguro que las access keys de IAM que tengo que rotar cada 90 días.
Ahora debería dejar inactivas mis access keys y metafóricamente guardar en un cajón mi usuario de IAM de mi cuenta original. ¡Ya no lo necesito! Ahora me logueo directamente desde AWS SSO para todo lo que quiera hacer en cualquiera de mis cuentas.
En nubeGo podemos configurar la estructura ideal de cuentas y más como parte del servicio de MSP NCMS. Si quieres conocer sobre los beneficios que traerá a tu organización contáctanos en https://es.nubego.io/contact-us
Gracias por leer, y espero que les haya servido!