Migrowanie z tożsamości zarządzanej zasobnika do tożsamości obciążenia

Artykuł
08/02/2024

Ten artykuł koncentruje się na migracji z tożsamości zarządzanej przez zasobnik do Tożsamość obciążeń Microsoft Entra dla klastra usługi Azure Kubernetes Service (AKS). Zawiera również wskazówki w zależności od wersji biblioteki klienta tożsamości platformy Azure używanej przez aplikację opartą na kontenerze.

Jeśli nie znasz Tożsamość obciążeń Microsoft Entra, zapoznaj się z następującym artykułem Omówienie.

Zanim rozpoczniesz

Interfejs wiersza polecenia platformy Azure w wersji 2.47.0 lub nowszej. Uruchom polecenie az --version , aby znaleźć wersję i uruchomić polecenie az upgrade , aby uaktualnić wersję. Jeśli konieczna będzie instalacja lub uaktualnienie, zobacz Instalowanie interfejsu wiersza polecenia platformy Azure.

Scenariusze migracji

W tej sekcji opisano dostępne opcje migracji w zależności od wersji zainstalowanego zestawu Azure Identity SDK.

W przypadku dowolnego scenariusza należy skonfigurować zaufanie federacyjne przed zaktualizowaniem aplikacji, aby korzystała z tożsamości obciążenia. Poniżej przedstawiono minimalne wymagane kroki:

Utwórz poświadczenia tożsamości zarządzanej.
Skojarz tożsamość zarządzaną z kontem usługi kubernetes używanym już na potrzeby tożsamości zarządzanej zasobnika lub utwórz nowe konto usługi Kubernetes, a następnie skojarz je z tożsamością zarządzaną.
Ustanów relację zaufania federacyjnego między tożsamością zarządzaną a identyfikatorem Entra firmy Microsoft.

Migrowanie z najnowszej wersji

Jeśli aplikacja korzysta już z najnowszej wersji zestawu Azure Identity SDK, wykonaj następujące kroki, aby ukończyć konfigurację uwierzytelniania:

Wdrażanie tożsamości obciążenia równolegle z tożsamością zarządzaną zasobnika. Możesz ponownie uruchomić wdrożenie aplikacji, aby rozpocząć korzystanie z tożsamości obciążenia, gdzie automatycznie wprowadza adnotacje OIDC do aplikacji.
Po pomyślnym uwierzytelnieniu aplikacji można usunąć adnotacje tożsamości zarządzanej przez zasobnik z aplikacji, a następnie usunąć dodatek tożsamości zarządzanej zasobnika.

Migrowanie ze starszej wersji

Jeśli aplikacja nie korzysta z najnowszej wersji zestawu Azure Identity SDK, masz dwie opcje:

Możesz użyć przyczepki migracji, którą udostępniamy w aplikacjach systemu Linux, które proxy transakcji IMDS, które aplikacja wykonuje do openID Connect (OIDC). Przyczepka migracji nie ma być rozwiązaniem długoterminowym, ale sposobem szybkiego uruchomienia tożsamości obciążenia. Wykonaj następujące kroki:
- Wdróż obciążenie przy użyciu przyczepki migracji do serwera proxy transakcji IMDS aplikacji.
- Sprawdź, czy transakcje uwierzytelniania zakończyły się pomyślnie.
- Zaplanuj pracę aplikacji w celu zaktualizowania zestawu SDK do obsługiwanej wersji.
- Po zaktualizowaniu zestawu SDK do obsługiwanej wersji można usunąć przyczepkę serwera proxy i ponownie wdrożyć aplikację.
Uwaga

Przyczepka migracji nie jest obsługiwana do użytku produkcyjnego. Ta funkcja ma na celu zapewnienie czasu na przeprowadzenie migracji zestawu SDK aplikacji do obsługiwanej wersji, a nie oznacza to rozwiązania długoterminowego lub zamierzonego. Przyczepka migracji jest dostępna tylko dla kontenerów systemu Linux, ponieważ udostępnia tylko tożsamości zarządzane przez zasobniki z pulami węzłów systemu Linux.
Zapisz ponownie aplikację, aby obsługiwać najnowszą wersję biblioteki klienta tożsamości platformy Azure. Następnie wykonaj następujące kroki:
- Uruchom ponownie wdrożenie aplikacji, aby rozpocząć uwierzytelnianie przy użyciu tożsamości obciążenia.
- Po pomyślnym zakończeniu transakcji uwierzytelniania można usunąć adnotacje tożsamości zarządzanej przez zasobnik z aplikacji, a następnie usunąć dodatek tożsamości zarządzanej zasobnika.

Tworzenie tożsamości zarządzanej

Jeśli nie masz tożsamości zarządzanej utworzonej i przypisanej do zasobnika, wykonaj następujące kroki, aby utworzyć i udzielić niezbędnych uprawnień do magazynu, usługi Key Vault lub zasobów, które aplikacja musi uwierzytelnić na platformie Azure.

Użyj polecenia az account set interfejsu wiersza polecenia platformy Azure, aby ustawić określoną subskrypcję jako bieżącą aktywną subskrypcję. Następnie użyj polecenia az identity create , aby utworzyć tożsamość zarządzaną.

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)"

Udziel tożsamości zarządzanej uprawnienia wymagane do uzyskania dostępu do zasobów na platformie Azure, których wymaga. Aby uzyskać informacje na temat tego, jak to zrobić, zobacz Przypisywanie dostępu tożsamości zarządzanej do zasobu.
Aby uzyskać adres URL wystawcy OIDC i zapisać go w zmiennej środowiskowej, uruchom następujące polecenie. Zastąp wartości domyślne nazwy klastra i nazwy grupy zasobów.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
Zmienna powinna zawierać adres URL wystawcy podobny do następującego przykładu:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
Domyślnie wystawca jest ustawiony tak, aby używał podstawowego adresu URL https://{region}.oic.prod-aks.azure.com/{uuid}, w którym wartość parametru {region} jest zgodna z lokalizacją, w której wdrożony jest klaster usługi AKS. Wartość {uuid} reprezentuje klucz OIDC.

Tworzenie konta usługi Kubernetes

Jeśli nie masz dedykowanego konta usługi Kubernetes utworzonego dla tej aplikacji, wykonaj następujące kroki, aby utworzyć, a następnie dodaj do niego adnotację przy użyciu identyfikatora klienta tożsamości zarządzanej utworzonej w poprzednim kroku. Użyj polecenia az aks get-credentials i zastąp wartości nazwy klastra i nazwy grupy zasobów.

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

Skopiuj i wklej następujące dane wejściowe wielowierszowe w interfejsie wiersza polecenia platformy Azure.

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

Następujące dane wyjściowe przypominają pomyślne utworzenie tożsamości:

Serviceaccount/workload-identity-sa created

Ustanawianie zaufania poświadczeń tożsamości federacyjnej

Użyj polecenia az identity federated-credential create, aby utworzyć poświadczenia tożsamości federacyjnej między tożsamością zarządzaną, wystawcą konta usługi i tematem. Zastąp wartości resourceGroupName, , userAssignedIdentityName, federatedIdentityNameserviceAccountNamespacei 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

Uwaga

Propagacja poświadczeń tożsamości federacyjnej po ich dodaniu trwa kilka sekund. Jeśli żądanie tokenu jest wykonywane natychmiast po dodaniu poświadczeń tożsamości federacyjnej, może to prowadzić do niepowodzenia przez kilka minut, ponieważ pamięć podręczna jest wypełniana w katalogu starymi danymi. Aby uniknąć tego problemu, możesz dodać niewielkie opóźnienie po dodaniu poświadczeń tożsamości federacyjnej.

Wdrażanie obciążenia przy użyciu przyczepki migracji

Uwaga

Przyczepka migracji nie jest obsługiwana do użytku produkcyjnego. Ta funkcja ma na celu zapewnienie czasu na przeprowadzenie migracji zestawu SDK aplikacji do obsługiwanej wersji, a nie oznacza to rozwiązania długoterminowego lub zamierzonego. Przyczepka migracji dotyczy tylko kontenerów systemu Linux, ponieważ tożsamości zarządzane przez zasobniki były dostępne tylko w pulach węzłów systemu Linux.

Jeśli aplikacja korzysta z tożsamości zarządzanej i nadal korzysta z imDS w celu uzyskania tokenu dostępu, możesz użyć przyczepki migracji tożsamości obciążenia, aby rozpocząć migrację do tożsamości obciążenia. Ten przyczepka jest rozwiązaniem migracji i w długoterminowych aplikacjach należy zmodyfikować ich kod, aby używać najnowszych zestawów SDK tożsamości platformy Azure, które obsługują asercji klienta.

Aby zaktualizować lub wdrożyć obciążenie, dodaj te adnotacje zasobników tylko wtedy, gdy chcesz użyć przyczepki migracji. W specyfikacji zasobnika należy wstrzyknąć następujące wartości adnotacji , aby użyć przyczepki:

azure.workload.identity/inject-proxy-sidecar - wartość jest true lub false
azure.workload.identity/proxy-sidecar-port - wartość jest żądanym portem dla przyczepki serwera proxy. Domyślna wartość to 8000.

Po utworzeniu zasobnika z powyższymi adnotacjami tożsamość obciążenia platformy Azure zmutowaniem elementu webhook automatycznie wprowadza kontener init-container i przyczepkę serwera proxy do specyfikacji zasobnika.

Element webhook, który jest już uruchomiony, dodaje następujące fragmenty kodu YAML do wdrożenia zasobnika. Poniżej przedstawiono przykład zmutowanego zasobnika specyfikacji:

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

Ta konfiguracja ma zastosowanie do dowolnej konfiguracji, w której jest tworzony zasobnik. Po zaktualizowaniu lub wdrożeniu aplikacji możesz sprawdzić, czy zasobnik jest w stanie uruchomienia, używając polecenia kubectl describe pod . Zastąp wartość podName nazwą obrazu wdrożonego zasobnika.

kubectl describe pods podName

Aby sprawdzić, czy zasobnik przekazuje transakcje IMDS, użyj polecenia kubectl logs . Zastąp wartość podName nazwą obrazu wdrożonego zasobnika:

kubectl logs podName

Następujące dane wyjściowe dziennika przypominają pomyślną komunikację za pośrednictwem przyczepki serwera proxy. Sprawdź, czy dzienniki pokazują, że token został pomyślnie uzyskany, a operacja GET zakończyła się pomyślnie.

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>"

Usuwanie tożsamości zarządzanej zasobnika

Po zakończeniu testowania i pomyślnym pobraniu tokenu przy użyciu przyczepki serwera proxy można usunąć mapowanie tożsamości zarządzanej przez zasobnik firmy Microsoft Entra dla zasobnika z klastra, a następnie usunąć tożsamość.

Uruchom polecenie az aks pod-identity delete, aby usunąć tożsamość z zasobnika. Należy to zrobić tylko wtedy, gdy wszystkie zasobniki w przestrzeni nazw przy użyciu mapowania tożsamości zarządzanej zasobnika zostały zmigrowane do korzystania z przyczepki.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Następne kroki

W tym artykule pokazano, jak skonfigurować zasobnik do uwierzytelniania przy użyciu tożsamości obciążenia jako opcji migracji. Aby uzyskać więcej informacji na temat Tożsamość obciążeń Microsoft Entra, zobacz następujący artykuł Omówienie.

Udostępnij za pośrednictwem