Pod yönetilen kimliğinden iş yükü kimliğine geçiş
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 Connect'e (OIDC) yaptığı IMDS 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 IMDS işlemlerine ara sunuculuk yapmak 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.
Not
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'yihttps://{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
, federatedIdentityName
serviceAccountNamespace
ve serviceAccountName
değerlerini resourceGroupName
değ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
Not
Ş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
Not
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 erişim belirteci almak için hala IMDS 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ğertrue
veyafalse
azure.workload.identity/proxy-sidecar-port
- değeri ara sunucu sepet için istenen bağlantı noktasıdır. Varsayılan değer şudur:8000
.
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 IMDS 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.
Azure Kubernetes Service