Saltar al contenido principal
Usa la identidad de un job de GitHub Actions para obtener una sesión temporal de despliegue en Basaltic. No necesitas almacenar una clave de acceso Basaltic de larga duración en GitHub. El job solicita un JWT OIDC de GitHub y lo intercambia en el endpoint AssumeRoleWithWebIdentity de Basaltic. El token bearer resultante autoriza llamadas de despliegue a la API según las políticas del rol Basaltic.

Registrar GitHub en la cuenta de despliegue

Sigue el registro de proveedor en la misma cuenta que el rol de despliegue. Usa estos valores:
La audiencia es el identificador elegido para este intercambio. Usa exactamente el mismo valor en el proveedor, la política de confianza y el workflow. La guía de AWS usa sts.amazonaws.com como audiencia de ejemplo.

Restringir el rol a tu workflow

Crea un rol IAM llamado github-deployer en la cuenta production. Su política de confianza debe indicar tu proveedor y el sujeto exacto de GitHub. Este ejemplo usa un entorno protegido llamado production:
Sustituye el propietario, repositorio e IDs del ejemplo por el sub exacto de tu token. GitHub admite formatos de sujeto basados en nombres y en IDs inmutables. Los cambios de nombre, transferencias o personalizaciones pueden alterar el valor. Consulta la referencia de sujetos de GitHub. Un sujeto de entorno no restringe también la rama. Configura la protección de entornos de GitHub para limitar las ramas y aprobaciones de despliegue. El workflow de ejemplo usa un entorno, por lo que su confianza debe usar el sujeto de entorno. Basaltic evalúa el emisor, sujeto y audiencia verificados. Claims como repository_id, ref y job_workflow_ref no son claves de política separadas en Basaltic. Incluye las restricciones necesarias en el sujeto admitido y en la configuración del entorno de GitHub.

Conceder permisos de despliegue

Adjunta políticas de permisos para los recursos específicos que modifica el despliegue. La confianza permite autenticarse; no concede acceso de despliegue. Para ejecutar la verificación siguiente, añade esta pequeña política y después los permisos de despliegue de tu aplicación por separado:

Obtener una sesión en GitHub Actions

Añade el siguiente workflow tras sustituir los valores de cuenta, rol, audiencia y entorno. El permiso id-token: write de GitHub permite al job solicitar su token de identidad; los permisos Basaltic siguen procediendo del rol. El intercambio no usa credenciales Basaltic preexistentes. Define BASALTIC_ROLE_ID con el UUID devuelto al crear el rol; el endpoint de verificación recibe un UUID.
.github/workflows/deploy.yml
Usa BASALTIC_TOKEN en los pasos posteriores de despliegue como token bearer HTTP. Sustituye o complementa la verificación con tus comandos de despliegue, concediendo solo las acciones IAM necesarias. Esta variable la define el ejemplo; las herramientas necesitan su propia configuración documentada de token. No imprimas el token ni subas la respuesta del intercambio como artefacto. El ejemplo solicita una sesión de 15 minutos. Para jobs más largos, obtén una nueva prueba de GitHub e intercámbiala antes de que caduque la sesión Basaltic. No hay refresh token en este flujo. Consulta la guía de workflows OIDC de GitHub.

Solución de problemas

Un 401 durante el intercambio suele indicar un problema con el registro del emisor, audiencia, firma o caducidad. Un 403 apunta a la confianza del rol: compara el sujeto exacto, incluidos los IDs inmutables, rama frente a entorno y el operador de conjunto de audiencia. Un 403 después de iniciar sesión indica permisos ausentes o un límite de permisos. Consulta la visión general de federación.