Bajada
GitHub habilitó en vista previa una mejora de OIDC en Actions que permite incluir propiedades personalizadas del repositorio dentro del token de identidad. El cambio facilita controles ABAC más finos para acceso cloud desde CI/CD, reduce duplicación de reglas por repo y ayuda a estandarizar políticas de despliegue entre equipos grandes.
Introducción
La autenticación federada con OpenID Connect en GitHub Actions ya era una práctica recomendada para eliminar secretos estáticos en pipelines. Sin embargo, muchos equipos terminaban con políticas cloud difíciles de mantener: excepciones por repositorio, reglas copiadas entre cuentas y un alto riesgo de deriva entre lo que dice el gobierno de plataforma y lo que efectivamente se aplica en IAM.
Con la nueva capacidad anunciada por GitHub, los tokens OIDC pueden incorporar propiedades personalizadas de repositorio como claims `repo_property_*`. En términos prácticos, esto permite usar metadatos que ya existen en GitHub (por ejemplo, `criticality`, `data_class`, `team`, `workspace_id`, `env_scope`) para decidir qué rol o permisos puede asumir cada workflow en AWS, Azure, GCP u otros proveedores compatibles.
Qué ocurrió
El 12 de marzo de 2026, GitHub anunció que los tokens OIDC de Actions ahora pueden incluir propiedades personalizadas de repositorio, definidas a nivel organización o enterprise. La función llega en public preview junto con una nueva página de configuración para administrar estas claims desde la UI, además de la API.
La lógica del cambio es centralizar gobierno: en lugar de editar cada workflow para representar contexto organizacional, los administradores agregan una propiedad al conjunto de claims y todos los repositorios con ese valor comienzan a emitirlo automáticamente en sus tokens. Ese claim viaja firmado en el JWT y puede evaluarse en políticas de confianza del proveedor cloud.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de DevOps, plataforma y seguridad, el impacto es principalmente operativo:
– Menos fricción en onboarding: repos nuevos heredan acceso correcto según su metadata, sin tickets manuales para cada rol.
– Menos drift de IAM: la política se ata a atributos de repositorio, no a listas estáticas difíciles de mantener.
– Mejor separación de entornos: se pueden expresar condiciones tipo «solo repos con `repo_property_env=prod` pueden asumir rol de despliegue productivo».
– Escalabilidad multicloud: el mismo modelo de clasificación en GitHub puede mapearse a distintas políticas por proveedor.
También mejora auditoría: cuando un incidente involucra credenciales de pipeline, es más sencillo reconstruir por qué ese job tenía acceso, ya que la decisión depende de claims explícitas y gobernadas.
Detalles técnicos
En OIDC de GitHub, el proveedor emite un JWT con claims como `sub`, `repository`, `ref`, `workflow`, `environment` y ahora `repo_property_*` cuando se habilitan.
Puntos técnicos relevantes:
1. **Gobernanza del dato**: las propiedades deben existir previamente en organización o enterprise. El valor en cada repo determina qué claim se emite.
2. **Prefijo fijo**: los claims se exponen como `repo_property_
3. **Compatibilidad de políticas**: el proveedor cloud debe poder evaluar claims personalizados en la confianza federada.
4. **No reemplaza `sub`**: sigue siendo clave restringir `sub`, `aud` y, cuando aplica, `environment`.
5. **Permiso de workflow**: el job necesita `id-token: write` para solicitar el token.
Un detalle importante para arquitectura: la documentación de GitHub marca que AWS no soporta custom claims OIDC en este escenario, por lo que en AWS la estrategia principal sigue siendo condicionar por `sub` y `aud`. En Azure y GCP, donde ABAC con claims adicionales suele ser más flexible, esta novedad puede rendir más rápido.
Qué deberían hacer los administradores o equipos técnicos
1. **Inventariar propiedades útiles**: definir 3 a 6 propiedades estándar con semántica estable (`criticality`, `compliance_tier`, `deployment_scope`, `owner_team`).
2. **Evitar explosión de cardinalidad**: no crear taxonomías excesivas; valores acotados facilitan políticas mantenibles.
3. **Aplicar “deny by default”**: en cloud, negar por defecto y permitir sólo combinaciones de claims aprobadas.
4. **Mantener condiciones base**: incluso con claims nuevos, conservar restricciones estrictas de `sub`, rama/tag y entorno protegido.
5. **Pilotear por dominios**: empezar con un conjunto de repos de una plataforma y medir reducción de tickets IAM/errores de permisos.
6. **Automatizar compliance**: validar en CI que repos críticos tengan propiedades obligatorias y valores válidos.
7. **Registrar y revisar**: auditar regularmente tokens emitidos y políticas para detectar claims obsoletas o sobrepermisos.
Conclusión
La incorporación de propiedades de repositorio en tokens OIDC es un avance concreto para operar GitHub Actions a escala empresarial. No es una funcionalidad “cosmética”: reduce trabajo manual, mejora coherencia entre gobierno y ejecución, y habilita controles más expresivos para pipelines.
El valor real aparecerá en organizaciones que traten sus metadatos como contrato operativo, con taxonomía estable y políticas cloud revisables. Donde eso exista, este cambio puede traducirse en menos deuda de permisos y mejores tiempos de entrega sin relajar seguridad.
Fuentes
– https://github.blog/changelog/2026-03-12-actions-oidc-tokens-now-support-repository-custom-properties/
– https://docs.github.com/en/actions/concepts/security/openid-connect
– https://docs.github.com/en/actions/reference/security/oidc