Uso de IAM Roles Anywhere en lugar de claves IAM
- 13 abr
- 4 Min. de lectura
Introducción
En entornos híbridos y multi-cloud, uno de los mayores desafíos es habilitar el acceso seguro a recursos en la nube sin depender de credenciales estáticas como las claves de acceso de IAM. A medida que las organizaciones integran workloads on-premises, dispositivos edge y servicios que corren en otras nubes con AWS, la gestión de identidades se vuelve una pieza crítica de la arquitectura.
AWS IAM Roles Anywhere aborda este desafío permitiendo que sistemas fuera de AWS se autentiquen utilizando certificados X.509 y asuman roles de IAM de forma segura. En lugar de distribuir claves de acceso de larga duración, los workloads utilizan certificados para obtener credenciales temporales a través de AWS Security Token Service, alineándose con prácticas modernas de seguridad como Zero Trust.
Este enfoque cambia el modelo de secretos compartidos a identidades verificables respaldadas por PKI. Los certificados X.509 necesarios pueden ser emitidos tanto por una PKI empresarial existente como utilizando AWS Private Certificate Authority, lo que lo hace lo suficientemente flexible para integrarse con infraestructuras de seguridad actuales.
Probando IAM Roles Anywhere
Veamos un ejemplo donde utilizaremos una CA privada/local para generar certificados y configurar un servidor on-premises para acceder a un bucket de S3 e interactuar con objetos usando IAM Roles Anywhere. En este ejemplo vamos a:
Generar certificados para una CA privada/local
Establecer un trust anchor entre AWS y nuestra CA
Crear y configurar un Role
Configurar un Profile
Generar certificados para nuestro servidor on-premises
Configurar el profile en el servidor
Probar acceso a servicios de AWS
Paso 1 - Generar certificados para una CA privada/local
Lo primero que necesitamos hacer es generar una clave privada para nuestra CA, que llamaremos ca.key. Podemos generarla con OpenSSL, y es muy importante almacenarla de forma segura.
openssl genrsa -out ca.key 4096 |
Luego, creamos un archivo de configuración llamado ca.cnf, donde definimos los datos de la organización. Ejemplo:
[ req ] default_bits = 4096 prompt = no default_md = sha256 distinguished_name = dn x509_extensions = v3_ca [ dn ] C = AR ST = Buenos Aires L = Pergamino O = Teracloud OU = DevOps CN = Facundo Montero emailAddress = facundo.montero@teracloud.io [ v3_ca ] basicConstraints = critical, CA:TRUE, pathlen:0 keyUsage = critical, keyCertSign, cRLSign subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always |
Finalmente, usando la clave privada y el archivo de configuración, generamos el certificado público de la CA (ca.crt), definiendo también su período de validez:
openssl req -new -x509 \\n -days 365 \\n -key ca.key \\n -out ca.crt \\n -config ca.cnf\n |
Paso 2 - Establecer un trust anchor entre AWS y nuestra CA
Para acceder a la configuración de IAM Roles Anywhere desde la consola, debemos ir al final de la sección de Roles en IAM.
Para que AWS reconozca nuestra CA como válida y establezca confianza, necesitamos configurar el certificado público (ca.crt) en Roles Anywhere. Para esto:
Definimos un nombre para la relación de confianza
Indicamos que es un certificado externo
Pegamos el contenido del archivo ca.crt
Paso 3 - Crear y configurar un Role
Ahora debemos crear un IAM Role, especificando durante su creación que será utilizado para Roles Anywhere.
Luego seleccionamos las políticas que tendrá el Role. En este ejemplo usamos la política administrada AmazonS3FullAccess.
Finalmente, definimos un nombre para el Role y verificamos que tenga una Trust Policy que permita a Roles Anywhere asumirlo.
Paso 4 - Configurar un Profile
Una vez creado el Role, debemos crear un Profile en Roles Anywhere.
Ahí definimos:
Un nombre
El Role creado previamente
Opcionalmente, podemos:
Configurar una Session Policy para limitar permisos
Definir la duración de la sesión (por defecto, 1 hora)
Paso 5 - Generar certificados para el servidor on-premises
Ahora generamos los certificados para el servidor que usará el profile, firmados por la CA creada anteriormente.
Primero, creamos server.cnf con los datos del servidor:
[ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn x509_extensions = v3_ca [ dn ] C = AR ST = Buenos Aires L = Pergamino O = Teracloud OU = DevOps CN = mi-servidor emailAddress = facundo@jcaii.ca [ v3_ca ] basicConstraints = critical, CA:FALSE keyUsage = critical, digitalSignature, keyEncipherment subjectKeyIdentifier = clientAuth authorityKeyIdentifier = hash |
Luego generamos la clave privada:
openssl genrsa -out server.key 2048 |
Generamos el CSR:
openssl req -new \ -key server.key \ -out server.csr \ -config server.cnf |
Firmamos el certificado:
openssl x509 -req \ -in server.csr \ -CA ca.crt \ -CAkey ca.key \ -CAcreateserial \ -out server.crt \ -days 365 \ -sha256 \ -extfile server.cnf \ -extensions v3_req |
Verificamos la cadena de confianza:
openssl verify -CAfile ca.crt server.crt |
Luego subimos server.crt y server.key al servidor, por ejemplo en: /etc/aws/rolesanywhere/
Paso 6 - Configurar el profile en el servidor
Debemos instalar la herramienta Signing Helper para obtener credenciales temporales:
curl -Lo aws_signing_helper https://rolesanywhere.amazonaws.com/releases/1.7.2/X86_64/Linux/Amzn2023/aws_signing_helper chmod +x aws_signing_helper sudo mv aws_signing_helper /usr/local/bin/ |
Luego configuramos el profile en ~/.aws/config:
[profile mi-servidor] region = us-east-1 credential_process = /usr/local/bin/aws_signing_helper credential-process --region us-east-1 --certificate /etc/aws/rolesanywhere/server.crt --private-key /etc/aws/rolesanywhere/server.key --trust-anchor-arn arn:aws:rolesanywhere:us-east-1:756003157369:trust-anchor/bcn5fdc2-56u3-4d55-a4a3-932c90fcc63b --profile-arn arn:aws:rolesanywhere:us-east-1:756003157369:profile/4e1C84s0-c20b-4p07t-0983r-8744912 --role-arn arn:aws:iam::756003157369:role/EjemploRolesAnywhere |
Paso 7 - Probar acceso a servicios de AWS
Una vez que todo está configurado, necesitamos probar el profile en el servidor y verificar que funcione correctamente. Para esto, podemos usar la AWS CLI y comprobar que la identidad sea válida:
aws sts get-caller-identity --profile mi-servidor { "UserId": "DREAZS353SACNNSMMSZPM:8713b1b390710894f86205281ca62c028367bc06", "Account": "756003157369", "Arn": "arn:aws:sts::756003157369:assumed-role/EjemploRolesAnywhere/8713b1b390710894f86205281ca62c028367bc06" } |
Una vez verificada la identidad, podemos listar el contenido de un bucket en nuestra cuenta o subir un archivo:
aws s3 ls s3://your-bucket --profile mi-servidor |
aws s3 cp objeto.txt s3://your-bucket/objeto.txt --profile mi-servidor |
También podemos usar el profile desde un script en Python con boto3. Este es un ejemplo de cómo subir un archivo a un bucket. Por defecto, intentará obtener el nombre del bucket y los valores del profile desde las variables de entorno del sistema; si no los encuentra, utilizará los valores definidos en el script:
import os import boto3 from botocore.exceptions import BotoCoreError, ClientError BUCKET_NAME = os.environ.get("BUCKET_NAME", "your-bucket") AWS_PROFILE = os.environ.get("AWS_PROFILE", "mi-servidor") FILE_NAME = "objeto.txt" OBJECT_NAME = "objeto.txt" def upload_file(): try: session = boto3.Session(profile_name=AWS_PROFILE) s3 = session.client("s3") s3.upload_file(FILE_NAME, BUCKET_NAME, OBJECT_NAME) print(f"Archivo '{FILE_NAME}' subido a s3://{BUCKET_NAME}/{OBJECT_NAME}") except FileNotFoundError: print("El archivo no existe") except (BotoCoreError, ClientError) as e: print(f"Error al subir el archivo: {e}") if name == "__main__": upload_file() |
Conclusión
Este ejemplo muestra lo simple que es configurar IAM Roles Anywhere en un servidor. Una vez configurado, puede utilizarse igual que un profile estándar de AWS basado en claves de acceso, lo que facilita su adopción en workflows existentes.
Sin embargo, la principal ventaja está en su modelo de seguridad. Al utilizar AWS Security Token Service, IAM Roles Anywhere provee credenciales temporales que se rotan automáticamente.
Esto elimina la necesidad de gestionar claves de acceso de larga duración, reduciendo la carga operativa y disminuyendo significativamente el riesgo asociado a la filtración de credenciales.
Facundo Montero
Cloud Engineer
