Compartir vía


Protección del acceso seguro a Azure Repos desde canalizaciones

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Los repositorios son fundamentales para el éxito empresarial, ya que hospedan el código que impulsa las operaciones. El acceso a los repositorios debe controlarse cuidadosamente. En este artículo se explica cómo mejorar la canalización de compilación y la seguridad de canalización de versión clásica al acceder a Azure Repos para mitigar el riesgo de acceso no autorizado.

Para garantizar el acceso seguro a los repositorios de Azure, habilite las siguientes alternancias:

  • Limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones que no son de versión
  • Limitar el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de versión
  • Proteger el acceso a repositorios en canalizaciones YAML

Proceso Basic

Los pasos siguientes para proteger las canalizaciones son similares en todas las canalizaciones:

  1. Identifique los repositorios de Azure Repos a los que la canalización requiere acceso dentro de la misma organización, pero en distintos proyectos.
    Para ello, inspeccione la canalización o habilite limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones de versión (no)y observe qué repositorios no puede desencarcar la canalización. Es posible que los repositorios de submódulos no aparezcan en la primera ejecución con errores.
  2. Conceda a la identidad de compilación de la canalización acceso a ese proyecto para cada proyecto que contenga un repositorio al que necesita acceder la canalización.
  3. Conceda a la identidad de compilación de la canalización acceso de lectura a ese repositorio para cada repositorio en el que se desencara la canalización.
  4. Conceda a la identidad de compilación de la canalización acceso de lectura a ese repositorio para cada repositorio que un repositorio usa como submódulo por un repositorio que la canalización descontece y se encuentra en el mismo proyecto.
  5. Habilite limitar el ámbito de autorización del trabajo al proyecto actual para canalizaciones que no son de versión, limitar el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de versión y proteger el acceso a los repositorios en las canalizaciones yaML.

Canalizaciones de compilación

Para ilustrar los pasos que se deben seguir para mejorar la seguridad de las canalizaciones cuando acceden a Azure Repos, se usa el ejemplo siguiente.

  • Supongamos que está trabajando en la canalización SpaceGameWeb hospedada en el proyecto fabrikam-tailspin/SpaceGameWeb, en el repositorio de Azure Repos SpaceGameWeb.
  • La SpaceGameWeb canalización comprueba el SpaceGameWebReact repositorio en el mismo proyecto y los FabrikamFiber repositorios y FabrikamChat en el fabrikam-tailspin/FabrikamFiber proyecto.
  • El FabrikamFiber repositorio usa el FabrikamFiberLib repositorio como submódulo hospedado en el mismo proyecto.
  • Las estructuras SpaceGameWeb del repositorio del proyecto se ven como en la captura de pantalla siguiente. Captura de pantalla de la estructura del repositorio SpaceGameWeb.
  • Las estructuras FabrikamFiber del repositorio del proyecto se ven como en la captura de pantalla siguiente. Captura de pantalla de la estructura del repositorio FabrikamFiber.
  • Imagine que el proyecto no está configurado para utilizar una identidad de compilación basada en proyectos o para proteger el acceso a los repositorios en canalizaciones de YAML. Además, supongamos que ya ejecutó correctamente la canalización.

Uso de una identidad de compilación basada en proyectos para canalizaciones de compilación

Durante la ejecución de la canalización, se usa una identidad para acceder a los recursos, como repositorios, conexiones de servicio y grupos de variables. Las canalizaciones pueden usar dos tipos de identidades: nivel de proyecto y nivel de colección. El primero da prioridad a la seguridad, mientras que este último enfatiza la facilidad de uso. Para más información, consulte El ámbito de las identidades de compilación y el ámbito de autorización de trabajos.

Para mejorar la seguridad, use identidades de nivel de proyecto al ejecutar las canalizaciones. Estas identidades solo pueden acceder a los recursos dentro de su proyecto asociado, minimizando el riesgo de acceso no autorizado por actores malintencionados.

Para configurar la canalización para que use una identidad de nivel de proyecto, habilite el ámbito limitar la autorización del trabajo al proyecto actual para la configuración de canalizaciones que no son de versión.

En nuestro ejemplo práctico, cuando se desactiva este botón de alternancia, la canalización SpaceGameWeb puede acceder a todos los repositorios de todos los proyectos. Cuando el botón de alternancia está activado, SpaceGameWeb solo puede acceder a los recursos del proyecto fabrikam-tailspin/SpaceGameWeb, por lo que solo los repositorios SpaceGameWeb y SpaceGameWebReact dejan de estar accesibles.

Si ejecuta nuestra canalización de ejemplo, al activar el botón de alternancia, se produce un error en la canalización y los registros de errores le remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting. indican y remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Para corregir los problemas de desprotección, siga los pasos descritos en la sección Proceso básico de este artículo.

Además, consulte explícitamente los repositorios de submódulos antes de los repositorios que los usen. En nuestro ejemplo, significa el repositorio FabrikamFiberLib.

Si ejecuta nuestra canalización de ejemplo, se realiza correctamente.

Configuración adicional

Para mejorar aún más la seguridad al acceder a Azure Repos, considere la posibilidad de habilitar proteger el acceso a los repositorios en las canalizaciones de YAML.

Supongamos que la canalización SpaceGameWeb es una canalización YAML y que su código fuente de YAML es similar al código siguiente.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
  - ...

Protección del acceso a repositorios en canalizaciones YAML

Azure DevOps proporciona un mecanismo de permisos específico para los repositorios de Azure Repos, gracias a la configuración Protección del acceso a repositorios en canalizaciones YAML. Esta configuración hace que una canalización YAML solicite permiso de forma explícita para acceder a todos los repositorios de Azure Repos, independientemente del proyecto al que pertenezcan. Para obtener más información, consulte Repositorios de acceso. Esta configuración no afecta a la desprotegición de otros tipos de repositorios, como los hospedados en GitHub.

En nuestro ejemplo en ejecución, cuando esta configuración está activada, la SpaceGameWeb canalización solicita permiso para acceder al SpaceGameWebReact repositorio en el fabrikam-tailspin/SpaceGameWeb proyecto y los FabrikamFiber repositorios y FabrikamChat en el fabrikam-tailspin/FabrikamFiber proyecto.

Al ejecutar la canalización de ejemplo, se compila de forma similar al ejemplo siguiente.

Captura de pantalla de la primera ejecución de la canalización SpaceGameWeb después de activar el botón de alternancia Protección del acceso a repositorios en canalizaciones YAML.

Conceda permiso a los repositorios o recursos de canalización.

Captura de pantalla de la solicitud de concesión de permiso a la canalización SpaceGameWeb para acceder a tres repositorios.

La canalización se ejecuta, pero se produce un error porque no puede desaconsultar el FabrikamFiberLib repositorio como un submódulo de FabrikamFiber. Para resolver este problema, consulte explícitamente , FabrikamFiberLibagregando un - checkout: git://FabrikamFiber/FabrikamFiberLib paso antes del -checkout: FabrikamFiber paso.

La canalización de ejemplo se realiza correctamente.

Nuestro código fuente de canalización YAML final es similar al siguiente fragmento de código.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Solución de problemas

Use las siguientes soluciones para los problemas que surjan.

Usa Git en la línea de comandos para extraer repositorios de la misma organización.

Por ejemplo, está usando - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/. El comando produce un error cuando la opción Proteger el acceso a los repositorios de canalizaciones yaML está activada.

Para resolver el problema, consulte el OtherRepo repositorio mediante el checkout comando , como - checkout: git://FabrikamFiber/OtherRepo.

Un repositorio usa otro repositorio como submódulo

Supongamos que uno de los repositorios que extrae la canalización usa otro repositorio (en el mismo proyecto) como submódulo, como pasa en nuestro ejemplo de los repositorios FabrikamFiber y FabrikamFiberLib. Puede obtener más información sobre cómo extraer submódulos del repositorio.

Supongamos también que concedió a ese repositorio acceso de lectura a la identidad de compilación SpaceGame, pero se sigue produciendo un error en la extracción del repositorio FabrikamFiber al extraer el submódulo FabrikamFiberLib.

Para resolver este problema, consulte explícitamente , FabrikamFiberLibagregando un - checkout: git://FabrikamFiber/FabrikamFiberLib paso antes del -checkout: FabrikamFiber que.

Canalizaciones de versión clásicas

El proceso para proteger el acceso a los repositorios para las canalizaciones de versión es similar al de las canalizaciones de compilación.

Para ilustrar los pasos que debe seguir, usamos un ejemplo en ejecución. En nuestro ejemplo hay una canalización de versión denominada FabrikamFiberDocRelease en el proyecto fabrikam-tailspin/FabrikamFiberDocRelease. Supongamos que la canalización extrae el repositorio FabrikamFiber en el proyecto fabrikam-tailspin/FabrikamFiber, ejecuta un comando para generar documentación pública y la publica en un sitio web. Además, imagine que el FabrikamFiber repositorio usa el FabrikamFiberLib repositorio (en el mismo proyecto) como un submódulo.

Uso de una identidad de compilación basada en un proyecto para las canalizaciones de versión clásicas

Cuando se ejecuta una canalización, usa una identidad para acceder a varios recursos, como repositorios, conexiones de servicio o grupos de variables. Hay dos tipos de identidades que puede usar una canalización: una de nivel de proyecto y una de nivel de colección. El primero proporciona una mejor seguridad. Este último proporciona facilidad de uso. Obtenga más información sobre las identidades de compilación con ámbito y el ámbito de autorización de trabajos.

Se recomienda usar identidades de nivel de proyecto para ejecutar las canalizaciones. De forma predeterminada, las identidades de nivel de proyecto solo pueden acceder a los recursos del proyecto del que son miembros. El uso de esta identidad mejora la seguridad, ya que reduce el acceso obtenido por una persona malintencionada al secuestrar la canalización.

Para que la canalización use una identidad a nivel de proyecto, active la opción Limitar el ámbito de autorización del trabajo al proyecto actual en las canalizaciones de versión.

En nuestro ejemplo, cuando se desactiva este botón de alternancia, la canalización de versión FabrikamFiberDocRelease puede acceder a todos los repositorios de todos los proyectos, así como al repositorio FabrikamFiber. Cuando el botón de alternancia está activado, FabrikamFiberDocRelease solo puede acceder a los recursos del proyecto fabrikam-tailspin/FabrikamFiberDocRelease, por lo que el repositorio FabrikamFiber deja de estar accesible.

Si ejecuta nuestra canalización de ejemplo, al activar el botón de alternancia, se produce un error en la canalización y los registros le indican remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Para corregir estos problemas, siga los pasos descritos en la sección Proceso básico de este artículo.

La canalización de ejemplo se realiza correctamente.