Protección del acceso seguro a Azure Repos desde canalizaciones
Los repositorios son un recurso fundamental para el éxito de su empresa, ya que contienen el código que la impulsa. El acceso a los repositorios no debe concederse fácilmente.
En este artículo se muestra cómo mejorar la seguridad de las canalizaciones que acceden a Azure Repos para limitar el riesgo de que el código fuente caiga en manos equivocadas.
La configuración para que las canalizaciones accedan de forma segura a los repositorios de Azure es aquella en la que están activados los botones de alternancia Limitar el ámbito de autorización del trabajo al proyecto actual en las canalizaciones sin versión, Limitar el ámbito de autorización del trabajo al proyecto actual en las canalizaciones de versión y Proteger el acceso a repositorios en canalizaciones YAML.
Trataremos las canalizaciones de compilación y de versión clásicas:
Proceso Basic
Los pasos son similares en todas las canalizaciones:
Determine la lista de repositorios de Azure Repos a los que necesita acceder la canalización y que forman parte de la misma organización, pero que están en proyectos diferentes.
Puede compilar la lista de repositorios inspeccionando la canalización. También puede activar el botón de alternancia Limitar el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de (no) versión y anotar los repositorios que no puede extraer la canalización. Es posible que los repositorios de submódulos no aparezcan en la primera ejecución errónea.
Para cada proyecto de Azure DevOps que contenga un repositorio al que necesita acceder la canalización, siga los pasos para conceder acceso a la identidad de compilación de la canalización a ese proyecto.
Para cada repositorio de Azure Repos que extraiga la canalización, siga los pasos para conceder a ese repositorio acceso de lectura a la identidad de compilación de la canalización.
Para cada repositorio que se use como submódulo por parte de un repositorio que extraiga la canalización y que esté en el mismo proyecto, siga los pasos para conceder a ese repositorio acceso de lectura a la identidad de compilación de la canalización.
Active los botones de alternancia Limitar el ámbito de autorización del trabajo al proyecto actual en las canalizaciones sin versión, Limitar el ámbito de autorización del trabajo al proyecto actual en las canalizaciones de versión y Proteger el acceso a repositorios en 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, usaremos un ejemplo práctico.
Supongamos que está trabajando en la canalización SpaceGameWeb hospedada en el proyecto fabrikam-tailspin/SpaceGameWeb, en el repositorio de Azure Repos SpaceGameWeb. Supongamos también que la canalización SpaceGameWeb extrae el repositorio SpaceGameWebReact en el mismo proyecto y los repositorios FabrikamFiber y FabrikamChat en el proyecto fabrikam-tailspin/FabrikamFiber.
Por último, imaginémonos que el repositorio FabrikamFiber usa el repositorio FabrikamFiberLib como submódulo, hospedado en el mismo proyecto. Puede obtener más información sobre cómo extraer submódulos del repositorio.
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 haya ejecutado correctamente la canalización.
Uso de una identidad de compilación basada en un proyecto para las canalizaciones de compilación
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. La primera proporciona una mejor seguridad, mientras que la última 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 sin 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 producirá un error en la canalización y los registros de error le indicarán 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. 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 extracción del repositorio, siga los pasos descritos en Proceso básico.
Además, debe extraer explícitamente los repositorios de los submódulos antes de los repositorios que los usen. En nuestro ejemplo, significa el repositorio FabrikamFiberLib.
Si ahora ejecuta nuestra canalización de ejemplo, se realizará correctamente.
Configuración adicional
Para mejorar aún más la seguridad al acceder a Azure Repos, considere la posibilidad de activar la configuración Protección del acceso a repositorios en canalizaciones 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. Obtenga más información sobre esta configuración. La extracción de otros tipos de repositorios (por ejemplo, los que se hospedan en GitHub) no se ve afectada por esta configuración.
En nuestro ejemplo práctico, cuando este botón de alternancia está activado, la canalización SpaceGameWeb pedirá permiso para acceder al repositorio SpaceGameWebReact del proyecto fabrikam-tailspin/SpaceGameWeb y a los repositorios FabrikamFiber y FabrikamChat del proyecto fabrikam-tailspin/FabrikamFiber.
Al ejecutar la canalización de ejemplo, verá una compilación similar a la captura de pantalla siguiente.
Se le pedirá que conceda permiso a los repositorios que extraiga la canalización o que haya definido como recursos.
Cuando lo haya hecho, la canalización se ejecutará, pero se producirá un error porque no podrá extraer el repositorio FabrikamFiberLib como submódulo de FabrikamFiber. Para resolver este problema, extraiga explícitamente FabrikamFiberLib; por ejemplo, agregue un paso - checkout: git://FabrikamFiber/FabrikamFiberLib antes del paso -checkout: FabrikamFiber.
Si ahora ejecuta la canalización de ejemplo, se realizará 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
A continuación se muestran un par de situaciones problemáticas y cómo controlarlas.
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 producirá un error cuando el botón de alternancia Protección del acceso a repositorios en canalizaciones YAML esté activado.
Para resolver el problema, extraiga el repositorio OtherRepo mediante el comando checkout; por ejemplo, - 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, extraiga explícitamente FabrikamFiberLib; por ejemplo, agregue un paso - checkout: git://FabrikamFiber/FabrikamFiberLib antes del paso -checkout: FabrikamFiber.
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, usaremos un ejemplo práctico. 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. Supongamos también que el repositorio FabrikamFiber usa el repositorio FabrikamFiberLib (en el mismo proyecto) como 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. La primera proporciona una mejor seguridad, mientras que la última 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 producirá un error en la canalización y los registros le indicarán 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 Proceso básico.
Si ahora ejecuta nuestra canalización de ejemplo, se realizará correctamente.
Vea también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de