Migrálás a pod felügyelt identitásáról a számítási feladat identitására

Ez a cikk a pod által felügyelt identitásról az Azure Kubernetes Service-fürt Microsoft Entra Számítási feladat ID való migrálására összpontosít. Útmutatást is nyújt a tárolóalapú alkalmazás által használt Azure Identity-ügyfélkódtár verziójától függően.

Ha nem ismeri a Microsoft Entra Számítási feladat ID, tekintse meg az alábbi Áttekintés cikket.

Előkészületek

Az Azure CLI 2.47.0-s vagy újabb verziója. Futtassa az --version a verziót, és futtassa az upgrade a verzió frissítéséhez. Ha telepíteni vagy frissíteni szeretne: Az Azure CLI telepítése.

Migrálási forgatókönyvek

Ez a szakasz az Azure Identity SDK telepített verziójától függően elérhető migrálási lehetőségeket ismerteti.

Mindkét forgatókönyv esetében be kell állítania az összevont megbízhatósági kapcsolatot, mielőtt frissítené az alkalmazást a számítási feladat identitásának használatára. A szükséges minimális lépések a következők:

Migrálás a legújabb verzióról

Ha az alkalmazás már használja az Azure Identity SDK legújabb verzióját, hajtsa végre a következő lépéseket a hitelesítési konfiguráció elvégzéséhez:

  • A számítási feladatok identitásának üzembe helyezése a pod által felügyelt identitással párhuzamosan. Újraindíthatja az alkalmazás üzembe helyezését a számítási feladat identitásának használatának megkezdéséhez, ahol az automatikusan injektálja az OIDC-jegyzeteket az alkalmazásba.
  • Miután meggyőződött arról, hogy az alkalmazás sikeresen hitelesíthető, eltávolíthatja a pod által felügyelt identitásjegyzeteket az alkalmazásból, majd eltávolíthatja a pod által felügyelt identitás bővítményt.

Migrálás a régebbi verzióról

Ha az alkalmazás nem az Azure Identity SDK legújabb verzióját használja, két lehetősége van:

  • Használhat egy migrálási oldalkocsit, amelyet a Linux-alkalmazásokban biztosítunk, amely az alkalmazás által az OpenID Csatlakozás (OIDC) felé irányuló IMDS-tranzakciókat proxyz. A migrálási oldalkocsi nem hosszú távú megoldás, hanem a számítási feladatok identitásának gyors üzembe helyezésének módja. Hajtsa végre a következő lépéseket:

    • Helyezze üzembe a számítási feladatot a migrálási oldalkocsival az alkalmazás IMDS-tranzakcióinak proxyzásához.
    • Ellenőrizze, hogy a hitelesítési tranzakciók sikeresen befejeződnek-e.
    • Ütemezze az alkalmazások munkáját, hogy az SDK-k egy támogatott verzióra frissüljenek.
    • Miután az SDK-t frissítette a támogatott verzióra, eltávolíthatja a proxyoldali kocsit, és újra üzembe helyezheti az alkalmazást.

    Megjegyzés:

    A migrálási oldalkocsi éles használatra nem támogatott. Ez a funkció időt biztosít az alkalmazás SDK-jának egy támogatott verzióra való migrálására, és nem hosszú távú megoldásnak szánták vagy tervezték. A migrálási oldalkocsi csak Linux-tárolókhoz érhető el, mivel csak pod által felügyelt identitásokat biztosít Linux-csomópontkészletekkel.

  • Írja át az alkalmazást az Azure Identity-ügyfélkódtár legújabb verziójának támogatásához. Ezután hajtsa végre a következő lépéseket:

    • Indítsa újra az alkalmazás üzembe helyezését, hogy megkezdje a hitelesítést a számítási feladat identitásával.
    • Miután meggyőződött arról, hogy a hitelesítési tranzakciók sikeresen befejeződtek, eltávolíthatja a pod által felügyelt identitásjegyzeteket az alkalmazásból, majd eltávolíthatja a pod által felügyelt identitás bővítményt.

Felügyelt identitás létrehozása

Ha nem rendelkezik a podhoz létrehozott és hozzárendelt felügyelt identitással, hajtsa végre az alábbi lépéseket, hogy létrehozza és megadja a szükséges engedélyeket a tárterülethez, a Key Vaulthoz vagy bármely olyan erőforráshoz, amellyel az alkalmazásnak hitelesítenie kell az Azure-ban.

  1. Az Azure CLI az account set parancsával beállíthatja, hogy egy adott előfizetés legyen az aktuális aktív előfizetés. Ezután az az identity create paranccsal hozzon létre egy felügyelt identitást.

    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)"
    
  2. Adja meg a felügyelt identitásnak az azure-beli erőforrások eléréséhez szükséges engedélyeket. Ennek módjáról további információt a Felügyelt identitás hozzáférésének hozzárendelése erőforráshoz című témakörben talál.

  3. Az OIDC-kiállító URL-címének lekéréséhez és egy környezeti változóba való mentéséhez futtassa az alábbi parancsot. Cserélje le a fürt és az erőforráscsoport nevének alapértelmezett értékeit.

    export AKS_OIDC_ISSUER="$(az aks show -n myAKSCluster -g myResourceGroup --query "oidcIssuerProfile.issuerUrl" -otsv)"
    

    A változónak a következő példához hasonló kiállítói URL-címet kell tartalmaznia:

    https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
    

    Alapértelmezés szerint a kiállító az alap URL-címet https://{region}.oic.prod-aks.azure.com/{uuid}használja, ahol az érték {region} megegyezik az AKS-fürt üzembe helyezésének helyével. Az érték {uuid} az OIDC-kulcsot jelöli.

Kubernetes-szolgáltatásfiók létrehozása

Ha nem rendelkezik dedikált Kubernetes-szolgáltatásfiókkal ehhez az alkalmazáshoz, hajtsa végre a következő lépéseket a létrehozáshoz, majd fűzi hozzá az előző lépésben létrehozott felügyelt identitás ügyfélazonosítójával. Használja az az aks get-credentials parancsot , és cserélje le a fürt nevének és az erőforráscsoport nevének értékeit.

az aks get-credentials -n myAKSCluster -g "${RESOURCE_GROUP}"

Másolja és illessze be a következő többsoros bemenetet az Azure CLI-ben.

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

A következő kimenet hasonlít az identitás sikeres létrehozására:

Serviceaccount/workload-identity-sa created

Összevont identitás hitelesítő adatainak megbízhatóságának létrehozása

Az az identity federated-credential create paranccsal hozza létre az összevont identitás hitelesítő adatait a felügyelt identitás, a szolgáltatásfiók kiállítója és a tulajdonos között. Cserélje le az értékeket resourceGroupName, userAssignedIdentityName, federatedIdentityNameés serviceAccountNameserviceAccountNamespace.

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

Megjegyzés:

Az összevont identitás hitelesítő adatának propagálása néhány másodpercet vesz igénybe a kezdeti hozzáadását követően. Ha a jogkivonat-kérés közvetlenül az összevont identitás hitelesítő adatainak hozzáadása után történik, az néhány percig sikertelen lehet, mivel a gyorsítótár régi adatokkal van feltöltve a könyvtárban. A probléma elkerülése érdekében az összevont identitás hitelesítő adatainak hozzáadása után némi késést adhat hozzá.

A számítási feladat üzembe helyezése migrálási oldalkocsival

Megjegyzés:

A migrálási oldalkocsi éles használatra nem támogatott. Ez a funkció időt biztosít az alkalmazás SDK-jának egy támogatott verzióra való migrálására, és nem hosszú távú megoldásnak szánták vagy tervezték. A migrálási oldalkocsi csak Linux-tárolókhoz használható, mivel a pod által felügyelt identitások csak Linux-csomópontkészleteken érhetők el.

Ha az alkalmazás felügyelt identitást használ, és továbbra is az IMDS-re támaszkodik egy hozzáférési jogkivonat beszerzéséhez, a számítási feladatok identitásának migrálási oldalkocsija segítségével megkezdheti a számítási feladatok identitására való migrálást. Ez a sidecar egy migrálási megoldás, és a hosszú távú alkalmazásokban módosítania kell a kódjukat, hogy a legújabb Azure Identity SDK-kat használhassa, amelyek támogatják az ügyfelek állítását.

A számítási feladat frissítéséhez vagy üzembe helyezéséhez csak akkor vegye fel ezeket a podjegyzeteket, ha a migrálási oldalkocsit szeretné használni. A pod specifikációjában a következő széljegyzetértékeket kell beszúrnia az oldalkocsi használatához:

  • azure.workload.identity/inject-proxy-sidecar- az érték vagy truefalse
  • azure.workload.identity/proxy-sidecar-port - az érték a proxy oldalkocsijának kívánt portja. The default value is 8000.

A fenti széljegyzetekkel rendelkező pod létrehozásakor az Azure Workload Identity-et mutáló webhook automatikusan injektálja az init-tárolót és a proxy oldalkocsit a pod specifikációjára.

A már futó webhook hozzáadja a következő YAML-kódrészleteket a pod üzembe helyezéséhez. Az alábbiakban egy példa látható a mutáns pod specifikációjára:

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

Ez a konfiguráció minden olyan konfigurációra vonatkozik, ahol podot hoznak létre. Az alkalmazás frissítése vagy üzembe helyezése után a kubectl leíró pod parancsával ellenőrizheti, hogy a pod futó állapotban van-e. Cserélje le az értéket podName az üzembe helyezett pod képnevére.

kubectl describe pods podName

Annak ellenőrzéséhez, hogy a pod átadja-e az IMDS-tranzakciókat, használja a kubectl logs parancsot. Cserélje le az értéket podName az üzembe helyezett pod képnevére:

kubectl logs podName

Az alábbi naplókimenet a proxyoldali kocsin keresztüli sikeres kommunikációhoz hasonlít. Ellenőrizze, hogy a naplók egy jogkivonatot mutatnak-e, és hogy a GET művelet sikeres-e.

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

Pod által felügyelt identitás eltávolítása

Miután elvégezte a tesztelést, és az alkalmazás sikeresen le tud szerezni egy jogkivonatot a proxyoldali kocsival, eltávolíthatja a pod Microsoft Entra pod által felügyelt identitásleképezését a fürtből, majd eltávolíthatja az identitást.

  1. Futtassa az az aks pod-identity delete parancsot az identitás podról való eltávolításához. Ezt csak akkor szabad elvégezni, ha a névtérben a pod által felügyelt identitásleképezést használó összes pod át lett migrálva az oldalkocsi használatára.

    az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
    

Következő lépések

Ez a cikk bemutatta, hogyan állíthatja be a podot a számítási feladatok identitásának migrálási lehetőségként való hitelesítéséhez. A Microsoft Entra Számítási feladat ID kapcsolatos további információkért tekintse meg az alábbi Áttekintés cikket.