AWS IAM Policy Generator: Políticas de IAM, de bucket S3 y de confianza con mínimo privilegio — en JSON o Terraform.
Se ejecuta en tu navegador: nada de lo que pegas sale de esta página. Cómo lo demostramos
Playground de AWS IAM Policy Generator
s3:ListBucket acts on the bucket ARN and s3:GetObject on object ARNs (bucket/*), so they need separate resources — granting both on one ARN leaves one of them with no effect.
Selected: s3:ListBucket
Filled from the AWS ARN format of each action's resource type until you edit it. Replace every ${…} placeholder.
Results update as you type — press Enter to run now.
Policy JSON
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket"
},
{
"Sid": "ReadObjects",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}Action data: AWS Service Reference, retrieved 2026-10-04
Elige un servicio, las acciones y los recursos sobre los que actúan, añade condiciones y obtén una política de identidad de IAM, una política de bucket S3 o una política de confianza de rol válida, en JSON y como aws_iam_policy_document de Terraform — con el tamaño comprobado frente a la cuota de AWS y un aviso en cada comodín, todo calculado en tu navegador, sin registro.
La brecha
"Action": "*" funciona. Ese es el problema.
AWS evalúa tres tipos de política que escribirás a mano. Una política de identidad se adjunta a un usuario, grupo o rol y dice qué puede hacer ese principal, por eso no lleva elemento Principal. Una política basada en recursos — una política de bucket S3, una política de clave KMS, una política de cola SQS — se adjunta al recurso y debe indicar en Principal a quién se aplica. Una política de confianza es la política basada en recursos de un rol: decide quién puede asumirlo, normalmente con sts:AssumeRole o, para GitHub Actions y otros proveedores OIDC, con sts:AssumeRoleWithWebIdentity.
El mínimo privilegio consiste en conceder solo las acciones que llama una carga de trabajo, y solo sobre los recursos que toca. Una política con comodines pasa todas las pruebas y suspende la auditoría: las solicitudes se deniegan por defecto, un Deny explícito prevalece sobre cualquier Allow, y todo lo que una política permite lo puede hacer también una credencial filtrada. Acotar es delicado porque las acciones actúan sobre tipos de recurso distintos — s3:ListBucket sobre el ARN del bucket, s3:GetObject sobre bucket/*.
Las políticas también tienen límites de tamaño, contados sin espacios en blanco: 6.144 caracteres para una política administrada por el cliente; para las políticas en línea, 2.048 caracteres en total por usuario, 5.120 por grupo y 10.240 por rol; y 20 KB para una política de bucket S3. Una política que ha crecido sentencia a sentencia falla en el despliegue, no en la revisión.
El generador comprueba la gramática, las cuotas y los excesos de permisos habituales; no simula la evaluación de AWS. Confirma el acceso efectivo con IAM Access Analyzer o el simulador de políticas de IAM antes de producción.
El pipeline
Cómo funciona.
Cuatro pasos deterministas se ejecutan con cada cambio — todos dentro de la pestaña de tu navegador, con datos de acciones tomados de la AWS Service Reference.
-
Elige las acciones.
Elige un servicio y filtra sus acciones por nivel de acceso — List, Read, Write, Permissions management, Tagging. La lista de acciones procede de la AWS Service Reference y viaja con la página.
-
Acota los recursos.
Cada acción indica los tipos de recurso sobre los que actúa; el formato de ARN de ese tipo se rellena solo, así que sustituyes marcadores en lugar de escribir ARN de memoria.
-
Ensambla y comprueba.
Las sentencias forman un documento con Version 2012-10-17. Los Sid deben ser alfanuméricos y únicos, una política de bucket necesita un Principal y una de identidad no puede tenerlo, y se valida cada operador de condición.
-
Mide y avisa.
La política minificada se mide frente a la cuota que elijas, y se señalan las acciones comodín, Resource "*" en acciones de escritura, las acciones de gestión de permisos y un Principal "*" sin condición. Nada sale de la pestaña.
Referencia de políticas
Un bucket, solo lectura, dos formatos.
El primer preset tal como lo genera el panel: las mismas dos sentencias como JSON de política y como fuente de datos de Terraform.
Política de identidad en JSON
s3:ListBucket actúa sobre el bucket y s3:GetObject sobre sus objetos, así que cada sentencia lleva su propio ARN. Minificada, ocupa 248 de los 6.144 caracteres que admite una política administrada.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListBucket",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example-bucket"
},
{
"Sid": "ReadObjects",
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*"
}
]
}La misma política en Terraform
Pasa data.aws_iam_policy_document.policy.json a un recurso aws_iam_policy o aws_iam_role_policy.
data "aws_iam_policy_document" "policy" {
statement {
sid = "ListBucket"
effect = "Allow"
actions = ["s3:ListBucket"]
resources = ["arn:aws:s3:::example-bucket"]
}
statement {
sid = "ReadObjects"
effect = "Allow"
actions = ["s3:GetObject"]
resources = ["arn:aws:s3:::example-bucket/*"]
}
}Siguiente paso
¿Despliegas desde GitHub Actions? Olvídate de las access keys.
Una política de confianza OIDC permite que un workflow asuma un rol con credenciales de corta duración, fijado a un repositorio y una rama. La guía (en inglés) recorre el proveedor de identidad, la política de confianza, configure-aws-credentials y la misma configuración en Terraform.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:ref:refs/heads/main"
}
}
}
]
}FAQ
Tus preguntas, respondidas.
Toca una pregunta para desplegar la respuesta.
¿Qué es una política de IAM y en qué se diferencian las políticas basadas en identidad y las basadas en recursos?
Una política de IAM es un documento JSON que indica qué acciones se permiten o deniegan sobre qué recursos, opcionalmente bajo ciertas condiciones. Una política basada en identidad se asocia a un usuario, grupo o rol y otorga sus permisos a esa identidad, por eso no lleva elemento Principal. Una política basada en recursos se asocia al propio recurso —un bucket de S3, una cola de SQS, una clave de KMS— y debe indicar el Principal al que se aplica. Cuando ambas se aplican a una solicitud dentro de la misma cuenta, AWS las combina, y un Deny explícito en cualquiera de ellas siempre prevalece.
¿Qué diferencia hay entre una política de IAM y una política de bucket de S3?
El elemento Principal. Una política de IAM se asocia a un usuario, grupo o rol, así que el principal está implícito y el elemento no se permite. Una política de bucket se asocia al bucket, así que cada declaración debe decir a quién se aplica: otra cuenta, el ARN de un rol, un servicio como cloudfront.amazonaws.com o "*" para todos. El generador lo aplica en ambos sentidos: exige un Principal en modo bucket, lo rechaza en modo identidad y avisa cuando una declaración de bucket concede Principal "*" sin Condition.
¿Cómo escribo una política de IAM de mínimo privilegio?
Conceda solo las acciones que la carga de trabajo llama de verdad y solo sobre los recursos que toca: acciones concretas en lugar de s3:* o *, y ARN reales en Resource en lugar de "*". Añada condiciones donde restrinjan más el acceso, por ejemplo aws:SourceVpce, aws:PrincipalOrgID o una etiqueta del recurso. Después deje que AWS revise el resultado: IAM Access Analyzer valida una política frente a las buenas prácticas de AWS y puede generar una política con las acciones que un rol ha usado realmente, a partir de su historial de CloudTrail. El generador marca las acciones comodín, Resource "*" en acciones de escritura y de gestión de permisos, y Allow con NotAction.
¿Qué límites de tamaño tienen las políticas de IAM y de bucket?
Una política administrada por el cliente puede tener como máximo 6144 caracteres. Las políticas insertadas se limitan por identidad, como la suma de todas las políticas insertadas que tiene asociadas: 2048 caracteres para un usuario, 10 240 para un rol y 5120 para un grupo. IAM no cuenta los espacios en blanco para estos límites, por eso el medidor de tamaño mide el JSON minificado. Una política de bucket de S3 tiene su propio límite de 20 KB, y ninguno de estos límites de caracteres puede ampliarse con una solicitud de cuota.
¿Cómo uso la política generada con Terraform?
La pestaña Terraform escribe las mismas declaraciones como un bloque data "aws_iam_policy_document", que Terraform convierte en JSON al planificar. Haga referencia a su atributo json allí donde se espere una política: policy = data.aws_iam_policy_document.example.json en un aws_iam_policy para una política administrada, en un aws_iam_role_policy para una política insertada de rol o en un aws_s3_bucket_policy para una política de bucket. Si prefiere conservar el JSON tal cual, también sirven jsonencode() o un heredoc, pero la fuente de datos mantiene la política en HCL, donde los diffs son limpios.
¿De dónde sale la lista de acciones?
De la AWS Service Reference, los archivos JSON legibles por máquina que AWS publica para cada servicio con sus acciones, tipos de recurso y claves de condición. La página indica la fecha en que se obtuvieron los datos, y la lista cubre 12 servicios de uso habitual: S3, EC2, Lambda, DynamoDB, IAM, CloudWatch Logs, SQS, SNS, KMS, STS, Secrets Manager y ECR. Cada acción lleva su nivel de acceso —Read, List, Write, Permissions management o Tagging— y los tipos de recurso a los que puede limitarse, que es lo que alimenta las plantillas de ARN y los avisos. Para cualquier otro servicio, la lista de referencia es la Service Authorization Reference de la documentación de AWS.
¿Qué es una política de confianza?
Una política de confianza es la política basada en recursos asociada a un rol de IAM que indica quién puede asumirlo; las políticas de permisos del rol indican después qué puede hacer ese principal una vez asumido. Para GitHub Actions con OIDC, la política de confianza permite sts:AssumeRoleWithWebIdentity al principal federado token.actions.githubusercontent.com, con condiciones que exigen que el claim aud sea sts.amazonaws.com y que el claim sub coincida con su repositorio, por ejemplo repo:my-org/my-repo:ref:refs/heads/main — o, para repositorios creados después del 15 de julio de 2026, la forma inmutable repo:my-org@<owner-id>/my-repo@<repo-id>:ref:refs/heads/main. Sin la condición sobre sub, cualquier repositorio de GitHub podría asumir el rol. La política de confianza de un rol se limita por defecto a 2048 caracteres, ampliable hasta 8192.
¿Mi política sale alguna vez del navegador?
No. El generador se ejecuta al 100 % en el cliente: el catálogo de acciones viene con la página y cada política se construye en la pestaña de su navegador. No se sube nada a ningún servidor, no hay cuenta ni registro, y el enlace para compartir codifica su política en el fragmento de la URL, que los navegadores nunca envían a un servidor.
More free, private DevOps tools.
El AWS IAM Policy Generator es una de las herramientas de OpsCanopy — un dosel creciente de validadores, conversores y testers basados en el navegador que nunca tocan un servidor.
Más en Seguridad
¿Empiezas con AWS? Lee la guía de AWS →
42 herramientas gratuitas, todas pueden funcionar sin conexión — opscanopy.com funciona sin registro y sin subir nada.
Más para proteger un pipeline: el JWT Decoder y el Certificate Decoder, o explora el directorio de herramientas.
El generador comprueba la estructura, las cuotas y los excesos de permisos habituales, pero no evalúa SCP, límites de permisos ni políticas de sesión — prueba con IAM Access Analyzer antes de desplegar. OpsCanopy es gratuito y abierto.