Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Wanneer u tijdens het aanpassingsproces toegang hebt tot resources zoals opslagplaatsen of Azure-resources, moet u zich veilig verifiëren. U kunt verwijzen naar geheimen in Azure Key Vault in uw aanpassingsbestanden om blootstelling van gevoelige informatie te vermijden en u kunt serviceprincipals gebruiken om te authenticeren bij Azure voor beveiligde toegang tot resources. In dit artikel wordt uitgelegd hoe u resources veilig kunt beheren en openen tijdens het aanpassen van dev boxs.
Key Vault-geheimen gebruiken in aanpassingsbestanden
Gebruik geheimen uit Azure Key Vault in uw YAML-aanpassingen om privéopslagplaatsen te klonen of taken uit te voeren waarvoor een toegangstoken is vereist. Gebruik bijvoorbeeld in een aanpassingsbestand een persoonlijk toegangstoken (PAT) dat is opgeslagen in Azure Key Vault om toegang te krijgen tot een privéopslagplaats.
Zowel team- als gebruikersaanpassingen ondersteunen het ophalen van geheimen uit een sleutelkluis. Teamaanpassingen, die gebruikmaken van definitiebestanden van basisafbeeldingen, definiëren de basisafbeelding voor het ontwikkelaarsvak met de image parameter en vermelden de taken die worden uitgevoerd wanneer een ontwikkelaarsvak wordt gemaakt. Gebruikersconfiguraties geven de taken weer die worden uitgevoerd wanneer een ontwikkelbox wordt gemaakt.
Als u een geheim, zoals een PAT, wilt gebruiken in uw aanpassingsbestanden, slaat u het op als een sleutelkluisgeheim. In de volgende voorbeelden ziet u hoe u in beide typen aanpassingen naar een sleutelkluisgeheim verwijst.
Toegang tot key vault configureren voor aanpassingen
Als u sleutelkluisgeheimen wilt configureren voor gebruik in uw team of gebruikersaanpassingen, moet u ervoor zorgen dat de beheerde identiteit van het Dev Center-project de rol Key Vault Secrets User heeft in uw sleutelkluis.
Als uw sleutelkluis privé is, laat vertrouwde Microsoft-services de firewall omzeilen, omdat Dev Center nog geen servicetags ondersteunt.
In de volgende schermopname ziet u de optie om vertrouwde Microsoft-services toe te staan de firewall te omzeilen in azure Key Vault-instellingen.
Zie Azure Key Vault-netwerkinstellingen configureren voor meer informatie over het toestaan van vertrouwde Microsoft-services om de firewall te omzeilen.
Aanvullende configuratie voor gebruikersaanpassingen
Als u sleutelkluisgeheimen wilt configureren voor gebruikersaanpassingen, moet u ook het volgende doen:
- Zorg ervoor dat de beheerde identiteit van het Dev Center-project zowel de Key Vault Reader als de Key Vault Secrets Gebruiker-rol in uw eigen sleutelkluis heeft.
- Verwijs de key vault-geheimengebruikersrol voor het geheim aan elke gebruiker of groep die dit nodig heeft tijdens het aanpassen van het ontwikkelvak, waaronder de beheerde identiteit, beheerdersaccounts van het Dev Center en andere vereiste gebruikers of groepen.
Voorbeeld van teamaanpassingen
Deze syntaxis maakt gebruik van een sleutelkluisgeheim (PAT) in een afbeeldingsdefinitiebestand. Dit KEY_VAULT_SECRET_URI is de URI van het geheim in uw sleutelkluis.
$schema: "<SCHEMA_VERSION>"
name: "<IMAGE_DEFINITION_NAME>"
image: "<BASE_IMAGE>"
description: "<DESCRIPTION>"
tasks:
- name: <TASK_NAME>
description: <TASK_DESCRIPTION>
parameters:
repositoryUrl: <REPOSITORY_URL>
directory: <DIRECTORY_PATH>
pat: "{{<KEY_VAULT_SECRET_URI>}}"
In dit voorbeeld wordt de git-clone taak gebruikt:
$schema: "1.0"
name: "example-image-definition"
image: microsoftvisualstudio_visualstudioplustools_vs-2022-ent-general-win11-m365-gen2
description: "Clones a public example Git repository"
tasks:
- name: git-clone
description: Clone this repository into C:\workspaces
parameters:
repositoryUrl: https://github.com/example-org/example-repo.git
directory: C:\workspaces
pat: "{{https://contoso-vault.vault.azure.net/secrets/github-pat}}"
U kunt ook verwijzen naar het geheim in overeenstemming met een ingebouwde taak, zoals wordt weergegeven in het volgende voorbeeld:
$schema: "1.0"
name: "example-image-definition"
image: microsoftvisualstudio_visualstudioplustools_vs-2022-ent-general-win11-m365-gen2
description: "Clones a public example Git repository"
tasks:
- name: git-clone
description: Clone this repository into C:\Workspaces
parameters:
command: MyCommand –MyParam "{{KEY_VAULT_SECRET_URI}}"
Voorbeeld van gebruikersaanpassingen
Met aanpassingen van gebruikers kunt u een Azure DevOps-token verkrijgen om privéopslagplaatsen te klonen zonder expliciet een PAT op te geven uit de sleutelkluis. De service wisselt uw Azure-token automatisch uit voor een Azure DevOps-token tijdens runtime.
In dit voorbeeld ziet u de afkorting van ADO ({{ado://...}}). De service wisselt uw Azure-token uit voor een Azure DevOps-token tijdens runtime, dus u hoeft geen PAT op te slaan in Key Vault.
$schema: "1.0"
tasks:
- name: git-clone
description: Clone this repository into C:\workspaces
parameters:
repositoryUrl: https://dev.azure.com/example-org/MyProject/_git/example-repo
directory: C:\workspaces
pat: '{{ado://example-org}}'
De Dev Box Visual Studio Code-extensie en Dev Box CLI ondersteunen het injecteren van secrets niet in de testwerkstroom van de inner loop voor aangepaste workflows.
Verifiëren bij Azure-resources met service-principals
Met service principals kunt u zich veilig verifiëren bij Azure-resources zonder gebruikersreferenties te onthullen. Maak een service-principal, wijs de vereiste rollen toe en gebruik deze om te verifiëren in een aanpassingstaak. Hydrateer het wachtwoord van Key Vault op het moment van aanpassing met behulp van de bestaande geheimenfunctie.
Maak een service-principal in Azure Active Directory (Azure AD) en wijs deze toe aan de benodigde rollen voor de resources die u wilt gebruiken.
De uitvoer is een JSON-object met de appId van de service-principal, displayName, wachtwoord en tenant, die worden gebruikt voor verificatie en autorisatie in Azure Automation-scenario's.
Voorbeeld: CLI-uitvoer wanneer u een service-principal maakt. Sla het geretourneerde wachtwoord op in Key Vault en verleen de rol van Key Vault Secrets User aan de projectidentiteit van het Dev Center, zodat de aanpassing het geheim kan aanmelden tijdens runtime.
$ az ad sp create-for-rbac -n DevBoxCustomizationsTest { "appId": "...", "displayName": "DevBoxCustomizationsTest", "password": "...", "tenant": "..." }Sla het wachtwoord op dat hierboven is geretourneerd in een Key Vault-geheim, zoals hieronder:
https://mykeyvault.vault.azure.net/secrets/passwordKen in de Sleutelkluis de rol Key Vault Secrets User toe aan de projectidentiteit.
U kunt nu authenticeren bij aanpassingstaken, waarbij u het wachtwoord van de service-principal vanuit de Key Vault tijdens de aanpassing kunt hydrateren.
Voorbeeld: Een bestand downloaden uit Azure Storage
In het volgende voorbeeld ziet u hoe u een bestand downloadt uit een opslagaccount. Het YAML-fragment definieert een Dev Box-aanpassing waarmee twee hoofdtaken worden uitgevoerd:
Installeert de Azure CLI met behulp van winget-pakketbeheer.
Voert een PowerShell-script uit dat:
- Meldt u aan bij Azure met behulp van een service-principal, met het wachtwoord dat veilig is opgehaald uit Azure Key Vault.
- Hiermee downloadt u een blob (bestand) uit een Azure Storage-account met behulp van de geverifieerde sessie.
Voorbeeld: aanpassing die een wachtwoord van een service-principal uit Key Vault hydrateert en gebruikt om een blob te verifiëren en te downloaden vanuit Azure Storage. Sla het wachtwoord van de service-principal op in Key Vault en zorg ervoor dat de projectidentiteit de rol Key Vault Secrets User heeft.
$schema: "1.0" name: "devbox-customization" tasks: - name: ~/winget parameters: package: Microsoft.AzureCLI - name: ~/powershell parameters: command: | az login --service-principal ` --username <appId> ` --password {{https://mykeyvault.vault.azure.net/secrets/password}} ` --tenant <tenantId> az storage blob download ` --account-name <storage_account_name> ` --container-name <container_name> ` --name <blob_name> ` --file <local_file_path> ` --auth-mode login
Met deze installatie kunt u het veilige gebruik van Azure-resources automatiseren tijdens het inrichten van Dev Box zonder referenties beschikbaar te maken in het script.
Voorbeeld: Een artefact downloaden van Azure DevOps
Download build-artefacten van Azure DevOps (ADO) met behulp van een service-principal voor verificatie. Voeg de toepassings-id (appId) van de service-principal toe als gebruiker in uw Azure DevOps-organisatie en wijs vervolgens de principal toe aan de groep Lezers . Deze stap geeft de benodigde machtigingen voor het gebruik van buildartefacten.
Nadat u deze stappen hebt geconfigureerd, gebruikt u de referenties van de service principal in aanpassingstaken om artefacten veilig te authenticeren en te downloaden van Azure DevOps.
Een service-principal toevoegen aan een Azure DevOps-organisatie
Een service-principal toevoegen aan uw Azure DevOps-organisatie:
Meld u aan bij uw Azure DevOps-organisatie en open organisatie-instellingen.
Selecteer Gebruikers in het menu.
Op de Gebruikers pagina, selecteer Gebruikers toevoegen.
Voer in het dialoogvenster Nieuwe gebruikers toevoegen de volgende gegevens in:
- Gebruikers: Voer de toepassings-id (appId) van de service-principal in als het e-mailadres van de gebruiker.
- Toegangsniveau: Selecteer Basic.
- Toevoegen aan project: selecteer het project waaraan u de service-principal wilt toevoegen.
- Azure DevOps-groepen: wijs de service-principal toe aan de groep Lezers .
Voltooi het proces om de benodigde machtigingen te verlenen.
Zie Organisatiegebruikers toevoegen en toegang beheren voor meer informatie over het toevoegen van gebruikers aan DevOps-organisaties.
Verwante inhoud
- Meer informatie over het instellen en ophalen van een geheim uit Azure Key Vault met behulp van Azure Portal.
- Meer informatie over het toevoegen en configureren van een catalogus vanuit GitHub of Azure-opslagplaatsen.
- Meer informatie over het gebruik van service-principals en beheerde identiteiten in Azure DevOps.