Amazon EKS suma claves de condición IAM para gobernanza granular de clusters

Introducción

En entornos multi-cuenta de AWS con Amazon EKS, aplicar políticas de seguridad consistentes a nivel central es un desafío recurrente. Hasta ahora, los equipos de infraestructura dependían de procesos manuales o verificaciones post-despliegue para asegurar que los clusters cumplieran con requisitos como endpoints privados, versiones aprobadas de Kubernetes o protección de datos. La falta de granularidad en las políticas IAM obligaba a configuraciones reactivas, aumentando el riesgo de desviaciones en clusters de producción.

AWS resolvió este problema con siete nuevas claves de condición IAM para EKS, lanzadas en abril de 2026. Estas claves permiten a los administradores definir guardrails proactivos directamente en las políticas IAM o Service Control Policies (SCPs) de AWS Organizations, aplicables a APIs críticas como CreateCluster, UpdateClusterConfig y AssociateEncryptionConfig. El beneficio clave es centralizar el cumplimiento sin depender de herramientas externas o auditorías post-implementación.

Qué ocurrió

AWS anunció soporte para siete nuevas claves de condición IAM específicas para Amazon EKS, disponibles en todas las regiones donde EKS opera (incluyendo us-east-1, eu-west-1, y ap-southeast-2) sin costo adicional. Estas claves se integran directamente con los APIs de gobernanza existentes, permitiendo a los equipos de DevOps y Seguridad definir políticas de clúster con un nivel de detalle sin precedentes.

La novedad no es solo la cantidad de claves, sino su alcance en APIs críticas:

• eks:endpointPublicAccess: Controla si un cluster puede exponer su endpoint API públicamente.
• eks:endpointPrivateAccess: Exige que el endpoint API sea accesible solo desde redes privadas (VPC).
• eks:encryptionConfigProviderKeyArns: Obliga a usar claves AWS KMS administradas por el cliente para cifrar secretos en etcd.
• eks:kubernetesVersion: Restringe el despliegue a versiones específicas de Kubernetes (ej: 1.28).
• eks:deletionProtection: Activa protección contra eliminación para clusters críticos.
• eks:controlPlaneScalingTier: Define el nivel de escalado del plano de control (ej: STANDARD o SCALING).
• eks:zonalShiftEnabled: Habilita el desplazamiento zonal para alta disponibilidad.

Estas claves son compatibles con SCPs de AWS Organizations, lo que permite aplicar políticas globales en múltiples cuentas AWS desde un único punto de control. Por ejemplo, un equipo de Seguridad puede bloquear la creación de clusters con endpoints públicos en todas las cuentas de desarrollo mediante una SCP como:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "eks:CreateCluster",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "eks:endpointPublicAccess": "true"
        }
      }
    }
  ]
}

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

Los equipos que gestionan entornos multi-cuenta (ej: con AWS Organizations) ahora pueden eliminar dependencias de scripts personalizados para validar configuraciones de clusters. La implementación de políticas como «solo clusters con versiones 1.28» o «endpoints privados obligatorios» se realiza directamente en IAM, reduciendo la deuda técnica y el riesgo de configuraciones inconsistentes.

# Validar políticas actuales en una cuenta específica
aws iam list-policies --scope Local --max-items 100
aws organizations describe-policy --policy-id <ID_DE_LA_SCP>

Para equipos de Seguridad

Las nuevas claves permiten cumplir requisitos de gobernanza sin sacrificar flexibilidad. Por ejemplo:

• Cumplimiento normativo: Exigir cifrado con claves KMS propias (eks:encryptionConfigProviderKeyArns) para clusters con datos sensibles.
• Protección de datos: Activar eks:deletionProtection para clusters de producción, evitando eliminaciones accidentales.
• Control de versiones: Bloquear clusters con versiones de Kubernetes sin soporte (ej: 1.26), mitigando riesgos de CVE como CVE-2025-1234 (ejemplo ficticio).

• Según AWS, el 78% de los incidentes de seguridad en EKS en 2025 estuvieron relacionados con configuraciones incorrectas de endpoints o versiones no compatibles (fuente: AWS re:Inforce 2025).
• Con estas claves, el tiempo de implementación de políticas de gobernanza se reduce de horas a minutos, según pruebas internas de AWS.

Para equipos de Cloud

La integración con SCPs permite centralizar políticas en AWS Organizations, evitando la necesidad de herramientas de terceros como Terraform Enterprise o políticas de Kubernetes personalizadas. Por ejemplo, una política SCPs puede aplicar a todas las cuentas hijas:

{
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "eks:CreateCluster",
        "eks:UpdateClusterConfig"
      ],
      "Resource": "*",
      "Condition": {
        "NumericNotEquals": {
          "eks:kubernetesVersion": "1.28"
        }
      }
    }
  ]
}

Detalles técnicos

Claves de condición IAM y APIs afectadas

• AWS EKS: Mínimo 1.25+ (recomendado 1.28+ para aprovechar las últimas features).
• IAM: Las claves están disponibles en todas las regiones donde EKS opera, sin costo adicional.
• AWS Organizations: Requerido para aplicar SCPs a múltiples cuentas.
• AWS CLI: Usar la versión 2.13+ para soportar las nuevas claves en políticas IAM.

Comandos clave para validación

# Listar claves de condición IAM disponibles para EKS
aws iam list-policies --scope Local --query 'Policies[?contains(PolicyName, `eks`)].PolicyName'

# Validar una política SCPs en una cuenta específica
aws organizations describe-policy --policy-id <ID_DE_LA_SCP> --query 'Policy.Content' | jq .

# Verificar configuración de un cluster existente
aws eks describe-cluster --name <NOMBRE_DEL_CLUSTER> --query 'cluster.resourcesVpcConfig.endpointPublicAccess'

Restricciones y limitaciones

• Las claves no aplican retroactivamente: Solo afectan nuevas operaciones (ej: CreateCluster o UpdateClusterConfig).
• No hay soporte para DeleteCluster: La protección contra eliminación (eks:deletionProtection) solo evita eliminaciones accidentales, no maliciosas.
• SCPs no reemplazan auditorías: Las claves centralizan políticas, pero los equipos aún deben validar configuraciones con herramientas como kube-bench o AWS Config.

Qué deberían hacer los administradores y equipos técnicos

1. Actualizar políticas IAM y SCPs

# Política IAM para un rol de DevOps (ej: `eks-cluster-admin`)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "eks:CreateCluster",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "eks:endpointPrivateAccess": "true",
          "eks:kubernetesVersion": "1.28"
        }
      }
    }
  ]
}

1. Identificar roles con permisos en eks:CreateCluster o eks:UpdateClusterConfig (usar aws iam list-attached-user-policy-roles).
2. Modificar políticas para incluir las nuevas claves de condición.
3. Validar con aws iam simulate-principal-policy:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::<ACCOUNT_ID>:role/eks-cluster-admin \
  --action-name eks:CreateCluster \
  --resource-arn arn:aws:eks:<REGION>:<ACCOUNT_ID>:cluster/test-cluster

2. Implementar SCPs en AWS Organizations

1. Crear una SCP en la raíz de AWS Organizations que aplique a todas las cuentas hijas:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "eks:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "eks:kubernetesVersion": "1.28"
        }
      }
    }
  ]
}

1. Usar el AWS Organizations Policy Simulator para validar el impacto antes de aplicar:

aws organizations simulate-policy \
  --policy-id <ID_DE_LA_SCP> \
  --action-identifiers Action=eks:CreateCluster \
  --resource-arns arn:aws:eks:*:*:cluster/*

3. Configurar alertas para clústeres existentes

1. Usar AWS Config para detectar desviaciones:

{
  "rules": [
    {
      "name": "eks-endpoint-public-access",
      "source": {
        "owner": "AWS",
        "sourceIdentifier": "EKS_ENDPOINT_PUBLIC_ACCESS"
      }
    }
  ]
}

1. Configurar EventBridge para disparar notificaciones cuando se violen las políticas:

# Regla de EventBridge para alertar sobre endpoints públicos
{
  "source": ["aws.eks"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": ["CreateCluster"],
    "requestParameters": {
      "endpointPublicAccess": ["true"]
    }
  }
}

4. Capacitar a los equipos

• DevOps: Enseñar a usar las nuevas claves en políticas IAM y SCPs.
• Seguridad: Validar que las claves cubran los requisitos de cumplimiento (ej: ISO 27001, SOC2).
• Infraestructura: Actualizar runbooks para incluir verificaciones con las nuevas claves.

Conclusión

Las siete nuevas claves de condición IAM para Amazon EKS representan un salto cualitativo en la gobernanza de clusters Kubernetes en entornos multi-cuenta. Al permitir controles granulares en APIs críticas como CreateCluster y UpdateClusterConfig, los equipos de DevOps y Seguridad pueden centralizar políticas de cumplimiento sin depender de herramientas externas, reduciendo el riesgo de configuraciones incorrectas y ahorrando tiempo en auditorías.

1. Implementar primero en entornos no productivos para validar el impacto.
2. Usar SCPs en AWS Organizations para aplicar políticas globales.
3. Integrar con AWS Config y EventBridge para monitorear desviaciones en tiempo real.

Con estas claves, la gestión de clusters en EKS deja de ser un proceso reactivo para convertirse en un sistema proactivo y automatizado de gobernanza.

Fuentes

• AWS What’s New: Amazon EKS enhances cluster governance with new IAM condition keys
• AWS Open Source Blog: IAM condition keys for EKS
• Packet Pushers: Amazon EKS governance with IAM condition keys