GitHub habilitó en preview que los tokens OIDC de Actions incluyan propiedades personalizadas de repositorio, permitiendo políticas ABAC más precisas en AWS, Azure y GCP sin editar cada workflow. Para Platform y DevSecOps, el cambio reduce drift de permisos y mejora el gobierno de identidades de CI/CD.
Introducción
En la mayoría de organizaciones que ya migraron de secretos estáticos a OIDC en GitHub Actions, el siguiente problema no es técnico sino operativo: cómo sostener políticas de acceso consistentes cuando crecen los repositorios, equipos y entornos. Muchas implementaciones terminan con listas manuales por repositorio, reglas duplicadas y excepciones difíciles de auditar en la nube.
La novedad publicada por GitHub el 19 de marzo de 2026 apunta justo a ese punto: incorporar propiedades personalizadas de repositorio como claims dentro del token OIDC. En términos prácticos, una etiqueta de gobierno definida a nivel organización (por ejemplo, workspace_id, criticality, data_class) puede viajar automáticamente en el JWT que consume el proveedor cloud para autorizar el acceso.
Qué ocurrió
GitHub anunció que los tokens OpenID Connect de Actions ahora pueden incluir propiedades custom de repositorio con prefijo repo_property_*. Además, habilitó una nueva interfaz de configuración (preview) para administrar estos claims desde repositorio, organización o enterprise, además de la vía API.
El objetivo explícito es facilitar modelos ABAC (Attribute-Based Access Control) en lugar de depender sólo de allow-lists o de ajustes workflow por workflow. Una vez que el administrador agrega una propiedad al set de claims permitidos, cualquier repositorio que tenga valor para esa propiedad la incorpora automáticamente en sus tokens OIDC.
Esto permite, por ejemplo, condicionar roles cloud usando atributos de gobierno que ya existían en GitHub, sin replicar ese metadato en cada pipeline ni mantener reglas separadas por proyecto.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma, el impacto principal está en el control de acceso a infraestructura desde CI/CD. La gestión por atributos reduce la dependencia de naming conventions frágiles y baja el costo de onboarding de repos nuevos: si el repositorio hereda la propiedad correcta, puede cumplir políticas sin cambios manuales de workflow.
En seguridad, la mejora ayuda a aplicar mínimo privilegio con más granularidad. Se puede atar el acceso a credenciales cloud a atributos como tipo de workload, entorno permitido o dominio de negocio, disminuyendo la posibilidad de que un pipeline legítimo obtenga permisos fuera de su alcance operativo.
En operaciones, también reduce drift. Cuando una política depende de metadata central y no de archivos YAML dispersos, es más fácil auditar, detectar inconsistencias y ejecutar cambios globales sin romper decenas de repositorios. Esto no elimina la necesidad de revisión de trust policies en cloud, pero sí ordena el plano de identidad entre GitHub y los proveedores externos.
Detalles técnicos
La documentación de GitHub explica que el token OIDC conserva los claims estándar (iss, aud, sub) y suma claims custom, entre ellos los nuevos repo_property_*. En el flujo normal, un job solicita el token a token.actions.githubusercontent.com, lo presenta al proveedor cloud y éste evalúa condiciones de confianza antes de emitir credenciales temporales.
Con este cambio, la decisión de acceso puede basarse en atributos de repositorio administrados centralmente. Eso habilita patrones útiles para plataformas multi-equipo:
- Roles cloud distintos según criticidad o clasificación del repositorio.
- Acceso restringido por unidad de negocio sin duplicar workflows.
- Políticas transversales para AWS/Azure/GCP usando el mismo metadato fuente.
Hay, sin embargo, dos límites prácticos que conviene considerar. Primero, la función está en preview y puede cambiar. Segundo, si la higiene de propiedades en GitHub es pobre (valores faltantes o inconsistentes), la política ABAC puede degradarse rápidamente. En otras palabras, el valor del feature depende de disciplina de gobierno de metadata.
Qué deberían hacer los administradores o equipos técnicos
- Inventariar propiedades de repositorio y definir un set mínimo útil para autorización cloud (por ejemplo: entorno, criticidad, dominio, owner).
- Activar gradualmente claims OIDC custom en una unidad piloto antes de escalar a toda la organización.
- Ajustar trust policies en AWS/Azure/GCP para validar claims
repo_property_*con reglas explícitas de mínimo privilegio. - Implementar validaciones de metadata (linters/policies) para evitar repos sin propiedades obligatorias.
- Monitorear denegaciones y drift de autenticación tras el cambio, con métricas de acceso fallido por claim.
- Documentar runbooks para onboarding de repos nuevos y cambios de clasificación sin romper pipelines existentes.
Conclusión
El soporte de propiedades personalizadas en tokens OIDC de GitHub Actions es una mejora pequeña en apariencia, pero relevante en operación real. Ataca una fricción recurrente de equipos DevOps y seguridad: mantener coherencia entre gobierno de repositorios y autorización cloud sin acumular lógica manual en cada pipeline.
Si se implementa con criterios claros de metadata y políticas bien acotadas, el cambio puede reducir riesgo operativo y simplificar la evolución de CI/CD a escala. La clave no está sólo en habilitar la feature, sino en convertirla en un modelo de gobierno sostenible para identidades de máquina.
Fuentes
- GitHub Changelog: OIDC con propiedades personalizadas
- GitHub Docs: OpenID Connect en Actions
- GitHub Docs: referencia de claims OIDC