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:
- 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. - 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.
- 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.
- 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.
- 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 proyectofabrikam-tailspin/SpaceGameWeb
, en el repositorio de Azure ReposSpaceGameWeb
. - La
SpaceGameWeb
canalización comprueba elSpaceGameWebReact
repositorio en el mismo proyecto y losFabrikamFiber
repositorios yFabrikamChat
en elfabrikam-tailspin/FabrikamFiber
proyecto. - El
FabrikamFiber
repositorio usa elFabrikamFiberLib
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. - Las estructuras
FabrikamFiber
del repositorio del proyecto se ven como en la captura de pantalla siguiente. - 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.
Conceda permiso a los repositorios o recursos de canalización.
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 , FabrikamFiberLib
agregando 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 , FabrikamFiberLib
agregando 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.