Acerca del fortalecimiento de seguridad con OpenID Connect

Resumen de OpenID connect

Los flujos de trabajo de las GitHub Actions a menudo se diseñan para acceder a un proveedor de servicios en la nube (tales como AWS, Azure, GCP o HashiCorp Vault) para poder desplegar el software o utilizar los servicios de la nube. Antes de que un flujo de trabajo pueda acceder a estos recursos, este suministrará credenciales, tales como contraseña o token, al proveedor de servicios en la nube. Estas credenciales se almacenan a menudo como un secreto en GitHub y el flujo de trabajo presenta este secreto al proveedor de servicios en la nube cada que este se ejecuta.

Sin embargo, el utilizar secretos preprogramados requiere que crees credenciales en el proveedor de servicios en la nube y luego que los dupliques en GitHub como un secreto.

Con OpenID Connect (OIDC), puedes tomar un enfoque diferente si configuras tu flujo de trabajo para que solicite un token de acceso de vida corta directamente del proveedor de servicios en la nube. Tu proveedor de servicios en la nube también necesita ser compatible con OIDC en su extremo y debes configurar una relación de confianza que controle qué flujos de trabajo pueden solicitar los tokens de acceso. Los proveedores que actualmente son compatibles con OIDC incluyen a Amazon Web Services, Azure, Google Cloud Platform y AshiCorp Vault, entre otros.

Beneficios de utilizar OIDC

Al actualizar tus flujos de trabajo para que utilicen tokens de OIDC, puedes adoptar las siguientes buenas prácticas de seguridad:

• Sin secretos en la nube: no tendrá que duplicar las credenciales de nube como secretos de GitHub de larga duración. En vez de esto, puedes configurar la confianza de OIDC en tu proveedor de servicios en la nube y luego actualizar tus flujos de trabajo para que soliciten un token de acceso de vida corta desde dicho proveedor mediante OIDC.
• Administración de la autenticación y la autorización: tiene un control más preciso sobre cómo los flujos de trabajo pueden usar las credenciales, mediante las herramientas de autenticación (authN) y autorización (authZ) del proveedor de servicios en la nube para controlar el acceso a los recursos de nube.
• Rotación de credenciales: con OIDC, el proveedor de servicios en la nube emite un token de acceso de duración breve que solo es válido para un trabajo y después expira de forma automática.

Iniciar con OIDC

El siguiente diagrama otorga un resumen de cómo se integra el proveedor de OIDC de GitHub con tus flujos de trabajo y proveedor de servicios en la red:

1. En tu proveedor de servicios en la red, crea una relación de confianza con OIDC entre tu rol en la nube y tus flujos de trabajo de GitHub que necesiten acceso a la nube.
2. Cada vez que se ejecuta tu job, el proveedor de ODIC de GitHub genera un token de OIDC automáticamente. Este token contiene notificaciones múltiples para establecer una identidad verificable y fortalecida en seguridad sobre el flujo de trabajo específico que está tratando de autenticar.
3. Podrías incluir un paso o acción en tu job para solicitar este token del proveedor de OIDC de GitHub y presentarlo al proveedor de servicios en la nube.
4. Una vez que el proveedor de identidad valide con éxito las notificaciones que se presentan en el token, este proporciona un token de acceso a la nube de vida corta que está disponible únicamente por la duración del job.

Configurar la relación de confianza de OIDC con la nube

Al configurar la nube para que confíe en el proveedor de OIDC de GitHub, tendrá que agregar condiciones que filtren las solicitudes entrantes para que los flujos de trabajo o repositorios que no sean de confianza no puedan solicitar tokens de acceso para los recursos de nube:

• Antes de conceder un token de acceso, el proveedor de nube comprueba que subject y otras notificaciones usadas para establecer condiciones en su configuración de confianza coinciden con las del token web JSON (JWT) de la solicitud. Como resultado, debe prestar atención y definir correctamente el asunto y otras condiciones en el proveedor de nube.
• Los pasos de configuración de confianza de OIDC y la sintaxis para definir condiciones para los roles en la nube (mediante el Asunto y otras notificaciones) variarán en función del proveedor de nube que se use. Para obtener algunos ejemplos, vea "Notificaciones de asunto de ejemplo".

Entender el token de OIDC

Cada job solicita un token de OIDC del proveedor de ODIC de GitHub, el cual responde con un Token Web JSON (JWT) generado automáticamente, el cual es único para cada job de flujo de trabajo en donde se genera. Cuando se ejecuta el job, el token de OIDC se presenta al proveedor de servicios en la nube. Para validar el token, el proveedor de servicios en la nube verifica si el asunto del token de OIDC y otros reclamos empatan con las condiciones que se preconfiguraron en la definición de confianza de OIDC del rol en la nube.

El siguiente token de OIDC de ejemplo usa un asunto (sub) que hace referencia a un entorno de trabajo denominado prod en el repositorio octo-org/octo-repo.

{
  "typ": "JWT",
  "alg": "RS256",
  "x5t": "example-thumbprint",
  "kid": "example-key-id"
}
{
  "jti": "example-id",
  "sub": "repo:octo-org/octo-repo:environment:prod",
  "environment": "prod",
  "aud": "https://HOSTNAME/octo-org",
  "ref": "refs/heads/main",
  "sha": "example-sha",
  "repository": "octo-org/octo-repo",
  "repository_owner": "octo-org",
  "actor_id": "12",
  "repository_visibility": "private",
  "repository_id": "74",
  "repository_owner_id": "65",
  "run_id": "example-run-id",
  "run_number": "10",
  "run_attempt": "2",
  "actor": "octocat",
  "workflow": "example-workflow",
  "head_ref": "",
  "base_ref": "",
  "event_name": "workflow_dispatch",
  "ref_type": "branch",
  "job_workflow_ref": "octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main",
  "iss": "https://HOSTNAME/_services/token",
  "nbf": 1632492967,
  "exp": 1632493867,
  "iat": 1632493567
}

Para ver todas las reclamaciones admitidas por el proveedor de OIDC de GitHub, revisa las entradas claims_supported en https://HOSTNAME/_services/token/.well-known/openid-configuration.

El token incluye las notificaciones de la audiencia estándar, emisor y asunto.

El token de OIDC también incluye notificaciones estándar adicionales.

El token también incluye notificaciones personalizadas que proporciona GitHub.

Definir las condiciones de confianza en los roles de la nube utilizando notificaciones de OIDC

Con OIDC, un flujo de trabajo de GitHub Actions requiere un token para poder acceder a los recursos en tu proveedor de servicios en la nube. El flujo de trabajo solicita un token de acceso desde tu proveedor de servicios en la nube, el cual verifica los detalles que presenta el JWT. Si la configuración de confianza en el JWT es una coincidencia, tu proveedor de servicios en la nube responde emitiendo un token temporal al flujo de trabajo, el cual puede utilizarse después para acceder a los recursos de tu proveedor de servicios en la nube. Puedes configurar tu proveedor de servicios en la nube para que solo responda a las solicitudes que se originan desde un repositorio de organización específico; también puedes especificar condiciones adicionales como se describe a continuación.

Las notificaciones de asunto y audiencia habitualmente se utilizan combinadas mientras se configuran las condiciones en el rol/recursos de la nube para dar el alcance a su acceso a los flujos de trabajo de GitHub.

• Público: de manera predeterminada, este valor utiliza la URL del propietario de la organización o el repositorio. Esta puede utilizarse para configurar una condición en la que solo los flujos de trabajo de una organización específica puedan acceder al rol en la nube.
• Asunto: de forma predeterminada, tiene un formato predefinido y es una concatenación de algunos de los metadatos clave del flujo de trabajo, como la organización de GitHub, el repositorio, la rama o el entorno job asociado. Vea "Notificaciones de asunto de ejemplo" para ver cómo se crea la notificación del asunto a partir de metadatos concatenados.

Si necesitas condiciones de confianza más pormenorizadas, puedes personalizar las notificaciones de emisor (iss) y asunto (sub) que se incluyen con el JWT. Para más información, consulta "Personalización de las notificaciones de token".

También hay muchas notificaciones adicionales compatibles en el token de OIDC que pueden utilizarse para configurar estas condiciones. Adicionalmente, tu proveedor de servicios en la nube podría permitirte asignar un rol a los tokens de acceso, lo cual te permite especificar permisos aún más granulares.

Ejemplos de notificación de asunto

Los siguientes ejemplos demuestran cómo utilizar el "Asunto" como una condición y explican como este se ensambla desde los metadatos concatenados. El asunto usa información del contexto job e indica al proveedor de nube que las solicitudes de token de acceso solo se pueden conceder para solicitudes de flujos de trabajo que se ejecutan en ramas y entornos específicos. Las siguientes secciones describen algunos temas comunes que puedes utilizar.

Filtrar por un ambiente específico

La notificación de asunto incluye el nombre de ambiente cuando el job hace referencia a uno de ellos.

Puede configurar un asunto que filtre por un nombre de entorno específico. En este ejemplo, la ejecución del flujo de trabajo debe haberse originado en un trabajo con un entorno denominado Production, en un repositorio denominado octo-repo que sea propiedad de la organización octo-org:

• Sintaxis: repo:<orgName/repoName>:environment:<environmentName>
• Ejemplo:repo:octo-org/octo-repo:environment:Production

Filtrado de eventos pull_request

La solicitud de asunto incluye la cadena pull_request cuando el flujo de trabajo se desencadena mediante un evento de solicitud de incorporación de cambios, pero solo si el trabajo no hace referencia a un entorno.

Puede configurar un asunto que filtre por el evento pull_request. En este ejemplo, la ejecución del flujo de trabajo debe haberse desencadenado mediante un evento pull_request en un repositorio denominado octo-repo que pertenece a la organización octo-org:

• Sintaxis: repo:<orgName/repoName>:pull_request
• Ejemplo: repo:octo-org/octo-repo:pull_request

Filtrar por una rama específica

La reivindicación del asunto incluye el nombre de rama del flujo de trabajo, pero solo si el job no hace referencia a un ambiente y el flujo de trabajo no se activa con un evento de solicitud de cambios.

Puedes configurar un asunto que filtre por un nombre de rama específica. En este ejemplo, la ejecución del flujo de trabajo debe haberse desencadenado desde una rama denominada demo-branch, en un repositorio denominado octo-repo que pertenece a la organización octo-org:

• Sintaxis: repo:<orgName/repoName>:ref:refs/heads/branchName
• Ejemplo: repo:octo-org/octo-repo:ref:refs/heads/demo-branch`

Filtrar por una etiqueta específica

La reivindicación del asunto incluye el nombre de etiqueta del flujo de trabajo, pero únicamente si el job no hace referencia a un ambiente y el flujo de trabajo no se activa con un evento de solicitud de cambios.

Puedes crear un asunte que filtre por una etiqueta específica. En este ejemplo, la ejecución del flujo de trabajo debe haberse desencadenado con una etiqueta denominada demo-tag, en un repositorio denominado octo-repo que pertenece a la organización octo-org:

• Sintaxis: repo:<orgName/repoName>:ref:refs/tags/<tagName>
• Ejemplo: repo:octo-org/octo-repo:ref:refs/tags/demo-tag

Configurar el asunto en tu proveedor de servicios en la red

Para configurar el asunto en la relación de confianza de tu proveedor de servicios en la nube, debes agregar la secuencia del asunto a su configuración de confianza. En los ejemplos siguientes se muestra cómo varios proveedores de nube pueden aceptar el mismo asunto repo:octo-org/octo-repo:ref:refs/heads/demo-branch de maneras diferentes:

Para más información, vea las guías enumeradas en "Habilitación de OpenID Connect para el proveedor de nube".

Actualizar tus acciones para OIDC

A fin de actualizar las acciones personalizadas para que se autentiquen mediante OIDC, puede usar getIDToken() del kit de herramientas de acciones para solicitar un JWT del proveedor de OIDC de GitHub. Para más información, vea "Token de OIDC" en la documentación del paquete npm.

También puede usar un comando curl para solicitar el JWT, mediante las variables de entorno siguientes.

Por ejemplo:

curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"

Agregar ajustes de permisos

La ejecución del trabajo o del flujo de trabajo necesita una configuración permissions con id-token: write. No podrá solicitar el token de identificador JWT de OIDC si el valor permissions de id-token está establecido en read o none.

El valor id-token: write permite solicitar JWT desde el proveedor OIDC de GitHub mediante uno de estos enfoques:

• Con variables de entorno en el ejecutor (ACTIONS_ID_TOKEN_REQUEST_URL y ACTIONS_ID_TOKEN_REQUEST_TOKEN).
• Con getIDToken() del kit de herramientas de Acciones.

Si necesita capturar un token de OIDC para un flujo de trabajo, el permiso se puede establecer en el nivel de flujo de trabajo. Por ejemplo:

permissions:
  id-token: write # This is required for requesting the JWT
  contents: read  # This is required for actions/checkout

Si solo necesitas recuperar un token de OIDC para un solo job, entonces este permiso puede configurarse dentro de dicho job. Por ejemplo:

permissions:
  id-token: write # This is required for requesting the JWT

Puede que necesites especificar permisos adicionales aquí, dependiendo de los requisitos de tu flujo de trabajo.

Para los flujos de trabajo reutilizables, la configuración de permissions para id-token debe fijarse en write en el nivel del flujo de trabajo que llama o en el trabajo específico que llama al flujo de trabajo reutilizable. Para obtener más información, vea «Reutilización de flujos de trabajo».

Actualizar tus flujos de trabajo para OIDC

Ahora puedes actualizar tus flujos de trabajo de YAML para que utilicen tokens de acceso OIDC en vez de secretos. Los proveedores populares de servicios en la nube publicaron sus acciones de inicio de sesión oficiales que te facilitan iniciar con OIDC. Para más información sobre cómo actualizar los flujos de trabajo, vea las guías específicas de la nube que se enumeran a continuación en "Habilitación de OpenID Connect para el proveedor de nube".

Habilitar OpenID Connect para tu proveedor de servicios en la nube

Para habilitar y configurar OIDC para tu proveedor específico de servicios en la nube, consulta las siguientes guías:

• "Configurar OpenID Connect en Amazon Web Services"
• "Configura OpenID Connect en Azure"
• "Configurar OpenID Connect en Google Cloud Platform"
• "Configurar OpenID Connect en HashiCorp Vault"

Para habilitar y configurar OIDC para otro proveedor de servicios en la nube, consulta la siguiente guía:

• "Configurar OpenID Connect en los proveedores de servicios en la nube"