Wdrażanie i konfigurowanie tożsamości obciążeń w klastrze AKS Hybrid and Edge (wersja zapoznawcza)

Dotyczy: AKS w usłudze Azure lokalnie

Federacja tożsamości na potrzeby zarządzania obciążeniem umożliwia skonfigurowanie zarządzanej tożsamości przypisanej przez użytkownika lub rejestracji aplikacji w usłudze Microsoft Entra ID, aby ufać tokenom od zewnętrznego dostawcy tożsamości (IdP), takiego jak Kubernetes, umożliwiając dostęp do zasobów chronionych przez Microsoft Entra, takich jak Azure Key Vault lub Azure Blob storage.

Azure Kubernetes Service (AKS) Hybrid and Edge to zarządzana usługa Kubernetes, która umożliwia łatwe wdrażanie klastrów Kubernetes z obsługą tożsamości obciążenia. W tym artykule opisano sposób wykonywania następujących zadań:

• Utwórz klaster usługi AKS z włączoną tożsamością obciążenia (wersja zapoznawcza).
• Utwórz konto usługi Kubernetes i powiąż je z tożsamością zarządzaną Azure.
• Utwórz poświadczenie federacyjne w tożsamości zarządzanej w celu uzyskania zaufania do wystawcy OIDC.
• Wdróż aplikację.
• Przykład: Przyznanie dostępu podowi w klastrze do tajemnic w Azure Key Vault.

Aby zapoznać się z koncepcyjnym omówieniem federacji tożsamości obciążeń, zobacz Federacja tożsamości obciążeń w Azure Arc-enabled Kubernetes (wersja zapoznawcza).

Wymagania wstępne

Przed wdrożeniem klastra Kubernetes z włączoną usługą Azure Arc należy spełnić następujące wymagania wstępne:

• Jeśli nie masz subskrypcji Azure, przed rozpoczęciem utwórz darmowe konto.
• Wersja 1.4.23 lub nowsza Azure CLI. Jeśli używasz usługi Azure Cloud Shell, najnowsza wersja jest już zainstalowana.

Eksportowanie zmiennych środowiskowych

Aby uprościć kroki konfigurowania wymaganych tożsamości, uruchom następujące polecenia, aby zdefiniować zmienne środowiskowe. Przykłady w tym artykule odwołują się do tych zmiennych. Zastąp następujące wartości własnymi wartościami:

$AZSubscriptionID = "00000000-0000-0000-0000-000000000000" 
$Location = "westeurope" 
$resource_group_name = "myResourceGroup" 

$aks_cluster_name = "myAKSCluster" 

$SERVICE_ACCOUNT_NAMESPACE = "default" 
$SERVICE_ACCOUNT_NAME = "workload-identity-sa" 

$FedIdCredentialName = "myFedIdentity" 
$MSIName = "myIdentity" 

# To access key vault secrets from a pod in the cluster, include these variables:
$KVName = "KV-workload-id" 
$KVSecretName= "KV-secret"

Ustawianie aktywnej subskrypcji

Najpierw ustaw subskrypcję jako aktywną. Uruchom polecenie az account set z identyfikatorem subskrypcji:

az login  
az account set -s $AZSubscriptionID

Tworzenie grupy zasobów

Grupa zasobów platformy Azure to grupa logiczna, w której zasoby platformy Azure są wdrażane i zarządzane. Podczas tworzenia grupy zasobów zostanie wyświetlony monit o określenie lokalizacji. Ta lokalizacja to lokalizacja magazynu metadanych grupy zasobów i lokalizacja, w której zasoby są uruchamiane na platformie Azure, jeśli nie określisz innego regionu podczas tworzenia zasobów.

Aby utworzyć grupę zasobów, uruchom polecenie az group create:

az group create --name $resource_group_name --location $Location

W poniższych przykładowych danych wyjściowych przedstawiono pomyślne utworzenie grupy zasobów:

{ 
  "id": "/subscriptions/<guid>/resourceGroups/myResourceGroup", 
  "location": "westeurope", 
  "managedBy": null, 
  "name": "$resource_group_name", 
  "properties": { 
    "provisioningState": "Succeeded" 
  }, 
  "tags": null 
}

Krok 1. Tworzenie klastra usługi AKS z włączoną tożsamością obciążenia

Aby utworzyć klaster AKS, potrzebujesz obu wartości $customlocation_ID i $logicnet_Id.

• $customlocation_ID: identyfikator usługi Azure Resource Manager lokalizacji niestandardowej. Niestandardowa lokalizacja jest konfigurowana podczas wdrażania klastra lokalnego Azure. Administrator infrastruktury powinien podać identyfikator Resource Manager dla lokalizacji niestandardowej. Identyfikator usługi Resource Manager można również uzyskać, uruchamiając polecenie $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv), jeśli administrator infrastruktury udostępnia niestandardową nazwę lokalizacji i nazwę grupy zasobów.
• $logicnet_Id: Identyfikator usługi Azure Resource Manager lokalnej sieci logicznej platformy Azure utworzony zgodnie z tymi krokami. Administrator infrastruktury powinien podać ID Resource Managera dla sieci logicznej. Identyfikator usługi Resource Manager można również uzyskać, uruchamiając polecenie $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv), jeśli administrator infrastruktury udostępnia nazwę sieci logicznej i nazwę grupy zasobów.

Uruchom polecenie az aksarc create za pomocą parametru --enable-oidc-issuer --enable-workload-identity . Podaj identyfikatory entra-admin-group-object-ids i upewnij się, że jesteś członkiem grupy administracyjnej Identyfikator entra firmy Microsoft na potrzeby dostępu do trybu serwera proxy:

az aksarc create  
-n $aks_cluster_name -g $resource_group_name  
--custom-location $customlocation_ID --vnet-ids $logicnet_Id  
--aad-admin-group-object-ids <entra-admin-group-object-ids> 
--generate-ssh-keys  
--enable-oidc-issuer --enable-workload-identity

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

Wdrożenie rozszerzenia tożsamości obciążenia po pomyślnym utworzeniu aprowizowanego klastra może zająć trochę czasu. Użyj następującego polecenia, aby sprawdzić stan rozszerzenia tożsamości obciążenia:

az connectedk8s show -n $aks_cluster_name -g $resource_group_name

# agentState = "Succeeded" 
"agentPublicKeyCertificate": "", 
  "agentVersion": "1.21.10", 
  "arcAgentProfile": { 
    "agentAutoUpgrade": "Enabled", 
    "agentErrors": [], 
    "agentState": "Succeeded", 
    "desiredAgentVersion": "", 
    "systemComponents": null 

# oidcIssuerProfile "enabled": true and "issuerUrl" present 

"oidcIssuerProfile": { 
    "enabled": true, 
    "issuerUrl": "https://oidcdiscovery-{location}-endpoint-1111111111111111.000.azurefd.net/00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111/"}

W witrynie Azure Portal możesz wyświetlić rozszerzenie wiextension w sekcji Właściwości klastra Kubernetes.

Zapisywanie adresu URL wystawcy OIDC w zmiennej środowiskowej

Po pomyślnym utworzeniu klastra usługi AKS można uzyskać adres URL wystawcy OIDC i zapisać go w zmiennej środowiskowej. Uruchom następujące polecenie:

$SERVICE_ACCOUNT_ISSUER =$(az connectedk8s show --n $aks_cluster_name --resource-group $resource_group_name --query "oidcIssuerProfile.issuerUrl" --output tsv)

Krok 2. Tworzenie konta usługi Kubernetes i powiązanie go z tożsamością zarządzaną platformy Azure

Najpierw utwórz tożsamość zarządzaną. Uruchom polecenie: az identity create

az identity create --name $MSIName --resource-group $resource_group_name --location $Location --subscription $AZSubscriptionID

Następnie utwórz zmienne dla identyfikatora klienta tożsamości zarządzanej:

$MSIId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'clientId' --output tsv)
$MSIPrincipalId=$(az identity show --resource-group $resource_group_name --name $MSIName --query 'principalId' --output tsv)

Tworzenie konta usługi Kubernetes

W tym kroku tworzysz konto usługi Kubernetes i oznaczasz je identyfikatorem klienta tożsamości zarządzanej, którą utworzyłeś w poprzednim kroku.

Aby uzyskać dostęp do klastra z urządzenia klienckiego, użyj połączenia klastra. Aby uzyskać więcej informacji, zobacz Uzyskaj dostęp do swojego klastra z urządzenia klienckiego:

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

Otwórz nowe okno interfejsu wiersza poleceń. Skopiuj i wklej następujące polecenia:

$yaml = @"
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: $MSIId
  name: $SERVICE_ACCOUNT_NAME
  namespace: $SERVICE_ACCOUNT_NAMESPACE
"@

$yaml = $yaml -replace '\$MSIId', $MSIId `
               -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME `
               -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE

$yaml | kubectl apply -f -

Następujące dane wyjściowe pokazują pomyślne utworzenie konta usługi:

serviceaccount/workload-identity-sa created

Krok 3. Tworzenie poświadczeń federacyjnych w tożsamości zarządzanej w celu zaufania wystawcy OIDC

Najpierw utwórz kredencjał tożsamości federacyjnej. Użyj polecenia az identity federated-credential create, aby utworzyć federacyjne poświadczenie tożsamości między zarządzaną tożsamością, wystawcą konta usługi i podmiotem. 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.

# Create a federated credential 

az identity federated-credential create --name $FedIdCredentialName --identity-name $MSIName --resource-group $resource_group_name --issuer $SERVICE_ACCOUNT_ISSUER --subject "system:serviceaccount:${SERVICE_ACCOUNT_NAMESPACE}:${SERVICE_ACCOUNT_NAME}" 

# Show the federated credential 

az identity federated-credential show --name $FedIdCredentialName --resource-group $resource_group_name --identity-name $MSIName

Krok 4. Wdrażanie aplikacji

Podczas wdrażania zasobników aplikacji manifest powinien odwoływać się do konta usługi utworzonego w kroku Tworzenie konta usługi Kubernetes Service. Poniższy manifest pokazuje, jak odwoływać się do konta, a dokładniej do właściwości metadata\namespace i spec\serviceAccountName. Upewnij się, że określono obraz dla image oraz nazwę kontenera dla containerName:

$image = "<image>"  # Replace <image> with the actual image name 
$containerName = "<containerName>"  # Replace <containerName> with the actual container name 

$yaml = @" 
apiVersion: v1 
kind: Pod 
metadata: 
  name: sample-quick-start 
  namespace: $SERVICE_ACCOUNT_NAMESPACE 
  labels: 
    azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity. 
spec: 
  serviceAccountName: $SERVICE_ACCOUNT_NAME 
  containers: 
    - image: $image 
      name: $containerName 
"@ 

# Replace variables within the YAML content 
$yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME 

# Apply the YAML configuration 
$yaml | kubectl apply -f - 

Przykład: udzielanie uprawnień dostępu do usługi Azure Key Vault

Instrukcje w tym kroku opisują sposób uzyskiwania dostępu do sekretów, kluczy lub certyfikatów w magazynie kluczy Azure z poziomu zasobnika. Przykłady w tej sekcji pozwalają na skonfigurowanie dostępu do tajemnic w magazynie kluczy dla tożsamości zadania, ale możesz wykonać podobne kroki, aby skonfigurować dostęp do kluczy lub certyfikatów.

W poniższym przykładzie pokazano, jak używać modelu uprawnień kontroli dostępu na podstawie ról w Azure (Azure RBAC), aby przyznać podowi dostęp do key 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.

1. Utwórz magazyn kluczy z włączoną ochroną przed usunięciem i autoryzacją RBAC. Możesz również użyć istniejącego magazynu kluczy, jeśli jest skonfigurowany do ochrony przed przeczyszczeniem i autoryzacji RBAC:

   az keyvault create --name $KVName --resource-group $resource_group_name --location $Location --enable-purge-protection --enable-rbac-authorization
   
   # retrieve the key vault ID for role assignment
   $KVId=$(az keyvault show --resource-group $resource_group_name --name $KVName --query id --output tsv)
   

2. Przypisz sobie rolę RBAC Key Vault Secrets Officer, aby móc utworzyć tajny sekret w nowym magazynie kluczy. Propagowanie nowych przydziałów ról może zająć do pięciu minut, zanim zostaną zaktualizowane przez serwer autoryzacji.

   $CALLER_OBJECT_ID=$(az ad signed-in-user show --query id -o tsv)
   
   az role assignment create --assignee-object-id $CALLER_OBJECT_ID --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
   

3. Utwórz tajemnicę w magazynie kluczy

   az keyvault secret set --vault-name $KVName --name $KVSecretName --value "Hello!"
   

4. Przypisz rolę Key Vault Secrets User do utworzonej wcześniej tożsamości zarządzanej przypisanej przez użytkownika. Ten krok zapewnia uprawnienie tożsamości zarządzanej do odczytywania wpisów tajnych z magazynu kluczy:

   $IDENTITY_PRINCIPAL_ID=$(az identity show --name "$USER_ASSIGNED_IDENTITY_NAME" --resource-group "$resource_group_name" --query principalId --output tsv)
   
   az role assignment create --assignee-object-id $IDENTITY_PRINCIPAL_ID --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
   

5. Utwórz zmienną środowiskową dla adresu URL magazynu kluczy.

   $KVUrl=$(az keyvault show --resource-group $resource_group_name --name $KVName --query properties.vaultUri --output tsv)
   

6. Wdróż pod, który odwołuje się do konta usługi i adresu URL magazynu kluczy.

   $yaml = @" 
   apiVersion: v1 
   kind: Pod 
   metadata: 
     name: sample-quick-start 
     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: $KVUrl 
         - name: SECRET_NAME 
           value: $KVSecretName 
     nodeSelector: 
       kubernetes.io/os: linux 
   "@ 
   
   # Replace variables within the YAML content 
   $yaml = $yaml -replace '\$SERVICE_ACCOUNT_NAMESPACE', $SERVICE_ACCOUNT_NAMESPACE ` 
                   -replace '\$SERVICE_ACCOUNT_NAME', $SERVICE_ACCOUNT_NAME ` 
                   -replace '\$KVUrl', $KVUrl ` 
                   -replace '\$KVSecretName', $KVSecretName 
   
   # Apply the YAML configuration 
   $yaml | kubectl --kubeconfig <path-to-aks-cluster-kubeconfig> apply -f -
   

Usuń klaster AKS

Aby usunąć klaster usługi AKS, użyj polecenia az aksarc delete :

az aksarc delete -n $aks_cluster_name -g $resource_group_name

Następne kroki

W tym artykule wdrożono klaster Kubernetes i skonfigurowano go do używania tożsamości obciążenia 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 przy użyciu najnowszej wersji biblioteki klienta Azure Identity.

Możesz również pomóc w ochronie klastra na inne sposoby, postępując zgodnie ze wskazówkami w książce zabezpieczeń dla usługi AKS Hybrid and Edge.