Un CLI offline predice si tu trust policy de AWS aceptara el token OIDC de GitHub Actions

Un desarrollador ha publicado gha-oidc-claimsim, una herramienta de linea de comandos con licencia Apache-2.0 que simula si una trust policy de AWS IAM aceptaria el token OIDC que emite GitHub Actions. Recibe dos JSON —el contexto del evento del workflow y la politica de confianza— y devuelve ALLOW o DENY con los motivos. No habla con STS, no necesita credenciales de AWS y no toca la red.

Que resuelve

El caso tipico que motiva la herramienta: una trust policy anclada a una rama, del estilo repo:ORG/REPO:ref:refs/heads/main, que rechaza los jobs de pull_request. El sub por defecto en ese evento es repo:ORG/REPO:pull_request, asi que la condicion no encaja y el AssumeRoleWithWebIdentity falla con un error poco descriptivo en mitad del pipeline. Depurar eso suele ser ensayo y error contra la cuenta real. Aqui el calculo se reproduce en local: dado el evento y la politica, se predicen el sub y el aud por defecto y se comprueba si la condicion los acepta.

El autor ha sido bastante explicito con el alcance, algo que no siempre se ve en un lanzamiento de este tamano. La herramienta esta en release candidate, 0.1.0-rc.2, y no es una version estable. No esta publicada en PyPI: se instala desde el repositorio o desde la release en GitHub, lo que para un equipo con runners sin salida a internet significa vendorizar el codigo o montar un indice propio.

Las limitaciones que reconoce el propio autor son las que importan a quien vaya a meterlo en un pipeline. El modelo de condiciones de IAM esta simplificado y no es identico bit a bit al de AWS, de modo que un ALLOW de la herramienta no es una garantia de que STS vaya a conceder el rol: es una prediccion, no una validacion. La comprobacion opcional de claves duplicadas en HCL es una comodidad y el autor recomienda usar tflint para eso. Y no es un linter de subs ausentes al estilo Checkov ni un escaner de cuentas en vivo, dos cosas que el nombre puede hacer pensar.

Donde encaja

El hueco es razonable. Validar trust policies contra OIDC hoy pasa por aplicar el cambio y ver que revienta en el CI, o por montar un entorno de pruebas con su propio proveedor de identidad. Una herramienta que corre en un portatil, sin red y sin cuenta, baja el coste de iterar sobre la gramatica de claims. Para equipos de plataforma que gestionan muchas politicas de confianza entre cuentas, ese bucle corto es la diferencia entre revisar un cambio en un minuto o desplegarlo a ver que pasa.

Lo que queda por ver es si el modelo simplificado de claims aguanta los casos raros que aparecen en produccion: condiciones compuestas, comodines y contexto de reutilizacion de workflows. Mientras siga en release candidate y la instalacion sea manual, su sitio natural es el portatil de quien escribe la politica, no el gate de un despliegue.