apache-airflow-providers-git-azure¶

Voegt AzureDevOpsGitDagBundle toe: een Git DAG bundle voor private Azure DevOps-repositories zonder statische credential — geen PAT, geen SSH-key, geen client secret. Dit is wat een dag-processor-/worker-pod daadwerkelijk gebruikt om DAGs uit git op te halen, in tegenstelling tot de andere providers op deze site, die operators/hooks toevoegen die de eigen taken van een DAG gebruiken.

De bundle is transparant: deze gedraagt zich exact als de standaard GitDagBundle voor GitHub- (of andere) URL’s, op PAT gebaseerde connecties, en SSH-key-connecties, dus het is veilig om deze als bundle-class te gebruiken voor elke git-connectie, ook klantbeheerde. De Entra ID-logica activeert alleen voor Azure DevOps HTTPS-URL’s (dev.azure.com / *.visualstudio.com):

Connectie-inhoud (Azure DevOps HTTPS-URL)	Auth-modus
Alleen host	Workload identity (`WorkloadIdentityCredential`, met terugval op `DefaultAzureCredential` voor lokale ontwikkeling)
Login + password + extra `tenant_id`	Service principal client secret (`ClientSecretCredential`)
Login + password, geen extra `tenant_id`	PAT — standaardgedrag van `GitHook`
SSH-key (extra `private_key`/`key_file`) of een `git@…`-URL	Standaardgedrag van `GitHook`

Waarom dit bestaat¶

Azure DevOps Git over HTTPS accepteert Microsoft Entra ID access tokens (audience 499b84ac-1321-427f-aa17-267ca6975798) als authenticatie, maar deze verlopen na ongeveer een uur — te kortlevend om in een Airflow-connectie op te slaan. Deze bundle genereert in plaats daarvan een vers token op het moment van clone/fetch via de workload identity van de pod, zodat de connectie alleen ooit de repository-URL hoeft te bevatten.

Beveiligingseigenschappen:

Het token wordt nooit in de remote-URL ingebed, dus het wordt nooit weggeschreven in de .git/config van de bare repository.
Het token wordt aan het git-subproces doorgegeven via de environment variables GIT_CONFIG_COUNT/GIT_CONFIG_KEY_0=http.extraHeader/GIT_CONFIG_VALUE_0 (git ≥ 2.31) — niet op de command line, niet in een bestand.
Het token wordt nooit gelogd, en de hook-environment wordt gewist zodra het git-commando is afgerond.

Vereisten¶

Alleen workload identity (sla over als je in plaats daarvan een PAT- of service principal client secret-connectie gebruikt — zie “Connectie instellen” hieronder):

Een AKS-cluster met workload identity ingeschakeld, en een managed identity met federated credentials voor de service accounts dag-processor en worker van Airflow.
De managed identity toegevoegd aan de Azure DevOps-organisatie (vereist een Basic-toegangsniveau) en met Reader + Code: Read specifiek op de target-repository (Project Settings → Repositories → <repo> → Security) — niet organisatiebreed — plus View project-level information, verleend op projectniveau: Project Settings → Permissions → Users → zoek de identity op → klap de rij uit → schakel View project-level information in.
De Airflow-pods gelabeld met azure.workload.identity/use: "true" en het service account geannoteerd met azure.workload.identity/client-id: <client-id>.

De service principal client secret-flow heeft dezelfde Azure DevOps-zijdige vereiste als stap 2 hierboven — de appregistratie zelf (geen managed identity) moet worden onboarded in de organisatie met een Basic-toegangsniveau en Reader + Code: Read krijgen op de repo, plus View project-level information op het project (Project Settings → Permissions → Users → zoek de service principal op → klap de rij uit).

Connectie instellen¶

Zie Git (Azure DevOps)-connectie voor een walkthrough met screenshots van het aanmaken van deze connectie in de Airflow UI.

Workload identity — een standaard git-connectie waarvan de host de HTTPS-repository-URL is, met login/password leeg gelaten:

airflow connections add scamander-example \
  --conn-type git \
  --conn-host "https://dev.azure.com/<org>/<project>/_git/<repo>"

Service principal client secret — dezelfde connectie, plus het client-ID van de service principal als login, het client secret ervan als password, en de tenant in extra. Het password wordt hier gebruikt als Entra client secret, niet als git-wachtwoord — zonder de extra tenant_id wordt een password in plaats daarvan als PAT behandeld:

airflow connections add scamander-example \
  --conn-type git \
  --conn-host "https://dev.azure.com/<org>/<project>/_git/<repo>" \
  --conn-login "<client-id>" \
  --conn-password "<client-secret>" \
  --conn-extra '{"tenant_id": "<tenant-id>"}'

DAG bundle-configuratie¶

Richt de bundle-config op de nieuwe class (AIRFLOW__DAG_PROCESSOR__DAG_BUNDLE_CONFIG_LIST of de bijbehorende Helm-waarde):

[
  {
    "name": "scamander-example",
    "classpath": "airflow.providers.git_azure.bundles.git_azure.AzureDevOpsGitDagBundle",
    "kwargs": {
      "tracking_ref": "main",
      "git_conn_id": "scamander-example"
    }
  }
]

AzureDevOpsGitDagBundle accepteert dezelfde kwargs als de standaard GitDagBundle: tracking_ref, subdir, git_conn_id, repo_url, submodules, prune_dotgit_folder, sparse_dirs.

De gevolgde branch per instantie overschrijven¶

Een tracking_ref-sleutel in de extra van de connectie overschrijft de tracking_ref uit de bundle-config, zodat één gedeployde bundle-config per Airflow-instantie een andere branch/tag kan volgen door alleen de connectie aan te passen:

airflow connections add scamander-example \
  --conn-type git \
  --conn-host "https://dev.azure.com/<org>/<project>/_git/<repo>" \
  --conn-extra '{"tracking_ref": "release/2.0"}'

De tracking_ref-kwarg van de bundle-config is daarom optioneel — het is alleen een fout als noch de config, noch de connectie een waarde levert.