Tarde o temprano una herramienta externa te pide "una clave de AWS": un panel de control, un sistema de copias, un monitor. La tentación es copiar la clave de tu usuario administrador. No lo hagas nunca. Quien tenga esa clave puede hacer todo lo que puedes hacer tú, incluido borrar la cuenta entera. Lo correcto es crear un usuario IAM aparte con una política que permita solo las acciones concretas que esa herramienta necesita, y darle su clave.
Lo haremos desde AWS CloudShell, la terminal que viene integrada en la consola web, porque son cuatro comandos que se copian y pegan y el resultado es exacto. No hace falta instalar nada en tu ordenador.
Antes de empezar: qué significa cada cosa
- IAM
- El servicio de AWS que gestiona quién puede hacer qué en tu cuenta: usuarios, claves y permisos.
- Usuario IAM
- Una identidad dentro de tu cuenta de AWS, distinta de la tuya, a la que das solo los permisos que necesite. Puede ser para una persona o para un programa.
- Política
- La lista de permisos, escrita en un formato de texto llamado JSON: qué acciones se permiten y sobre qué. La guía te la da hecha.
- Clave de acceso
- El "usuario y contraseña" para programas: dos cadenas de texto (identificador y secreto) que una herramienta usa para hablar con AWS en nombre de ese usuario.
- CloudShell
- Una terminal (pantalla negra donde se escriben comandos) que viene integrada en la consola web de AWS. No hay que instalar nada: se abre y ya está conectada a tu cuenta.
- Permisos mínimos
- La idea de dar a cada herramienta solo lo imprescindible. Si la clave se filtra, el daño queda limitado a eso.
- ARN
- El nombre completo y único de cualquier cosa en AWS, con la forma arn:aws:... Sirve para referirse a ella sin equívocos.
- Rol
- Una alternativa al usuario con clave: la herramienta "toma prestado" un permiso temporal sin que exista una contraseña permanente. Más seguro, si la herramienta lo admite.
Paso a paso
Decide qué acciones necesita la herramienta
Antes de escribir nada, haz la lista. Un panel que gestiona máquinas Lightsail necesitará, por ejemplo: ver las máquinas y su estado, arrancar, parar y reiniciar, y quizá crear y ver instantáneas. No necesita crear ni borrar máquinas, ni ver la facturación, ni tocar usuarios. Cada acción que no está en la lista es una acción que no vas a dar. Si la herramienta es seria, te dirá exactamente qué permisos pide; si te pide "AdministratorAccess", desconfía.
Abre CloudShell
En la consola de AWS, pulsa el icono de terminal de la barra superior (CloudShell) o búscalo por nombre. Tarda unos segundos en arrancar. Ya tienes una terminal Linux con la herramienta
awsconfigurada con tus credenciales actuales, así que todo lo que hagas ahí lo haces como el usuario con el que estás en la consola (que debe tener permiso para gestionar IAM).Escribe la política
Crea un fichero con la política en formato JSON. Este ejemplo permite ver, arrancar, parar y reiniciar máquinas Lightsail y manejar sus instantáneas, nada más. Pega el bloque entero en CloudShell:
cat > politica.json <<'FIN' { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "lightsail:GetInstances", "lightsail:GetInstance", "lightsail:GetInstanceState", "lightsail:GetInstanceMetricData", "lightsail:GetRegions", "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance", "lightsail:GetInstanceSnapshots", "lightsail:GetInstanceSnapshot", "lightsail:CreateInstanceSnapshot", "lightsail:DeleteInstanceSnapshot" ], "Resource": "*" }] } FINCada acción se llama
servicio:Operación. Si solo quieres que la herramienta vea, quita las líneas de Start, Stop, Reboot, Create y Delete. Para EC2, S3 o RDS las acciones tienen otros nombres, pero la mecánica es idéntica. En Lightsail la mayoría de acciones no se pueden limitar a una máquina concreta, por eso elResourcees*; en EC2 o S3 sí puedes poner el identificador exacto del recurso.Crea la política, el usuario y únelos
Tres comandos. Cambia el nombre si quieres, pero que diga para qué sirve:
aws iam create-policy --policy-name PanelMaquinas --policy-document file://politica.json aws iam create-user --user-name panel-maquinas aws iam attach-user-policy --user-name panel-maquinas \ --policy-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):policy/PanelMaquinasEl primer comando devuelve el ARN de la política; el tercero lo reconstruye con el número de tu cuenta para que no tengas que copiarlo. Fíjate en que al usuario no le damos contraseña de consola: solo existirá para la clave de acceso.
Genera la clave de acceso
aws iam create-access-key --user-name panel-maquinasLa respuesta trae dos valores:
AccessKeyId(empieza por AKIA) ySecretAccessKey. El secreto solo se muestra esta vez. Cópialo directamente en la herramienta que lo va a usar. No lo pegues en un correo, en un chat ni en un documento compartido. Si lo pierdes, no pasa nada: borras esa clave y creas otra.Borra el fichero y comprueba
rm politica.json aws iam list-attached-user-policies --user-name panel-maquinasDebe aparecer solo
PanelMaquinas. Configura la herramienta con la clave y prueba una acción permitida (ver máquinas) y una no permitida (crear una): la segunda debe fallar con "not authorized". Ese error es la prueba de que has hecho bien el trabajo.
Qué puede salir mal
La herramienta dice que no tiene permiso para algo que sí quieres
Le falta una acción en la política. El mensaje de error de AWS dice exactamente cuál (User ... is not authorized to perform: lightsail:GetBundles). Añádela al JSON y actualiza la política con aws iam create-policy-version --set-as-default, o edítala desde la consola de IAM. Añade solo esa acción, no vuelvas a abrir la mano.
He pegado el secreto en un sitio donde no debía
Considéralo filtrado. En CloudShell: aws iam delete-access-key --user-name panel-maquinas --access-key-id AKIA... y crea otra. Como el usuario tiene permisos mínimos, el daño posible era pequeño; esa es la gracia de todo esto.
El tercer comando falla con el ARN
Puede que tu usuario de consola no tenga permiso para sts:GetCallerIdentity (raro) o que el nombre de la política tenga una errata. Copia el ARN que devolvió el primer comando y pégalo a mano en --policy-arn.
¿No sería mejor un rol que un usuario?
Sí, cuando la herramienta lo soporta: un rol IAM que la herramienta asume desde su propia cuenta de AWS no tiene clave que filtrar y las credenciales caducan solas. Pregúntale a tu proveedor si admite "acceso por rol" o "cross-account role". Si no, el usuario con permisos mínimos es la segunda mejor opción, y mucho mejor que la clave de administrador.
En Simplio
En Simplio no tienes que escribir la política: en la ayuda marcas con casillas qué quieres permitir (solo ver, sin cortafuegos, sin terminal, una región...) y te genera el JSON y el script completo para pegar en CloudShell, que devuelve la clave ya hecha. Y si prefieres evitar claves, Simplio admite la conexión por rol, con credenciales temporales que caducan en una hora. La clave se guarda cifrada y nunca se vuelve a mostrar.
Lo mismo, en AWS y en Simplio
| En la consola de AWS | En Simplio | |
|---|---|---|
| Escribir la política | Conocer el nombre exacto de cada acción de AWS y el formato JSON | Marcar casillas (solo ver, sin cortafuegos, sin terminal, una región): el JSON se genera solo |
| Crear usuario, política y clave | CloudShell, 4 comandos, 15 minutos la primera vez | Pegar en CloudShell el script que genera la ayuda: 2 minutos |
| Si no quieres claves | Diseñar un rol entre cuentas a mano | Conexión por rol con un ARN que te genera Simplio |