Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support managed-identity authentication to Azure Artifacts during AML environment builds

Abierto
  • ¿Algo no está bien?
#49,213 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
azure, python
Área
authentication, cloud, security

Línea de trabajo

No repository files, tests, or entry points are identified. Start by locating the AML-managed environment-build service and the existing python_feed credential flow, then determine whether this repository owns the required change. Done means Azure Artifacts Python feeds can use a configured user-assigned managed identity during AML-managed Conda/pip builds, with actionable permission errors and existing credential authentication preserved.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Is your feature request related to a problem? Please describe.

We use private Python packages hosted in Azure Artifacts. Developers update dependencies locally and submit Azure Machine Learning jobs directly from their machines, relying on AML to build and cache the required environments.
The documented AML python_feed connection supports PAT or username/password authentication, but not managed identity. This requires recurring renewal of a user-owned PAT and updates to the corresponding AML feed connections.
This creates operational overhead, a dependency on an employee’s credentials, and a risk of environment-build failures when credentials expire or are revoked.

Describe the solution you'd like

Support a configured user-assigned managed identity for Azure Artifacts authentication during AML-managed Conda/pip environment builds.
After one-time identity and feed-permission configuration, the developer workflow should remain:

Edit dependencies locally → submit an AML job → AML builds/caches the environment → run.

AML should acquire and renew short-lived Microsoft Entra tokens as needed, without exposing credentials in build logs or persisting them in the resulting image. Missing permissions should produce actionable errors.
This does not assume that the submitting user’s credentials or the job’s compute identity are available during environment builds. An explicitly configured environment-build identity would be appropriate.
The initial scope could be limited to Azure Artifacts Python feeds and AML-managed builds using a Conda specification with pip dependencies. Arbitrary Dockerfile builds and other package repositories can remain separate requests. Existing credential-based connections should continue to work.

Describe alternatives you've considered

  • CI-built images: Useful for production releases, but requiring a separate image-build pipeline for every dependency change adds friction to interactive development. We want to preserve AML’s existing remote environment-build workflow.
  • Bundling wheels at submission: Requires additional tooling, dependency resolution, and platform compatibility handling, particularly when submitting from Windows to Linux compute.
  • Installing dependencies at job startup: Moves installation outside AML’s normal environment-build/cache mechanism and requires custom authentication and bootstrap logic.
  • Automating PAT rotation: Reduces manual work but retains user-owned credentials and credential-renewal/distribution infrastructure.
  • Longer-lived PATs: Reduces renewal frequency, where policy permits, but does not eliminate the credential-management problem or dependency on an employee’s account.

Additional context

Authorization is an important part of this request. Users who can submit arbitrary builds using an identity could potentially retrieve packages accessible to it. The feature should explicitly control who may configure and use the build identity, require narrowly scoped feed permissions, and document that trust boundary. It should not implicitly grant every workspace user access to a privileged identity.

Related discussions:

  • #29942 — Private-package support in SDK v2 and the added complexity of separate Docker builds.
  • #35036 — Private-feed authentication in Docker build contexts. Related, but arbitrary Dockerfile support is outside this request’s initial scope.

This request specifically concerns replacing manually maintained feed credentials with managed-identity authentication, while preserving local job submission and AML-managed environment builds.

Is this supported through an existing mechanism, or already tracked on the roadmap? If this requires changes to the AML environment-build service rather than the SDK, please route the request to the appropriate service owners.

Lenguaje dominante
Python
Estrellas
5.6k
Forks
3.4k
Merge medio
1 d 18 h
PR fusionados (30 d)
214

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Azure/azure-sdk-for-python

Todos los issues de Azure/azure-sdk-for-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.