IAM

Como primer post de la serie de Estudiando para el DVA-C02, vamos a arrancar con IAM.

IAM es identity and access management, que es basicamente el manejo de usuarios, grupos, roles y permisos tanto de usuarios como de servicios de AWS.

Como recomendacion (esto es mas del examen de arquitectura, pero tambien aplica a este), si ya tienen una cuenta de AWS personal, dividan los sub-proyectos en Organizaciones. Son gratis, les quenda como "cuentas hijas" de la principal, y de esta forma, pueden detectar y dividir al 100% los recursos, billing, etc. Y cuando lo quieren dar de baja, dan de baja la organizacion y listo (todo esta auto contenido).

Si no tienen una cuenta de AWS, pueden sacar una de forma gratuita (si o si tienen que poner una tarjeta de credito, no festejen tanto). Cuando sacan la cuenta, al loguearse esa primera vez se estan logueando con lo que se llama root account: esa cuenta es la mas importante, dado que tiene acceso a TODO. No esta restringida de ninguna manera. Entonces, apenas nos hacemos la cuenta

1. Usen un password realmente seguro
2. Una vez logueados, pongan MFA (Authy, Microsoft Authenticator, Google Authenticator, o lo que mas les guste, pueden hasta usar una hardware key, pero pongan CUALQUIER cosa con doble factor. No, SMS no cuenta como doble factor)
3. Hagan un usuario que tenga el rol de Administrator, y tambien usen un password seguro y habiliten en doble factor
4. Nunca mas vuelvan a loguearse con el root account, solo lo van a necesitar para hacer cosas muy especificas. Siempre usen el otro usuario.

Al hacer esto, pueden incluso restringir el acceso del usuario admin (por ej, indicando que solo puede lanzar instancias baratas de EC2, o que no puede poner nada en alguna region lejana, tipo China).

Que tiene IAM?

Basicamente, IAM permite definir:

• Usuarios
• Groups
• Roles
• Policies (hechos en JSON)

Los Usuarios son lo que uno pensaria: usuarios. Estos pueden o no tener acceso programatico (con una Access Key y una Security Key) o acceso a la consola. Si laburamos en una empresa grande con un Active Directory o un LDAP, podemos tener usuarios federados que son "importados" en IAM para poder definir permisos y roles usando SAML.

Los Groups son grupos de usuario (Developers, Contabilidad, Diseñadores, etc). Los grupos SOLO pueden contener usuarios, no otros grupos.

Los Roles son usados para indicar permisos sobre instancias o servicios. Ejemplo, tenemos un server "A", otro "B" y otro "C". Necesitan acceso a DynamoDB y a S3. En vez de ir y poner las propiedades de cada uno ("A necesita acceso a DynamoDB, B tambien, C tambien, etc") directamente creamos un Rol "X", y a ese rol le asignamos los permisos de DynamoDB y S3. Y cada vez que lanzamos una instancia, le decimos "esta nueva instancia va a tomar el rol "X", y de esta forma, si en el futuro necesitamos agregar (o quitar) permisos para algo, lo hacemos sobre el rol y no sobre la instancia en si. Eso tambien nos ahorra de andar pasando el access key y security key en nuestro codigo: la instancia ya "SABE" que puede hacer al tener ese rol.

Policies son los permisos que hablabamos antes ("Permisos de acceso de solo lectura de DynamoDB", "Escritura en un bucket determinado en S3", se definen usando formato JSON, y puedes ir desde cosas generales ("Dame permiso de escritura a todos los buckets" a especifico ("Dame permiso en el folder AAA del bucket "Pepito" de la cuenta 234827874283).

Esto es bastante complicado, asi que hicieron algo llamdo Policy Simulator, que te permite probar las policies antes de agregarlas: https://policysim.aws.amazon.com/home/index.jsp

Como puntos finales, algunas best-practices a tener en cuenta:

• Un usuario de IAM debe equivaler a una sola persona
• Hacemos un rol de IAM por aplicacion (aca es medio generico, porque aplicacion puede considerarse un "web server", pero si tenes microservicios, capaz el "A" tiene permiso a Dynamo y el "B" no, asi que no deberias usar el mismo rol). Siempre pensar un poco antes de definir mil roles, muchas veces se pueden agrupar.
• NUNCA compartir las access key y security keys
• NUNCA PERO NUNCA hardcodear las keys en el codigo. Usar roles, y si realmente es imposible, buscar alternativas (Secret Manager, o -ew- Enviroment variables en el peor de los casos)
• NUNCA usar la root account. Nunca poner una contraseña facil y nunca dejarla sin 2do factor de autenticacion
• Siempre proveer el minimo acceso a las apps: si tu Lambda necesita solo acceso de lectura a un bucket de S3, no darle "Administrative access" a ese rol.

A pesar que parece "facil", la cantidad de veces que uno reniega al poner mal los policies son mas de los que estoy dispuesta a admitir. Empiecen de a poco a jugar un poco con esto, para ir entendiendo como configurar y asignar permisos.