Solución de problemas de 'Acceso Denegado' y problemas de autenticación en AWS CLI

Acceso Denegado en AWS CLI es frustrante porque el mensaje a menudo nombra la llamada API fallida, pero no la línea de política que la causó. Estos problemas casi siempre tienen su origen en políticas de Identity and Access Management (IAM) mal configuradas, credenciales temporales caducadas o una configuración incorrecta del entorno CLI.

El hábito útil es dividir el problema en dos preguntas: ¿quién está llamando el CLI? y ¿qué límite de política está impidiendo que esa identidad realice la acción?

1. Diagnóstico inicial: Identificar la identidad y las credenciales

Antes de sumergirse en un análisis complejo de políticas, el primer paso es confirmar de manera definitiva qué identidad IAM está utilizando AWS CLI y si esas credenciales siguen siendo válidas.

Verificar la identidad actual: `sts get-caller-identity`

Este es el comando de diagnóstico más crítico. Le indica exactamente qué ARN de usuario, ARN de rol o sesión de rol asumido está ejecutando los comandos posteriores de AWS.

aws sts get-caller-identity

Salida esperada:

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Si el ARN devuelto no coincide con el usuario o rol que espera, está operando bajo el perfil de AWS o las variables de entorno incorrectas.

Verificar la configuración del perfil y la región

Asegúrese de que se esté utilizando el perfil de AWS correcto, ya sea especificado mediante el indicador --profile o configurado mediante la variable de entorno AWS_PROFILE.

# Verificar la configuración del perfil predeterminado
aws configure list

# O verificar un perfil específico
aws configure list --profile prod-admin

Si la salida no muestra ninguna región o muestra una región incorrecta, las operaciones en recursos globales o servicios específicos de región (como buckets S3 o instancias EC2) pueden fallar, a veces resultando en un Acceso Denegado si el recurso no se encuentra donde el CLI está buscando.

Consejo: Si el comando sts get-caller-identity falla con un error de autenticación, indica un problema fundamental con las claves de acceso (pueden haber sido eliminadas, revocadas o ser incorrectas).

Tratar con credenciales temporales

Si está utilizando un rol IAM (a través de STS AssumeRole), el CLI opera con credenciales temporales que incluyen un SessionToken. Estas credenciales caducan después de la duración configurada para la sesión, a menudo una hora en configuraciones predeterminadas. Aunque AWS CLI normalmente las actualiza automáticamente cuando se obtienen de la cadena de proveedores de credenciales estándar, las configuraciones manuales pueden fallar.

Síntoma: Los comandos funcionan inicialmente, pero fallan después de un período determinado (por ejemplo, 60 minutos) con un error de autenticación.

Solución: Si utiliza un script personalizado o un entorno cargado manualmente, asegúrese de que su método para asumir el rol incluya un mecanismo para actualizar las credenciales cuando caduquen.

2. Análisis profundo de políticas IAM y autorización

Una vez que confirme la identidad que se está utilizando, el siguiente paso es determinar por qué esa identidad carece de los permisos necesarios. Los fallos de autorización de AWS son complejos porque se evalúan múltiples políticas simultáneamente.

La jerarquía de evaluación de políticas IAM

Los errores de autorización generalmente ocurren debido a uno de los siguientes componentes de política:

Denegación explícita: Una declaración de Denegar explícita en cualquier política aplicable (Identidad, Recurso o Límite) siempre anula una declaración de Permitir.
Falta de permiso: Ninguna política aplicable a la identidad o recurso concede la acción específica.

A. Políticas basadas en identidad (usuarios y roles)

Verifique las políticas IAM adjuntas directamente al usuario o al rol que se está asumiendo. Busque:

Acciones faltantes: ¿La política enumera específicamente la acción API necesaria (por ejemplo, s3:ListBucket, ec2:DescribeInstances)?
Restricciones de recursos: ¿La política restringe la acción a recursos específicos usando el elemento Resource? Un error común es establecer Resource: "*" cuando la acción requiere un ARN específico, o viceversa.
Condiciones: ¿Hay condiciones (por ejemplo, dirección IP de origen, hora del día, MFA requerido) que no se están cumpliendo?

B. Políticas basadas en recursos (S3, SQS, KMS)

Para servicios como S3 o KMS, el recurso en sí tiene una política que dicta quién puede acceder a él. Para el acceso entre cuentas, y para muchos diseños específicos de recursos, la política del recurso también debe permitir al principal. En la misma cuenta, la interacción exacta depende del tipo de principal y del servicio, por lo que no asuma que una política de identidad por sí sola explica cada resultado.

Ejemplo: Intentar acceder a un bucket S3 (Política de recurso) que tiene una Denegar explícita para todos los usuarios fuera de un endpoint VPC específico resultará en Acceso Denegado, independientemente de la política IAM del usuario.

C. Límites de permisos y SCP

Si su organización utiliza AWS Organizations, las Políticas de control de servicio (SCP) definen los permisos máximos permitidos dentro de una cuenta. De manera similar, los Límites de permisos limitan los permisos máximos que una entidad IAM puede poseer.

Si la SCP o el Límite deniega la acción requerida, la operación CLI fallará, incluso si la Política de identidad concede el permiso.

Herramienta práctica: Simulador de políticas IAM

Al solucionar fallos complejos, el Simulador de políticas IAM en la Consola de administración de AWS es invaluable. Puede probar una acción específica (por ejemplo, s3:GetObject) contra un recurso específico (por ejemplo, arn:aws:s3:::my-bucket/key) y especificar la entidad IAM, lo que ayuda a identificar exactamente qué declaración de política está causando la denegación.

3. Escenarios comunes de 'Acceso Denegado' y soluciones

Escenario 1: Acceso denegado a S3 (recurso vs. identidad)

El Acceso Denegado de S3 es notorio porque puede deberse tanto a la Política de usuario como a la Política de bucket.

Causa	Diagnóstico	Solución
Falta de permiso en la Política de bucket	`sts get-caller-identity` funciona, pero `aws s3 ls` falla.	Modifique la Política de bucket para permitir explícitamente que el ARN que llama realice las acciones necesarias (`s3:ListBucket`, `s3:GetObject`).
Falta de permisos de descifrado KMS	Acceder a objetos cifrados falla (incluso si la política S3 lo permite).	Asegúrese de que la entidad IAM tenga permisos para usar la clave KMS subyacente (`kms:Decrypt`) que cifró el objeto.
Requester Pays	Los intentos de descargar archivos grandes fallan.	Si el bucket requiere `Requester Pays`, el comando CLI debe incluir el indicador `--request-payer requester`.

Escenario 2: Denegación implícita debido a fallos de condición

Muchas políticas utilizan condiciones que aplican las mejores prácticas de seguridad, como requerir autenticación multifactor (MFA).

Si su política incluye una condición como:

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

E intenta ejecutar un comando sin MFA autenticado, la acción será denegada implícitamente.

Solución: Para comandos que requieren MFA, primero debe crear una sesión STS autenticada con su dispositivo MFA:

# 1. Obtener credenciales temporales usando su token MFA
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Exporte el AccessKeyId, SecretAccessKey y SessionToken resultantes como variables de entorno para su sesión CLI.

Escenario 3: Región faltante o incorrecta

Aunque no siempre es un error de Acceso Denegado, intentar realizar una acción en un recurso sin especificar la región correcta a menudo conduce a fallos de autorización o de recurso no encontrado, especialmente al trabajar con servicios regionales como EC2, DynamoDB o EKS.

Solución: Defina explícitamente la región en su comando o asegúrese de que su perfil esté configurado correctamente.

aws ec2 describe-instances --region us-west-2

Verificaciones específicas de servicio que ahorran tiempo

Los errores de IAM son más fáciles de depurar cuando deja de tratar AWS como un solo sistema de permisos. Cada servicio agrega su propio modelo de recursos y claves de condición.

Para S3, separe las acciones a nivel de bucket de las acciones a nivel de objeto. s3:ListBucket usa el ARN del bucket, mientras que s3:GetObject y s3:PutObject usan ARN de objeto bajo el bucket. Una política que concede s3:GetObject en arn:aws:s3:::my-bucket tiene una forma incorrecta; el acceso a objetos necesita arn:aws:s3:::my-bucket/*. El error inverso es igualmente común para listar.

Para KMS, verifique tanto la política de clave como la política IAM. Un rol puede parecer que tiene kms:Decrypt, pero si la política de clave no permite esa ruta de rol, el descifrado aún falla. Esto aparece al descargar objetos S3 cifrados, extraer instantáneas EBS cifradas o leer secretos que usan una clave administrada por el cliente.

Para ECR, el inicio de sesión de Docker y la extracción de imágenes requieren que varios servicios se alineen. La identidad CLI puede necesitar ecr:GetAuthorizationToken, y la política del repositorio puede necesitar permitir acciones de extracción si el repositorio se comparte entre cuentas. Si el rol del nodo del clúster está extrayendo la imagen, depurar con su perfil de administrador personal no prueba mucho; pruebe como el rol del nodo o el rol de ejecución de tarea.

Para flujos de trabajo de asunción de roles STS, observe ambos lados de la relación de confianza. La entidad que llama necesita permiso para llamar a sts:AssumeRole, y la política de confianza del rol de destino debe confiar en la entidad que llama. Si hay un ID externo o una condición MFA presente en la política de confianza, el comando de asunción de rol debe satisfacerla.

La precedencia del entorno puede engañar a usuarios experimentados

AWS CLI no solo lee ~/.aws/credentials. Recorre una cadena de proveedores de credenciales que puede incluir indicadores de línea de comandos, variables de entorno, perfiles con nombre, entradas de caché SSO, tokens de identidad web, metadatos EC2 o ECS y suposiciones de rol configuradas en el perfil. Por eso aws configure list es más útil que abrir un archivo.

Un fallo local común se ve así: ejecuta export AWS_PROFILE=dev, luego pega credenciales de producción temporales en AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN. Las claves de entorno pueden tomar el control, por lo que los comandos que parecen usar dev en realidad están usando la sesión exportada. En una terminal que ha estado abierta todo el día, ejecute:

env | sort | grep '^AWS_'

Si cambia de cuenta con frecuencia, use pestañas de terminal separadas, un ayudante de credenciales o scripts contenedores que impriman la identidad de la entidad que llama antes de los comandos destructivos. La línea adicional en la salida es más barata que eliminar de la cuenta equivocada.

4. Resumen de comandos de diagnóstico

Use esta lista de verificación de comandos para diagnosticar rápidamente la cadena de fallos de autorización:

Objetivo	Comando	Propósito
Verificar identidad	`aws sts get-caller-identity`	Confirma el ARN que ejecuta el comando.
Verificar configuración	`aws configure list`	Verifica la configuración del perfil, la región y el formato de salida.
Probar validez de la política	(Usar Simulador de políticas IAM)	Verifica si una identidad IAM puede realizar una acción API específica en un recurso.
Identificar denegaciones de política	`aws cloudtrail lookup-events ...`	Use CloudTrail para ver el registro de eventos exacto donde falló la evaluación de la política.

Una ruta de depuración real

Un primer pase bueno se ve así. Ejecute el comando fallido nuevamente con el perfil y la región escritos explícitamente, incluso si cree que su shell ya está configurado:

AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly

Si la identidad es incorrecta, deténgase ahí. Verifique AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE y AWS_REGION en el entorno. Las credenciales de entorno pueden tener prioridad sobre un perfil y hacer que el CLI actúe como un rol que olvidó que exportó antes. En CI, imprima aws sts get-caller-identity cerca del paso fallido para que el registro de compilación demuestre el rol utilizado en tiempo de ejecución.

Si la identidad es correcta, anote la acción API exacta. Los comandos de alto nivel pueden ocultar esto. aws s3 cp puede necesitar s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt o kms:GenerateDataKey dependiendo de la dirección, el cifrado y si el CLI debe inspeccionar el bucket. Cuando el mensaje de error incluye AccessDenied pero no la acción, CloudTrail generalmente le da el nombre del evento y el recurso.

Para S3, verifique la política del bucket, la propiedad del objeto, la configuración de bloqueo de acceso público, la política del endpoint VPC y la política de la clave KMS. Para objetos cifrados con KMS, un permiso S3 no es suficiente; la entidad que llama también necesita el permiso KMS relevante y la política de la clave debe permitir la ruta del principal. Para organizaciones, verifique las SCP antes de editar las políticas de identidad. Una SCP no puede conceder acceso, pero puede limitar lo que cualquier principal en la cuenta puede hacer.

La prevención es principalmente higiene aburrida: credenciales de rol de corta duración, perfiles claramente nombrados, políticas de privilegio mínimo probadas contra el ARN real y CloudTrail habilitado donde los ingenieros puedan consultarlo realmente. La mejor solución no es una Action: "*" más amplia; es encontrar la acción faltante o la condición de denegación que coincida con la solicitud.