Gestionando Permisos de AWS con Terraform: IAM Roles, Políticas y Usuarios

🚀 Introducción a IAM y Terraform

La gestión de identidades y accesos (IAM) es una de las piedras angulares de la seguridad en AWS. Permite controlar de forma granular quién (o qué) puede acceder a qué recursos y qué acciones pueden realizar. Sin una gestión de IAM adecuada, tus recursos en la nube podrían ser vulnerables o inaccesibles.

Tradicionalmente, la configuración de IAM se realizaba a través de la consola de AWS o mediante la AWS CLI. Sin embargo, en un entorno de infraestructura como código (IaC), Terraform ofrece una forma más eficiente, reproducible y auditable de gestionar estos permisos. Al definir tus roles, políticas y usuarios de IAM en archivos *.tf, puedes versionar tus configuraciones, revisarlas y aplicarlas de manera consistente en diferentes entornos.

Este tutorial te sumergirá en el mundo de IAM con Terraform, cubriendo los componentes esenciales: Usuarios, Grupos, Roles y Políticas. Aprenderás cómo estos elementos interactúan para formar un sistema de control de acceso robusto y cómo puedes definirlos y gestionarlos declarativamente con Terraform.

🎯 Conceptos Fundamentales de AWS IAM

Antes de sumergirnos en el código de Terraform, es crucial entender los componentes clave de IAM.

👤 Usuarios y Grupos IAM

• Usuarios IAM: Representan a una persona o una aplicación que interactúa directamente con AWS. Cada usuario puede tener credenciales de inicio de sesión (nombre de usuario y contraseña) para la consola, o claves de acceso (access keys) para acceso programático. Son una identidad de larga duración.
• Grupos IAM: Una colección de usuarios IAM. Puedes adjuntar políticas a un grupo, y todos los usuarios dentro de ese grupo heredarán esos permisos. Esto simplifica la gestión de permisos para múltiples usuarios con necesidades similares.

🎭 Roles IAM

Los Roles IAM son una forma segura de delegar permisos a entidades de confianza. A diferencia de un usuario, un rol no tiene credenciales de larga duración asociadas. En su lugar, cuando una entidad asume un rol, AWS le proporciona credenciales temporales. Los roles son ideales para:

• Servicios de AWS: Permitir que un servicio (como EC2, Lambda o ECS) realice acciones en tu nombre (ej. una instancia EC2 que necesita leer de S3).
• Usuarios fuera de AWS: Otorgar acceso temporal a usuarios federados o cuentas de AWS externas.
• Acceso entre cuentas: Permitir que una cuenta de AWS acceda a recursos en otra cuenta de AWS.

📜 Políticas IAM

Las Políticas IAM son documentos JSON que definen los permisos. Especifican qué acciones se pueden realizar en qué recursos, y bajo qué condiciones. Las políticas se pueden adjuntar a usuarios, grupos o roles.

Una política se compone de uno o más Statements, donde cada Statement incluye:

• Effect: Allow o Deny (siempre se evalúa Deny primero).
• Action: La acción o acciones permitidas/denegadas (ej. s3:GetObject).
• Resource: El ARN del recurso o recursos afectados (ej. arn:aws:s3:::my-bucket/*).
• Condition (opcional): Restricciones adicionales (ej. solo desde una IP específica).

🛠️ Configurando Terraform para IAM

Antes de empezar, asegúrate de tener Terraform instalado y configurado con tus credenciales de AWS.

# main.tf
provider "aws" {
  region = "us-east-1"
}

⚙️ Gestión de Usuarios y Grupos con Terraform

Comencemos con la gestión básica de usuarios y grupos.

Crear un Usuario IAM

Para crear un usuario IAM, utilizamos el recurso aws_iam_user.

resource "aws_iam_user" "developer" {
  name = "developer-user"
  path = "/system/developers/"
  tags = {
    Environment = "Development"
    Project     = "MyWebApp"
  }
}

Este código creará un usuario llamado developer-user en el path /system/developers/. El path es útil para organizar usuarios en una estructura jerárquica.

Crear un Grupo IAM

Para agrupar usuarios y aplicarles políticas de forma colectiva, usamos aws_iam_group.

resource "aws_iam_group" "developers" {
  name = "DevelopersGroup"
  path = "/system/"
}

Añadir un Usuario a un Grupo

Una vez que tienes un usuario y un grupo, puedes añadir el usuario al grupo con aws_iam_group_membership.

resource "aws_iam_group_membership" "developer_membership" {
  group = aws_iam_group.developers.name
  users = [
    aws_iam_user.developer.name
  ]
}

📜 Definiendo Políticas IAM con Terraform

Las políticas son el corazón de IAM. Terraform te permite definirlas de dos maneras principales: inline (incrustadas) o gestionadas.

Políticas Inline (incrustadas)

Las políticas inline se adjuntan directamente a un usuario, grupo o rol y se eliminan si el recurso principal se elimina. Son adecuadas para políticas pequeñas y específicas de un único recurso.

Aquí un ejemplo de política inline para un usuario, permitiéndole listar buckets S3:

resource "aws_iam_user_policy" "developer_s3_list_policy" {
  name   = "developer-s3-list-policy"
  user   = aws_iam_user.developer.name
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action   = [
          "s3:ListAllMyBuckets",
          "s3:GetBucketLocation"
        ]
        Effect   = "Allow"
        Resource = "*"
      },
    ]
  })
}

Políticas Gestionadas IAM

Las políticas gestionadas son entidades de IAM independientes que puedes adjuntar a múltiples usuarios, grupos o roles. Esto promueve la reutilización y facilita la auditoría. AWS proporciona políticas gestionadas predefinidas, pero también puedes crear las tuyas.

Creando una Política Gestionada Personalizada

resource "aws_iam_policy" "s3_read_only_policy" {
  name        = "S3ReadOnlyAccessMyWebApp"
  description = "Permite acceso de solo lectura a un bucket específico de S3 para MyWebApp"
  policy      = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = [
          "s3:GetObject",
          "s3:ListBucket"
        ]
        Resource = [
          "arn:aws:s3:::my-webapp-data-bucket",
          "arn:aws:s3:::my-webapp-data-bucket/*"
        ]
      },
    ]
  })
}

Adjuntando una Política Gestionada a un Grupo

Para adjuntar la política anterior al grupo de desarrolladores, usamos aws_iam_group_policy_attachment.

resource "aws_iam_group_policy_attachment" "developers_s3_read_attach" {
  group      = aws_iam_group.developers.name
  policy_arn = aws_iam_policy.s3_read_only_policy.arn
}

Adjuntando una Política Gestionada a un Usuario

Similarmente, para un usuario:

resource "aws_iam_user_policy_attachment" "developer_s3_read_attach" {
  user       = aws_iam_user.developer.name
  policy_arn = aws_iam_policy.s3_read_only_policy.arn
}

🎭 Gestión de Roles IAM con Terraform

Los roles son fundamentales para la comunicación entre servicios y para el acceso temporal.

Creando un Rol para una Instancia EC2

Imagina que tienes una aplicación web en una instancia EC2 que necesita leer y escribir datos en un bucket S3 específico.

Primero, defines la política de confianza del rol, que especifica qué entidades pueden asumir este rol. Para una instancia EC2, el principal de servicio es ec2.amazonaws.com.

data "aws_iam_policy_document" "ec2_assume_role" {
  statement {
    effect = "Allow"

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }

    actions = ["sts:AssumeRole"]
  }
}

resource "aws_iam_role" "ec2_s3_access_role" {
  name               = "EC2S3AccessRole"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume_role.json
  description        = "Un rol para instancias EC2 para acceder a S3"
}

Aquí, data "aws_iam_policy_document" es una data source que te permite construir un documento de política JSON de manera programática en Terraform sin crear el recurso de política en AWS. Luego, este JSON se usa en el argumento assume_role_policy del aws_iam_role.

Adjuntando Permisos al Rol

Ahora, definamos una política que permita a la instancia EC2 leer y escribir en un bucket S3 específico y adjuntémosla al rol.

data "aws_iam_policy_document" "s3_rw_policy_document" {
  statement {
    effect = "Allow"
    actions = [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ]
    resources = [
      "arn:aws:s3:::my-webapp-data-bucket",
      "arn:aws:s3:::my-webapp-data-bucket/*"
    ]
  }

  statement {
    effect = "Allow"
    actions = [
      "s3:ListBucket"
    ]
    resources = [
      "arn:aws:s3:::my-webapp-data-bucket"
    ]
  }
}

resource "aws_iam_policy" "ec2_s3_rw_policy" {
  name        = "EC2S3ReadWritePolicyMyWebApp"
  description = "Permisos de lectura/escritura en S3 para EC2"
  policy      = data.aws_iam_policy_document.s3_rw_policy_document.json
}

resource "aws_iam_role_policy_attachment" "ec2_s3_rw_attach" {
  role       = aws_iam_role.ec2_s3_access_role.name
  policy_arn = aws_iam_policy.ec2_s3_rw_policy.arn
}

Perfil de Instancia (Instance Profile)

Para que una instancia EC2 pueda asumir un rol, necesitas un aws_iam_instance_profile.

resource "aws_iam_instance_profile" "ec2_s3_access_profile" {
  name = "EC2S3AccessProfile"
  role = aws_iam_role.ec2_s3_access_role.name
}

Luego, cuando defines tu instancia EC2, la asocias con este perfil de instancia:

resource "aws_instance" "my_webapp_server" {
  # ... otros parámetros de la instancia ...
  ami                    = "ami-0abcdef1234567890" # Cambia por una AMI válida
  instance_type          = "t2.micro"
  iam_instance_profile   = aws_iam_instance_profile.ec2_s3_access_profile.name

  tags = {
    Name = "MyWebAppServer"
  }
}

✨ Buenas Prácticas y Consejos de Seguridad

• Principio de Mínimo Privilegio (PoLP): Siempre otorga solo los permisos absolutamente necesarios. Es mejor empezar con menos permisos y añadir más si es necesario, que empezar con demasiados.
• Usa Roles, no Usuarios con Claves de Acceso: Para servicios de AWS o aplicaciones, siempre usa roles. Las claves de acceso de usuario deben ser para personas que necesitan acceso programático o CLI y deben rotarse regularmente.
• Políticas Gestionadas vs. Inline: Prefiere políticas gestionadas para reutilización y mejor control. Las políticas inline pueden volverse difíciles de gestionar a medida que crece tu infraestructura.
• Variables de Terraform: Utiliza variables para nombres de recursos, ARNs de buckets, etc., para hacer tus módulos de IAM más genéricos y reutilizables.
• Módulos de Terraform: Encapsula tus configuraciones de IAM comunes en módulos de Terraform para mantener tu código DRY (Don't Repeat Yourself) y facilitar la estandarización.
• Auditoría y Monitoreo: Integra tus cambios de IAM en tu flujo de trabajo de CI/CD para que cada cambio sea revisado y aprobado. Usa AWS CloudTrail para registrar todas las actividades de la API de IAM.
• Evita Resource = "*": En la medida de lo posible, especifica los ARNs de los recursos exactos. Resource = "*" es una práctica peligrosa a menos que sea estrictamente necesario y bien justificado.

🔄 Aplicando y Gestionando Cambios

Una vez que hayas definido tus recursos de IAM en Terraform, el flujo de trabajo es el estándar:

1. terraform init: Inicializa tu directorio de trabajo y descarga los plugins necesarios.
2. terraform plan: Revisa los cambios que Terraform propone realizar. Es CRÍTICO revisar cuidadosamente cualquier cambio en IAM, ya que puede tener implicaciones de seguridad significativas.
3. terraform apply: Aplica los cambios a tu cuenta de AWS.

Para eliminar recursos de IAM creados por Terraform (por ejemplo, un usuario y sus políticas asociadas), puedes usar terraform destroy. Asegúrate siempre de entender qué se va a eliminar.

📈 Conclusión

La gestión de IAM con Terraform transforma una tarea compleja y propensa a errores en un proceso declarativo, reproducible y seguro. Al definir explícitamente usuarios, grupos, roles y políticas en código, ganas control, visibilidad y la capacidad de integrar la gestión de accesos en tu flujo de trabajo de infraestructura como código.

Esperamos que este tutorial te haya proporcionado una base sólida para empezar a gestionar tus permisos de AWS de manera efectiva y segura con Terraform. Recuerda siempre priorizar el principio de mínimo privilegio y auditar regularmente tus configuraciones de IAM.

¡Feliz infra-codificación! 🚀