Wdrażanie i konfigurowanie Tożsamość obciążeń Microsoft Entra w klastrze Azure Kubernetes Service (AKS)

Z tego artykułu dowiesz się, jak wdrożyć i skonfigurować klaster Azure Kubernetes Service (AKS) za pomocą Tożsamość obciążeń Microsoft Entra. Kroki opisane w tym artykule obejmują:

Utwórz nowy lub zaktualizuj istniejący klaster usługi AKS przy użyciu Azure CLI lub narzędzia Terraform z wystawcą OpenID Connect (OIDC) i aktywnym Tożsamość obciążeń Microsoft Entra.
Utwórz tożsamość dla obciążeń i konto usługi Kubernetes.
Skonfiguruj tożsamość zarządzaną na potrzeby federacji tokenów.
Wdróż obciążenie i zweryfikuj uwierzytelnianie przy użyciu tożsamości obciążenia.
Opcjonalnie umożliw przyznanie zasobnikowi w klastrze dostępu do sekretów w magazynie kluczy Azure.

Wymagania wstępne

Jeśli nie masz konta Azure, przed rozpoczęciem utwórz konto free.
Ten artykuł wymaga wersji 2.47.0 lub nowszej Azure CLI. W przypadku korzystania z Azure Cloud Shell najnowsza wersja jest już zainstalowana. Uruchom az --version, aby znaleźć wersję. Jeśli musisz zainstalować lub uaktualnić, zobacz Install Azure CLI.
Upewnij się, że tożsamość używana do utworzenia klastra ma odpowiednie minimalne uprawnienia. Aby uzyskać więcej informacji, zobacz opcje dostępu i tożsamości dla Azure Kubernetes Service (AKS).
Jeśli masz wiele subskrypcji Azure, wybierz odpowiedni identyfikator subskrypcji, w którym zasoby mają być rozliczane przy użyciu polecenia az account set.

Narzędzie Terraform zainstalowane lokalnie. Aby uzyskać instrukcje dotyczące instalacji, zobacz Instalowanie programu Terraform.

Uwaga

Możesz użyć łącznika usługi, aby ułatwić automatyczne konfigurowanie niektórych kroków. Aby uzyskać więcej informacji, zobacz Tutorial: Nawiązywanie połączenia z kontem magazynu Azure w Azure Kubernetes Service (AKS) za pomocą łącznika usługi przy użyciu Tożsamość obciążeń Microsoft Entra.

Tworzenie pliku konfiguracji narzędzia Terraform

Pliki konfiguracji narzędzia Terraform definiują infrastrukturę, którą program Terraform tworzy i zarządza.

Utwórz plik o nazwie main.tf i dodaj następujący kod, aby zdefiniować wersję programu Terraform i określić dostawcę Azure:

terraform {
 required_version = ">= 1.5.0"
 required_providers {
   azurerm = {
     source  = "hashicorp/azurerm"
     version = "~> 4.0"
   }
   kubernetes = {
     source  = "hashicorp/kubernetes"
     version = "~> 2.30"
   }
   random = {
     source  = "hashicorp/random"
     version = "~> 3.6"
   }
 }
}
provider "azurerm" {
 features {}
 subscription_id = var.subscription_id
}
data "azurerm_client_config" "current" {}

Dodaj następujący kod do main.tf, aby zdefiniować zmienne wielokrotnego użytku i wygenerować unikatowe nazwy dla wszystkich zasobów:

resource "random_string" "suffix" {
 length  = 6
 upper   = false
 special = false
 numeric = true
}
locals {
 suffix = random_string.suffix.result
 resource_group_name       = "rg-aks-wi-${local.suffix}"
 cluster_name              = "akswi${local.suffix}"
 managed_identity_name     = "uami-wi-${local.suffix}"
 federated_credential_name = "fic-wi-${local.suffix}"
 key_vault_name            = lower(substr("kvwi${local.suffix}", 0, 24))
 secret_name               = "secret-${local.suffix}"
 service_account_name      = "workload-sa-${local.suffix}"
 service_account_namespace = "default"
 workload_identity_subject = "system:serviceaccount:${local.service_account_namespace}:${local.service_account_name}"
}

Tworzenie grupy zasobów

Utwórz grupę zasobów przy użyciu polecenia az group create.

export RANDOM_ID="$(openssl rand -hex 3)"
export RESOURCE_GROUP="myResourceGroup$RANDOM_ID"
export LOCATION="<your-preferred-region>"
az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"

Dodaj następujący kod do main.tf, aby utworzyć grupę zasobów Azure. Zaktualizuj wartość location w celu dopasowania do preferowanego regionu Azure.

resource "azurerm_resource_group" "this" {
 name     = local.resource_group_name
 location = "eastus"
}

Włącz wystawcę OIDC i Tożsamość obciążeń Microsoft Entra w klastrze AKS

Można włączyć wystawcę OIDC i identyfikator obciążenia Microsoft Entra w nowym lub istniejącym klastrze AKS.

Utwórz nowy klaster AKS
Aktualizowanie istniejącego klastra usługi AKS

Utwórz klaster usługi AKS przy użyciu polecenia az aks create z parametrem --enable-oidc-issuer, aby włączyć wystawcę OIDC i parametr --enable-workload-identity w celu włączenia Tożsamość obciążeń Microsoft Entra. Poniższy przykład tworzy klaster z jednym węzłem:

export CLUSTER_NAME="myAKSCluster$RANDOM_ID"
az aks create \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity \
    --generate-ssh-keys

Po kilku minutach polecenie zostanie wykonane i zwróci informacje o klastrze w formacie JSON.

Dodaj następujący kod do main.tf, aby utworzyć klaster AKS z wystawcą OIDC i włączonym Tożsamość obciążeń Microsoft Entra.

resource "azurerm_kubernetes_cluster" "this" {
 name                              = local.cluster_name
 location                          = azurerm_resource_group.this.location
 resource_group_name               = azurerm_resource_group.this.name
 dns_prefix                        = local.cluster_name
 oidc_issuer_enabled               = true
 workload_identity_enabled         = true
 role_based_access_control_enabled = true
 default_node_pool {
   name       = "system"
   node_count = 1
   vm_size    = "Standard_B4ms"
 }
 identity {
   type = "SystemAssigned"
 }
}

Zaktualizuj istniejący klaster usługi AKS, aby włączyć wystawcę OIDC i Tożsamość obciążeń Microsoft Entra, używając polecenia az aks update z parametrami --enable-oidc-issuer i --enable-workload-identity.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --enable-oidc-issuer \
    --enable-workload-identity

Jeśli masz już istniejący klaster usługi AKS zarządzany przez program Terraform, możesz zaktualizować zasób azurerm_kubernetes_cluster w pliku main.tf, aby włączyć wystawcę OIDC i Tożsamość obciążeń Microsoft Entra:

  oidc_issuer_enabled               = true
  workload_identity_enabled         = true

Pobierz adres URL wystawcy OIDC

Pobierz adres URL wystawcy OIDC przy użyciu az aks show polecenia i zapisz go w zmiennej środowiskowej.

export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query "oidcIssuerProfile.issuerUrl" \
    --output tsv)"

Zmienna środowiskowa powinna zawierać adres URL wystawcy podobny do następującego przykładu:

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

Domyślnie wystawca jest ustawiony tak, aby używał podstawowego adresu URL https://{region}.oic.prod-aks.azure.com/{tenant_id}/{uuid}, gdzie wartość parametru {region} jest zgodna z lokalizacją, do której wdrożony jest klaster usługi AKS. Wartość {uuid} reprezentuje klucz OIDC, który jest losowo generowany i niezmienny identyfikator GUID dla każdego klastra.

Dodaj następujący kod do main.tf, aby pobrać adres URL wystawcy OIDC:

output "oidc_issuer_url" {
 value = azurerm_kubernetes_cluster.this.oidc_issuer_url
}

Tworzenie tożsamości zarządzanej

Pobierz identyfikator subskrypcji i zapisz go w zmiennej środowiskowej az account show przy użyciu polecenia .
```
export SUBSCRIPTION="$(az account show --query id --output tsv)"
```

Utwórz tożsamość zarządzaną przypisaną przez użytkownika przy użyciu az identity create polecenia .

export USER_ASSIGNED_IDENTITY_NAME="myIdentity$RANDOM_ID"
az identity create \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --subscription "${SUBSCRIPTION}"

Poniższy przykład danych wyjściowych przedstawia pomyślne utworzenie tożsamości zarządzanej:

{
  "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/myResourceGroupxxxxxx/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentityxxxxxx",
  "location": "eastus",
  "name": "myIdentityxxxxxx",
  "principalId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "resourceGroup": "myResourceGroupxxxxxx",
  "systemData": null,
  "tags": {},
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Pobierz identyfikator klienta tożsamości zarządzanej i zapisz go w zmiennej środowiskowej az identity show przy użyciu polecenia .

export USER_ASSIGNED_CLIENT_ID="$(az identity show \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --query 'clientId' \
    --output tsv)"

Dodaj następujący kod do main.tf, aby utworzyć tożsamość zarządzaną.

resource "azurerm_user_assigned_identity" "this" {
 name                = local.managed_identity_name
 location            = azurerm_resource_group.this.location
 resource_group_name = azurerm_resource_group.this.name
}

Tworzenie konta usługi Kubernetes

Połącz się z klastrem AKS za pomocą polecenia az aks get-credentials.

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

Utwórz konto usługi Kubernetes i dodaj do niego adnotację przy użyciu identyfikatora klienta tożsamości zarządzanej, stosując następujący manifest przy użyciu kubectl apply polecenia .

export SERVICE_ACCOUNT_NAME="workload-identity-sa$RANDOM_ID"
export SERVICE_ACCOUNT_NAMESPACE="default"
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 pokazują pomyślne stworzenie tożsamości zadania:

serviceaccount/workload-identity-sa created

Dodaj następujący kod do main.tf w celu skonfigurowania dostępu do Kubernetes, aby umożliwić tworzenie zasobów Kubernetes.

data "azurerm_kubernetes_cluster" "this" {
 name                = azurerm_kubernetes_cluster.this.name
 resource_group_name = azurerm_resource_group.this.name
}
provider "kubernetes" {
 host                   = data.azurerm_kubernetes_cluster.this.kube_config[0].host
 client_certificate     = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_certificate)
 client_key             = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].client_key)
 cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.this.kube_config[0].cluster_ca_certificate)
}

Dodaj następujący kod do main.tf, aby utworzyć konto serwisowe Kubernetes i oznaczyć je adnotacją z identyfikatorem klienta tożsamości zarządzanej.

resource "kubernetes_service_account" "this" {
 metadata {
   name      = local.service_account_name
   namespace = local.service_account_namespace
   annotations = {
     "azure.workload.identity/client-id" = azurerm_user_assigned_identity.this.client_id
   }
 }
}

Tworzenie poświadczeń tożsamości federacyjnej

Utwórz poświadczenie federacyjnej tożsamości między tożsamością zarządzaną, wystawcą konta usługi i podmiotem, przy użyciu polecenia az identity federated-credential create.

export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity$RANDOM_ID"
az identity federated-credential create \
    --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} \
    --identity-name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --issuer "${AKS_OIDC_ISSUER}" \
    --subject system:serviceaccount:"${SERVICE_ACCOUNT_NAMESPACE}":"${SERVICE_ACCOUNT_NAME}" \
    --audience api://AzureADTokenExchange

Uwaga

Federacyjne poświadczenia tożsamości potrzebują kilka sekund na propagację po ich dodaniu. Jeśli żądanie tokenu zostanie wykonane natychmiast po dodaniu poświadczeń tożsamości federacyjnej, żądanie może zakończyć się niepowodzeniem do czasu odświeżenia pamięci podręcznej. Aby uniknąć tego problemu, możesz dodać niewielkie opóźnienie po dodaniu poświadczenia tożsamości federacyjnej.

Dodaj następujący kod do main.tf, aby utworzyć poświadczenie tożsamości federacyjnej między tożsamością zarządzaną, wystawcą konta usługi i podmiotem:

resource "azurerm_federated_identity_credential" "this" {
 name                = local.federated_credential_name
 resource_group_name = azurerm_resource_group.this.name
 parent_id           = azurerm_user_assigned_identity.this.id
 issuer              = azurerm_kubernetes_cluster.this.oidc_issuer_url
 subject             = local.workload_identity_subject
 audience            = ["api://AzureADTokenExchange"]
}

Aby uzyskać więcej informacji na temat poświadczeń tożsamości federacyjnej w Microsoft Entra, zobacz Przegląd poświadczeń tożsamości federacyjnej w Microsoft Entra ID.

Tworzenie Key Vault z autoryzacją RBAC Azure

W poniższym przykładzie pokazano, jak używać modelu uprawnień kontroli dostępu opartej na rolach (Azure RBAC), aby przyznać podowi dostęp do klucza vault. Aby uzyskać więcej informacji na temat modelu uprawnień RBAC Azure dla Azure Key Vault, zobacz Przyznanie uprawnień aplikacjom do uzyskiwania dostępu do Azure Key Vault przy użyciu Azure RBAC.

Utwórz magazyn kluczy z ochroną przed usunięciem i autoryzacją Azure RBAC włączoną przy użyciu polecenia az keyvault create. Możesz również użyć istniejącego magazynu kluczy, jeśli jest skonfigurowany do ochrony przed czyszczeniem oraz autoryzacją przy użyciu Azure RBAC.

export KEYVAULT_NAME="keyvault-workload-id$RANDOM_ID" # Ensure the key vault name is between 3-24 characters
az keyvault create \
    --name "${KEYVAULT_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --location "${LOCATION}" \
    --enable-purge-protection \
    --enable-rbac-authorization

Pobierz identyfikator zasobu magazynu kluczy i zapisz go w zmiennej środowiskowej az keyvault show przy użyciu polecenia .

export KEYVAULT_RESOURCE_ID=$(az keyvault show --resource-group "${RESOURCE_GROUP}" \
    --name "${KEYVAULT_NAME}" \
    --query id \
    --output tsv)

Dodaj następujący kod do main.tf, aby utworzyć magazyn kluczy z autoryzacją RBAC Azure:

resource "azurerm_key_vault" "this" {
 name                          = local.key_vault_name
 location                      = azurerm_resource_group.this.location
 resource_group_name           = azurerm_resource_group.this.name
 tenant_id                     = data.azurerm_client_config.current.tenant_id
 sku_name                      = "standard"
 rbac_authorization_enabled    = true
}

Przypisywanie uprawnień RBAC do zarządzania magazynem kluczy

Pobierz identyfikator obiektu wywołującego i zapisz go w zmiennej środowiskowej az ad signed-in-user show przy użyciu polecenia .
```
export CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
```
Przypisz sobie rolę Azure RBAC Key Vault Secrets Officer, aby móc utworzyć sekret w nowym magazynie kluczy przy użyciu polecenia az role assignment create.
```
az role assignment create --assignee "${CALLER_OBJECT_ID}" \
    --role "Key Vault Secrets Officer" \
    --scope "${KEYVAULT_RESOURCE_ID}"
```

Dodaj następujący kod do main.tf, aby przypisać sobie rolę Azure RBAC Key Vault Secrets Officer, co pozwoli Ci utworzyć tajemnicę w nowym magazynie kluczy i przypisać rolę Key Vault Secrets User do tożsamości zarządzanej przypisanej przez użytkownika.

resource "azurerm_role_assignment" "user" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets Officer"
 principal_id         = data.azurerm_client_config.current.object_id
}
resource "azurerm_role_assignment" "identity" {
 scope                = azurerm_key_vault.this.id
 role_definition_name = "Key Vault Secrets User"
 principal_id         = azurerm_user_assigned_identity.this.principal_id
}

Tworzenie i konfigurowanie sekretnego dostępu

Utwórz tajemnicę w magazynie kluczy przy użyciu polecenia az keyvault secret set.

export KEYVAULT_SECRET_NAME="my-secret$RANDOM_ID"
az keyvault secret set \
    --vault-name "${KEYVAULT_NAME}" \
    --name "${KEYVAULT_SECRET_NAME}" \
    --value "Hello\!"

Uzyskaj identyfikator podmiotu użytkownika przypisanej tożsamości zarządzanej przy użyciu polecenia az identity show i zapisz go w zmiennej środowiskowej.

export IDENTITY_PRINCIPAL_ID=$(az identity show \
    --name "${USER_ASSIGNED_IDENTITY_NAME}" \
    --resource-group "${RESOURCE_GROUP}" \
    --query principalId \
    --output tsv)

Przypisz rolę Key Vault Secrets User do tożsamości zarządzanej przypisanej przez użytkownika przy użyciu polecenia az role assignment create. Ten krok daje tożsamości zarządzanej uprawnienie do odczytywania wpisów tajnych z magazynu kluczy.
```
az role assignment create \
    --assignee-object-id "${IDENTITY_PRINCIPAL_ID}" \
    --role "Key Vault Secrets User" \
    --scope "${KEYVAULT_RESOURCE_ID}" \
    --assignee-principal-type ServicePrincipal
```

Utwórz zmienną środowiskową dla adresu URL magazynu kluczy przy użyciu az keyvault show polecenia .

export KEYVAULT_URL="$(az keyvault show \
    --resource-group "${RESOURCE_GROUP}" \
    --name ${KEYVAULT_NAME} \
    --query properties.vaultUri \
    --output tsv)"

Dodaj następujący kod do main.tf, aby utworzyć sekret w magazynie kluczy.

resource "azurerm_key_vault_secret" "this" {
 name         = local.secret_name
 value        = "Hello from Key Vault"
 key_vault_id = azurerm_key_vault.this.id
}

Uruchomienie weryfikacyjnego poda i testowanie dostępu

Wdróż zasobnik, aby sprawdzić, czy tożsamość obciążenia może uzyskać dostęp do tajemnicy w magazynie kluczy. W poniższym przykładzie użyto obrazu ghcr.io/azure/azure-workload-identity/msal-go, który zawiera przykładową aplikację, która pobiera tajny klucz z Azure Key Vault przy użyciu Tożsamość obciążeń Microsoft Entra.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
    name: sample-workload-identity-key-vault
    namespace: ${SERVICE_ACCOUNT_NAMESPACE}
    labels:
        azure.workload.identity/use: "true"
spec:
    serviceAccountName: ${SERVICE_ACCOUNT_NAME}
    containers:
      - image: ghcr.io/azure/azure-workload-identity/msal-go
        name: oidc
        env:
          - name: KEYVAULT_URL
            value: ${KEYVAULT_URL}
          - name: SECRET_NAME
            value: ${KEYVAULT_SECRET_NAME}
    nodeSelector:
        kubernetes.io/os: linux
EOF

Poczekaj, aż pod będzie w stanie Ready przy użyciu polecenia kubectl wait.

kubectl wait --namespace ${SERVICE_ACCOUNT_NAMESPACE} --for=condition=Ready pod/sample-workload-identity-key-vault --timeout=120s

Sprawdź, czy zmienna SECRET_NAME środowiskowa jest ustawiona w zasobniku kubectl describe przy użyciu polecenia .
```
kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
```
W przypadku powodzenia dane wyjściowe powinny być podobne do następującego przykładu:
```
SECRET_NAME: ${KEYVAULT_SECRET_NAME}
```
Sprawdź, czy pody mogą uzyskać token i dostęp do zasobu przy użyciu kubectl logs polecenia.
```
kubectl logs sample-workload-identity-key-vault
```
W przypadku powodzenia dane wyjściowe powinny być podobne do następującego przykładu:
```
I0114 10:35:09.795900       1 main.go:63] "successfully got secret" secret="Hello\\!"
```
Ważne

Przypisywanie ról RBAC Azure może potrwać do 10 minut, zanim zostanie w pełni zaimplementowane. Jeśli zasobnik nie może uzyskać dostępu do sekretu, może być konieczne, aby poczekać na propagację przypisania roli. Aby uzyskać więcej informacji, zobacz Troubleshoot Azure RBAC.

Wyłącz Tożsamość obciążeń Microsoft Entra w klastrze usługi AKS

Wyłącz Tożsamość obciążeń Microsoft Entra w klastrze usługi AKS, w którym został on włączony i skonfigurowany, zaktualizuj klaster usługi AKS przy użyciu polecenia az aks update za pomocą parametru --disable-workload-identity.

az aks update \
    --resource-group "${RESOURCE_GROUP}" \
    --name "${CLUSTER_NAME}" \
    --disable-workload-identity

Uruchom pod weryfikacyjny

Dodaj następujący kod do main.tf, aby wdrożyć zasobnik weryfikacji, który używa tożsamości aplikacyjnej do uzyskania dostępu do sekretu w skarbcu kluczy.

resource "kubernetes_pod" "test" {
 metadata {
   name      = "workload-identity-test"
   namespace = local.service_account_namespace
   labels = {
     "azure.workload.identity/use" = "true"
   }
 }
 spec {
   service_account_name = kubernetes_service_account.this.metadata[0].name
   container {
     name  = "test"
     image = "ghcr.io/azure/azure-workload-identity/msal-go"
     env {
       name  = "KEYVAULT_URL"
       value = azurerm_key_vault.this.vault_uri
     }
     env {
       name  = "SECRET_NAME"
       value = azurerm_key_vault_secret.this.name
     }
   }
 }
}

Inicjowanie narzędzia Terraform

Zainicjuj Terraform w katalogu zawierającym plik main.tf przy użyciu polecenia terraform init. To polecenie pobiera dostawcę Azure wymaganego do zarządzania zasobami Azure za pomocą narzędzia Terraform.

terraform init

Tworzenie planu wykonania programu Terraform

Utwórz plan wykonywania narzędzia Terraform przy użyciu terraform plan polecenia . To polecenie pokazuje zasoby, które narzędzie Terraform utworzy lub zmodyfikuje w ramach subskrypcji Azure.

terraform plan

Stosowanie konfiguracji narzędzia Terraform

Po przejrzeniu i potwierdzeniu planu wykonania zastosuj konfigurację narzędzia Terraform przy użyciu terraform apply polecenia . To polecenie tworzy lub modyfikuje zasoby zdefiniowane w pliku main.tf w subskrypcji Azure.

terraform apply

Weryfikowanie wdrożenia

Połącz się z klastrem AKS za pomocą polecenia az aks get-credentials.

az aks get-credentials --name <cluster-name> --resource-group <resource-group>

Sprawdź stan podu weryfikacji przy użyciu polecenia kubectl get pods.
Gdy zasobnik osiągnie stan Ready, sprawdź, czy może uzyskać dostęp do tajnego klucza magazynu, przeglądając dzienniki zasobnika przy użyciu polecenia kubectl logs.
```
kubectl logs workload-identity-test
```

W tym artykule wdrożono klaster Kubernetes i skonfigurowano go do używania Tożsamość obciążeń Microsoft Entra w ramach przygotowań do uwierzytelniania obciążeń aplikacji przy użyciu tego poświadczenia. Teraz możesz przystąpić do wdrażania aplikacji i konfigurować ją tak, aby korzystała z tożsamości obciążenia z najnowszą wersją Azure Identity biblioteki klienta. Jeśli nie możesz ponownie napisać aplikacji w celu korzystania z najnowszej wersji biblioteki klienta, możesz skonfigurować zasobnik aplikacji do uwierzytelniania przy użyciu tożsamości zarządzanej z tożsamością obciążenia jako rozwiązaniem do migracji krótkoterminowej.

Integracja Service Connector pomaga uprościć konfigurację połączenia dla obciążeń AKS i usług wspierających Azure. Bezpiecznie obsługuje konfiguracje uwierzytelniania i sieci oraz stosuje najlepsze rozwiązania dotyczące nawiązywania połączenia z usługami Azure. Aby uzyskać więcej informacji, zobacz Połączenie z Azure OpenAI w modelach rozwiązania Foundry w usłudze AKS przy użyciu tożsamości obciążenia Microsoft Entra oraz wprowadzenie do Łącznika usług.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-04-08

Wdrażanie i konfigurowanie Tożsamość obciążeń Microsoft Entra w klastrze Azure Kubernetes Service (AKS)

Wymagania wstępne

Tworzenie pliku konfiguracji narzędzia Terraform

Tworzenie grupy zasobów

Włącz wystawcę OIDC i Tożsamość obciążeń Microsoft Entra w klastrze AKS

Pobierz adres URL wystawcy OIDC

Tworzenie tożsamości zarządzanej

Tworzenie konta usługi Kubernetes

Tworzenie poświadczeń tożsamości federacyjnej

Tworzenie Key Vault z autoryzacją RBAC Azure

Przypisywanie uprawnień RBAC do zarządzania magazynem kluczy

Tworzenie i konfigurowanie sekretnego dostępu

Uruchomienie weryfikacyjnego poda i testowanie dostępu

Wyłącz Tożsamość obciążeń Microsoft Entra w klastrze usługi AKS

Uruchom pod weryfikacyjny

Inicjowanie narzędzia Terraform

Tworzenie planu wykonania programu Terraform

Stosowanie konfiguracji narzędzia Terraform

Weryfikowanie wdrożenia

Treści powiązane

Opinia

Dodatkowe zasoby