Migrace z podu spravované identity na identitu úloh

Článek
10/24/2023

Tento článek se zaměřuje na migraci z podem spravované identity na ID úloh Microsoft Entra pro váš cluster Azure Kubernetes Service (AKS). Obsahuje také pokyny v závislosti na verzi klientské knihovny Azure Identity používané vaší aplikací založenou na kontejnerech.

Pokud ID úloh Microsoft Entra neznáte, přečtěte si následující článek s přehledem.

Než začnete

Azure CLI verze 2.47.0 nebo novější. Spuštěním příkazu vyhledejte az --version verzi a spusťte az upgrade upgrade verze. Pokud potřebujete instalaci nebo upgrade, přečtěte si téma Instalace Azure CLI.

Scénáře migrace

Tato část vysvětluje dostupné možnosti migrace v závislosti na tom, jakou verzi sady Azure Identity SDK je nainstalovaná.

V obou scénářích je potřeba nastavit federovaný vztah důvěryhodnosti před aktualizací aplikace tak, aby používala identitu úlohy. Toto jsou minimální požadované kroky:

Vytvořte přihlašovací údaje spravované identity .
Přidružte spravovanou identitu k účtu služby Kubernetes, který už používáte pro identitu spravovanou podem, nebo vytvořte nový účet služby Kubernetes a pak ji přidružte ke spravované identitě.
Vytvořte federovaný vztah důvěryhodnosti mezi spravovanou identitou a ID Microsoft Entra.

Migrace z nejnovější verze

Pokud vaše aplikace už používá nejnovější verzi sady Azure Identity SDK, dokončete konfiguraci ověřování provedením následujících kroků:

Nasaďte identitu úlohy paralelně s podem spravovanou identitou. Nasazení aplikace můžete restartovat, abyste mohli začít používat identitu úlohy, ve které automaticky vloží poznámky OIDC do aplikace.
Po ověření, že se aplikace úspěšně ověří, můžete z aplikace odebrat poznámky k identitě spravované podem a pak odebrat doplněk spravované podem identity.

Migrace ze starší verze

Pokud vaše aplikace nepoužívá nejnovější verzi sady Azure Identity SDK, máte dvě možnosti:

Můžete použít sajdkár migrace, který poskytujeme v rámci vašich linuxových aplikací, což proxy servery IMDS transakce, které vaše aplikace provádí, přes OpenID Připojení (OIDC). Sajdkárna migrace není určená jako dlouhodobé řešení, ale způsob, jak rychle začít pracovat s identitou úloh. Proveďte tyto kroky:
- Nasaďte úlohu pomocí sajdkáře migrace pro proxy transakce IMDS aplikace.
- Ověřte úspěšné dokončení ověřovacích transakcí.
- Naplánujte práci pro aplikace, aby aktualizovaly sadu SDK na podporovanou verzi.
- Jakmile se sada SDK aktualizuje na podporovanou verzi, můžete odebrat proxy sajdkáru a znovu nasadit aplikaci.
Poznámka:

Pro použití v produkčním prostředí není podporován sajdkár migrace. Tato funkce vám poskytne čas na migraci sady SDK aplikace na podporovanou verzi, nikoli na dlouhodobé řešení. Sajdkárna migrace je k dispozici pouze pro kontejnery Linuxu kvůli poskytování pouze identit spravovaných pody s fondy uzlů Linuxu.
Přepište aplikaci tak, aby podporovala nejnovější verzi klientské knihovny Azure Identity . Potom proveďte následující kroky:
- Restartujte nasazení aplikace, abyste mohli začít ověřovat pomocí identity úlohy.
- Jakmile ověříte úspěšné dokončení ověřovacích transakcí, můžete z aplikace odebrat poznámky k identitě spravované podem a pak doplněk identity spravované podem odebrat.

Vytvoření spravované identity

Pokud nemáte vytvořenou a přiřazenou spravovanou identitu k podu, pomocí následujících kroků vytvořte a udělte potřebná oprávnění k úložišti, key Vaultu nebo prostředkům, které vaše aplikace potřebuje k ověření v Azure.

Pomocí příkazu az account set v Azure CLI nastavte konkrétní předplatné, které bude aktuálním aktivním předplatným. Pak pomocí příkazu az identity create vytvořte spravovanou identitu.

az account set --subscription "subscriptionID"

az identity create --name "userAssignedIdentityName" --resource-group "resourceGroupName" --location "location" --subscription "subscriptionID"

export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "resourceGroupName" --name "userAssignedIdentityName" --query 'clientId' -otsv)"

Udělte spravované identitě oprávnění požadovaná pro přístup k prostředkům v Azure, která vyžaduje. Informace o tom, jak to provést, najdete v tématu Přiřazení přístupu ke spravované identitě k prostředku.
Pokud chcete získat adresu URL vystavitele OIDC a uložit ji do proměnné prostředí, spusťte následující příkaz. Nahraďte výchozí hodnoty pro název clusteru a název skupiny prostředků.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
Proměnná by měla obsahovat adresu URL vystavitele podobnou následujícímu příkladu:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
Ve výchozím nastavení je vystavitel nastaven na použití základní adresy URL https://{region}.oic.prod-aks.azure.com/{uuid}, kde hodnota pro {region} shodu s umístěním clusteru AKS je nasazena. Hodnota {uuid} představuje klíč OIDC.

Vytvoření účtu služby Kubernetes

Pokud pro tuto aplikaci nemáte vytvořený vyhrazený účet služby Kubernetes, vytvořte ho následujícím postupem a pak ho anotujte pomocí ID klienta spravované identity vytvořené v předchozím kroku. Použijte příkaz az aks get-credentials a nahraďte hodnoty názvu clusteru a názvu skupiny prostředků.

az aks get-credentials --name myAKSCluster --resource-group "${RESOURCE_GROUP}"

Zkopírujte a vložte následující víceřádkový vstup do Azure CLI.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: ${USER_ASSIGNED_CLIENT_ID}
  name: ${SERVICE_ACCOUNT_NAME}
  namespace: ${SERVICE_ACCOUNT_NAMESPACE}
EOF

Následující výstup se podobá úspěšnému vytvoření identity:

Serviceaccount/workload-identity-sa created

Navázání vztahu důvěryhodnosti přihlašovacích údajů federované identity

Pomocí příkazu az identity federated-credential create vytvořte přihlašovací údaje federované identity mezi spravovanou identitou, vystavitelem účtu služby a předmětem. Nahraďte hodnoty resourceGroupName, , federatedIdentityNameuserAssignedIdentityName, serviceAccountNamespacea serviceAccountName.

az identity federated-credential create --name federatedIdentityName --identity-name userAssignedIdentityName --resource-group resourceGroupName --issuer ${AKS_OIDC_ISSUER} --subject system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME} --audience api://AzureADTokenExchange

Poznámka:

Rozšíření přihlašovacích údajů federované identity po počátečním přidání trvá několik sekund. Pokud se žádost o token provede okamžitě po přidání přihlašovacích údajů federované identity, může dojít k selhání po dobu několika minut, protože mezipaměť je naplněná starými daty v adresáři. Abyste se tomuto problému vyhnuli, můžete po přidání přihlašovacích údajů federované identity přidat mírné zpoždění.

Nasazení úlohy pomocí sajdkáře migrace

Poznámka:

Pro použití v produkčním prostředí není podporován sajdkár migrace. Tato funkce vám poskytne čas na migraci sady SDK aplikace na podporovanou verzi, nikoli na dlouhodobé řešení. Sajdkárna migrace je určená jenom pro kontejnery Linuxu, protože identity spravované pody byly k dispozici pouze ve fondech uzlů Linuxu.

Pokud vaše aplikace používá spravovanou identitu a stále spoléhá na IMDS k získání přístupového tokenu, můžete k zahájení migrace na identitu úloh použít sajdkár migrace identit úloh. Tento sajdkár je řešení migrace a v dlouhodobých aplikacích byste měli upravit kód tak, aby používal nejnovější sady SDK azure Identity, které podporují klientské kontrolní výrazy.

Pokud chcete úlohu aktualizovat nebo nasadit, přidejte tyto poznámky podů jenom v případě, že chcete použít sajdkáře migrace. K použití sajdkáře ve specifikaci podu vložíte následující hodnoty poznámek :

azure.workload.identity/inject-proxy-sidecar - hodnota je true nebo false
azure.workload.identity/proxy-sidecar-port – hodnota je požadovaný port pro proxy sajdkáře. Výchozí hodnota je 8000.

Když se vytvoří pod s výše uvedenými poznámkami, azure Workload Identity mutating webhook automaticky vloží init-container a proxy sidecar do specifikace podu.

Webhook, který je již spuštěný, přidá do nasazení podu následující fragmenty kódu YAML. Následuje příklad specifikace mutovaného podu:

apiVersion: v1
kind: Pod
metadata:
  name: httpbin-pod
  labels:
    app: httpbin
    azure.workload.identity/use: "true"
  annotations:
    azure.workload.identity/inject-proxy-sidecar: "true"
spec:
  serviceAccountName: workload-identity-sa
  initContainers:
  - name: init-networking
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy-init:v1.1.0
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
        drop:
        - ALL
      privileged: true
      runAsUser: 0
    env:
    - name: PROXY_PORT
      value: "8000"
  containers:
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
  - name: proxy
    image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v1.1.0
    ports:
    - containerPort: 8000

Tato konfigurace se vztahuje na všechny konfigurace, ve kterých se pod vytváří. Po aktualizaci nebo nasazení aplikace můžete ověřit, že pod je spuštěný, pomocí příkazu kubectl describe pod . Nahraďte hodnotu podName názvem image nasazeného podu.

kubectl describe pods podName

Pokud chcete ověřit, že pod předává transakce IMDS, použijte příkaz kubectl logs . Nahraďte hodnotu podName názvem image nasazeného podu:

kubectl logs podName

Následující výstup protokolu připomíná úspěšnou komunikaci prostřednictvím proxy sajdkáře. Ověřte, že protokoly ukazují úspěšné získání tokenu a operace GET je úspěšná.

I0926 00:29:29.968723       1 proxy.go:97] proxy "msg"="starting the proxy server" "port"=8080 "userAgent"="azure-workload-identity/proxy/v0.13.0-12-gc8527f3 (linux/amd64) c8527f3/2022-09-26-00:19"
I0926 00:29:29.972496       1 proxy.go:173] proxy "msg"="received readyz request" "method"="GET" "uri"="/readyz"
I0926 00:29:30.936769       1 proxy.go:107] proxy "msg"="received token request" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"
I0926 00:29:31.101998       1 proxy.go:129] proxy "msg"="successfully acquired token" "method"="GET" "uri"="/metadata/identity/oauth2/token?resource=https://management.core.windows.net/api-version=2018-02-01&client_id=<client_id>"

Odebrání identity spravované podem

Jakmile dokončíte testování a aplikace úspěšně získá token pomocí sajdkára proxy serveru, můžete z clusteru odebrat mapování identit spravované podem Microsoft Entra a pak tuto identitu odebrat.

Spuštěním příkazu az aks pod-identity delete odeberte identitu z podu. To by se mělo provést až po migraci všech podů v oboru názvů pomocí mapování identit spravovaných podem, aby bylo možné použít sajdkáře.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Další kroky

Tento článek vám ukázal, jak nastavit pod pro ověření pomocí identity úlohy jako možnosti migrace. Další informace o ID úloh Microsoft Entra najdete v následujícím článku s přehledem.

Share via