Pod yönetilen kimliğinden iş yükü kimliğine geçiş

Makale
10/24/2023

Bu makale, Pod ile yönetilen bir kimlikten Azure Kubernetes Service (AKS) kümeniz için Microsoft Entra İş Yükü Kimliği geçişine odaklanmaktadır. Ayrıca kapsayıcı tabanlı uygulamanız tarafından kullanılan Azure Identity istemci kitaplığının sürümüne bağlı olarak da rehberlik sağlar.

Microsoft Entra İş Yükü Kimliği hakkında bilginiz yoksa aşağıdaki Genel Bakış makalesine bakın.

Başlamadan önce

Azure CLI sürüm 2.47.0 veya üzeri. Sürümü bulmak için komutunu az --version çalıştırın ve sürümü yükseltmek için komutunu çalıştırın az upgrade . Yüklemeniz veya yükseltmeniz gerekirse, bkz. Azure CLI yükleme.

Geçiş senaryoları

Bu bölümde, Azure Kimlik SDK'sının hangi sürümünün yüklü olduğuna bağlı olarak kullanılabilen geçiş seçenekleri açıklanmaktadır.

Her iki senaryoda da, uygulamanızı iş yükü kimliğini kullanacak şekilde güncelleştirmeden önce federasyon güveninin ayarlanmış olması gerekir. Gereken en düşük adımlar şunlardır:

Yönetilen kimlik kimlik bilgileri oluşturun.
Yönetilen kimliği pod ile yönetilen kimlik için zaten kullanılan kubernetes hizmet hesabıyla ilişkilendirin veya yeni bir Kubernetes hizmet hesabı oluşturun ve ardından yönetilen kimlikle ilişkilendirin.
Yönetilen kimlik ile Microsoft Entra Kimliği arasında bir federasyon güven ilişkisi oluşturun.

En son sürümden geçiş

Uygulamanız zaten Azure Kimlik SDK'sının en son sürümünü kullanıyorsa, kimlik doğrulama yapılandırmasını tamamlamak için aşağıdaki adımları gerçekleştirin:

İş yükü kimliğini pod ile yönetilen kimlikle paralel olarak dağıtın. Uygulama dağıtımınızı yeniden başlatarak OIDC ek açıklamalarını uygulamaya otomatik olarak eklediği iş yükü kimliğini kullanmaya başlayabilirsiniz.
Uygulamanın başarıyla kimlik doğrulaması gerçekleştirebildiğini doğruladıktan sonra pod ile yönetilen kimlik ek açıklamalarını uygulamanızdan kaldırabilir ve ardından pod ile yönetilen kimlik eklentisini kaldırabilirsiniz.

Eski sürümden geçiş

Uygulamanız Azure Kimlik SDK'sının en son sürümünü kullanmıyorsa iki seçeneğiniz vardır:

Linux uygulamalarınızda sağladığımız ve uygulamanızın OpenID Bağlan (OIDC) üzerinden yaptığı I AVH işlemlerini proxy'leyen bir geçiş sepet kullanabilirsiniz. Geçiş sepetleri uzun vadeli bir çözüm olarak tasarlanmamıştır ancak iş yükü kimliğiyle çalışmaya başlamanın bir yoludur. Aşağıdaki adımları gerçekleştirin:
- Uygulama I AVH işlemlerine ara sunucu sağlamak için geçiş sepetli iş yükünü dağıtın.
- Kimlik doğrulama işlemlerinin başarıyla tamamlandığından emin olun.
- Uygulamaların SDK'larını desteklenen bir sürüme güncelleştirmeleri için çalışmayı zamanlayın.
- SDK'lar desteklenen sürüme güncelleştirildikten sonra ara sunucuyu kaldırabilir ve uygulamayı yeniden dağıtabilirsiniz.
Dekont

Geçiş sepet üretim kullanımı için desteklenmez. Bu özellik, uygulama SDK'nızı desteklenen bir sürüme geçirmeniz için size zaman tanıyacak ve uzun vadeli bir çözüm olarak tasarlanmamıştır. Geçiş sepet, yalnızca Linux düğüm havuzlarıyla pod ile yönetilen kimlikler sağlanması nedeniyle yalnızca Linux kapsayıcıları için kullanılabilir.
Azure Identity istemci kitaplığının en son sürümünü desteklemek için uygulamanızı yeniden yazın. Daha sonra aşağıdaki adımları gerçekleştirin:
- İş yükü kimliğini kullanarak kimlik doğrulamasına başlamak için uygulama dağıtımınızı yeniden başlatın.
- Kimlik doğrulama işlemlerinin başarıyla tamamlanıp tamamlanmadığını doğruladıktan sonra pod ile yönetilen kimlik ek açıklamalarını uygulamanızdan kaldırabilir ve ardından pod ile yönetilen kimlik eklentisini kaldırabilirsiniz.

Yönetilen kimlik oluşturma

Oluşturulmuş ve podunuza atanmış bir yönetilen kimliğiniz yoksa depolama, Key Vault veya uygulamanızın Azure'da kimlik doğrulaması yapması gereken kaynaklar için gerekli izinleri oluşturmak ve vermek için aşağıdaki adımları gerçekleştirin.

Belirli bir aboneliği geçerli etkin abonelik olarak ayarlamak için Azure CLI az account set komutunu kullanın. Ardından yönetilen kimlik oluşturmak için az identity create komutunu kullanın.

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

Yönetilen kimliğe Azure'da gereken kaynaklara erişmek için gereken izinleri verin. Bunun nasıl yapılacağını öğrenmek için bkz . Kaynağa yönetilen kimlik erişimi atama.
OIDC Veren URL'sini almak ve bir ortam değişkenine kaydetmek için aşağıdaki komutu çalıştırın. Küme adı ve kaynak grubu adı için varsayılan değerleri değiştirin.
```
export AKS_OIDC_ISSUER="$(az aks show --name myAKSCluster --resource-group myResourceGroup --query "oidcIssuerProfile.issuerUrl" -o tsv)"
```
değişkeni, aşağıdaki örneğe benzer şekilde Veren URL'sini içermelidir:
```
https://eastus.oic.prod-aks.azure.com/00000000-0000-0000-0000-000000000000/00000000-0000-0000-0000-000000000000/
```
Veren varsayılan olarak, değerinin AKS kümesinin dağıtıldığı konumla eşleştiği {region} temel URL'yi https://{region}.oic.prod-aks.azure.com/{uuid}kullanacak şekilde ayarlanır. değeri {uuid} OIDC anahtarını temsil eder.

Kubernetes hizmet hesabı oluşturma

Bu uygulama için oluşturulmuş ayrılmış bir Kubernetes hizmet hesabınız yoksa, önceki adımda oluşturulan yönetilen kimliğin istemci kimliğiyle oluşturmak ve buna ek açıklama eklemek için aşağıdaki adımları uygulayın. az aks get-credentials komutunu kullanın ve küme adı ile kaynak grubu adı değerlerini değiştirin.

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

Aşağıdaki çok satırlı girişi kopyalayıp Azure CLI'ye yapıştırın.

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şağıdaki çıkış, kimliğin başarıyla oluşturulmasına benzer:

Serviceaccount/workload-identity-sa created

Federasyon kimliği kimlik bilgisi güveni oluşturma

Yönetilen kimlik, hizmet hesabı veren ve konu arasında federasyon kimliği kimlik bilgilerini oluşturmak için az identity federated-credential create komutunu kullanın. , , userAssignedIdentityName, federatedIdentityNameserviceAccountNamespaceve serviceAccountNamedeğerlerini resourceGroupNamedeğiştirin.

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

Dekont

Şirket dışı kimlik bilgilerinin ilk eklendikten sonra yayılması birkaç saniye sürer. Federasyon kimliği kimlik bilgileri eklendikten hemen sonra bir belirteç isteği yapılırsa, önbellek dizinde eski verilerle doldurulduktan sonra birkaç dakika hataya neden olabilir. Bu sorunu önlemek için, federasyon kimliği kimlik bilgilerini ekledikten sonra biraz gecikme ekleyebilirsiniz.

Geçiş sepetli iş yükünü dağıtma

Dekont

Geçiş sepet üretim kullanımı için desteklenmez. Bu özellik, uygulama SDK'nızı desteklenen bir sürüme geçirmeniz için size zaman tanıyacak ve uzun vadeli bir çözüm olarak tasarlanmamıştır. Geçiş sepet yalnızca Linux kapsayıcıları içindir çünkü pod ile yönetilen kimlikler yalnızca Linux düğüm havuzlarında kullanılabilirdi.

Uygulamanız yönetilen kimlik kullanıyorsa ve hala erişim belirteci almak için I AVH kullanıyorsa iş yükü kimliği geçiş sepetini kullanarak iş yükü kimliğine geçiş yapmaya başlayabilirsiniz. Bu sepet bir geçiş çözümüdür ve uzun vadeli uygulamalarda, istemci onayını destekleyen en son Azure Kimlik SDK'larını kullanacak şekilde kodlarını değiştirmeniz gerekir.

İş yükünü güncelleştirmek veya dağıtmak için bu pod ek açıklamalarını yalnızca geçiş sepetini kullanmak istiyorsanız ekleyin. Pod belirtiminizde sepet kullanmak için aşağıdaki ek açıklama değerlerini eklersiniz:

azure.workload.identity/inject-proxy-sidecar - değer true veya false
azure.workload.identity/proxy-sidecar-port - değeri ara sunucu sepet için istenen bağlantı noktasıdır. 8000 varsayılan değerdir.

Yukarıdaki ek açıklamalara sahip bir pod oluşturulduğunda, Web kancasını sessize alan Azure İş Yükü Kimliği, init-kapsayıcısını ve ara sunucuyu pod belirtimine otomatik olarak ekler.

Zaten çalışmakta olan web kancası, pod dağıtımına aşağıdaki YAML kod parçacıklarını ekler. Aşağıda, mutasyona uğrayan pod belirtiminin bir örneği verilmiştir:

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

Bu yapılandırma, pod'un oluşturulduğu tüm yapılandırmalar için geçerlidir. Uygulamanızı güncelleştirdikten veya dağıtdıktan sonra kubectl describe pod komutunu kullanarak pod'un çalışır durumda olduğunu doğrulayabilirsiniz. değerini podName dağıtılan podunuzun görüntü adıyla değiştirin.

kubectl describe pods podName

Pod'un I AVH işlemlerini geçirdiğini doğrulamak için kubectl logs komutunu kullanın. değerini podName dağıtılan podunuzun görüntü adıyla değiştirin:

kubectl logs podName

Aşağıdaki günlük çıkışı, ara sunucu sepet üzerinden başarılı bir iletişime benzer. Günlüklerde bir belirtecin başarıyla alındığını ve GET işleminin başarılı olduğunu doğrulayı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>"

Pod ile yönetilen kimliği kaldırma

Testinizi tamamladıktan ve uygulama proxy sepet kullanarak belirteç almayı başarıyla tamamladıktan sonra, pod için Microsoft Entra pod yönetilen kimlik eşlemesini kümenizden kaldırabilir ve ardından kimliği kaldırabilirsiniz.

Kimliği podunuzdan kaldırmak için az aks pod-identity delete komutunu çalıştırın. Bu yalnızca pod ile yönetilen kimlik eşlemesi kullanılarak ad alanında bulunan tüm podlar sepet kullanmak üzere geçirildikten sonra yapılmalıdır.
```
az aks pod-identity delete --name podIdentityName --namespace podIdentityNamespace --resource-group myResourceGroup --cluster-name myAKSCluster
```

Sonraki adımlar

Bu makalede, geçiş seçeneği olarak bir iş yükü kimliği kullanarak podunuzun kimlik doğrulaması için nasıl ayarlanacağı gösterilmektedir. Microsoft Entra İş Yükü Kimliği hakkında daha fazla bilgi için aşağıdaki Genel Bakış makalesine bakın.

Aracılığıyla paylaş