Azure Arc 클러스터에서 사용하도록 설정된 AKS에서 워크로드 ID 배포 및 구성(미리 보기)

아티클
11/23/2024

적용 대상: Azure Local, 버전 23H2

워크로드 ID 페더레이션을 사용하면 Kubernetes와 같은 외부 ID 공급자(IdP)의 토큰을 신뢰하도록 Microsoft Entra ID의 사용자 할당 관리 ID 또는 앱 등록을 구성하여 Azure Key Vault 또는 Azure Blob Storage와 같이 Microsoft Entra로 보호되는 리소스에 액세스할 수 있습니다.

Azure Arc에서 사용하도록 설정된 AKS(Azure Kubernetes Service)는 워크로드 ID를 사용하도록 설정된 Kubernetes 클러스터를 쉽게 배포할 수 있는 관리되는 Kubernetes 서비스입니다. 이 문서에서는 다음 작업을 수행하는 방법을 설명합니다.

워크로드 ID를 사용하도록 설정된 AKS Arc 클러스터를 만듭니다(미리 보기).
Kubernetes 서비스 계정을 만들고 Azure 관리 ID에 바인딩합니다.
관리 ID에 페더레이션 자격 증명을 만들어 OIDC 발급자를 신뢰합니다.
애플리케이션을 배포합니다.
예: 클러스터의 Pod에 Azure Key Vault의 비밀에 대한 액세스 권한을 부여합니다.

워크로드 아이덴티티 페더레이션에 대한 개념적 개요는 Azure Arc 지원 Kubernetes(미리 보기)에서워크로드 아이덴티티 페더레이션을 참조하세요.

Important

이러한 미리 보기 기능은 셀프 서비스에서 옵트인(opt-in)으로 사용할 수 있습니다. 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. Azure Arc 미리 보기에서 사용하도록 설정된 Azure Kubernetes Service는 고객 지원에서 최대한 많이 지원됩니다.

참고 항목

퍼블릭 프리뷰에서 Azure 로컬의 AKS 버전 23H2는 AKS 클러스터 생성 시 워크로드 ID를 사용하도록 설정할 수 있습니다. 그러나 클러스터를 만든 후 워크로드 ID를 사용하도록 설정하거나 나중에 사용하지 않도록 설정하는 것은 현재 지원되지 않습니다.

필수 조건

Azure Arc를 사용하도록 설정된 Kubernetes 클러스터를 배포하기 전에 다음 필수 구성 요소가 있어야 합니다.

Azure 구독이 없으신 경우 시작하기 전에 무료 계정을 만드세요.
이 문서에는 Azure CLI 버전 1.4.23 이상이 필요합니다. Azure Cloud Shell을 사용하는 경우 최신 버전이 이미 설치되어 있습니다.

환경 변수 내보내기

필요한 ID를 구성하는 단계를 간소화하기 위해 다음 명령은 이 문서의 예제에서 참조되는 환경 변수를 정의합니다. 다음 값을 사용자의 고유 값으로 바꿉니다.

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

활성 구독 설정

먼저 구독을 현재 활성 구독으로 설정합니다. 구독 ID를 사용하여 az account set 명령을 실행합니다.

az login  
az account set -s $AZSubscriptionID

리소스 그룹 만들기

Azure 리소스 그룹은 Azure 리소스가 배포되고 관리되는 논리 그룹입니다. 리소스 그룹을 만들 때 위치를 지정하라는 메시지가 표시됩니다. 이 위치는 리소스 그룹 메타데이터의 스토리지 위치이며 리소스를 만드는 중에 다른 지역을 지정하지 않은 경우 Azure에서 리소스가 실행되는 위치입니다.

리소스 그룹을 만들려면 az group create 명령을 실행합니다.

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

다음 예제 출력은 리소스 그룹을 성공적으로 만드는 방법을 보여줍니다.

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

1단계: 워크로드 ID를 사용하도록 설정된 AKS Arc 클러스터 만들기

AKS Arc 클러스터를 만들려면 값과 $customlocation_ID 값이 $logicnet_Id 모두 필요합니다.

$customlocation_ID: 사용자 지정 위치의 Azure Resource Manager ID입니다. 사용자 지정 위치는 Azure Local 버전 23H2 클러스터 배포 중에 구성됩니다. 인프라 관리자는 사용자 지정 위치의 Resource Manager ID를 제공해야 합니다. 인프라 관리자가 사용자 지정 위치 이름 및 리소스 그룹 이름을 제공하는 경우 리소스 관리자 ID를 가져올 $customlocation_ID = $(az customlocation show --name "<your-custom-location-name>" --resource-group $resource_group_name --query "id" -o tsv)수도 있습니다.
$logicnet_Id: 다음 단계에 따라 만든 Azure 로컬 논리 네트워크의 Azure Resource Manager ID입니다. 인프라 관리자는 논리 네트워크의 Resource Manager ID를 제공해야 합니다. 인프라 관리자가 논리 네트워크 이름 및 리소스 그룹 이름을 제공하는 경우 리소스 관리자 ID를 사용하여 $logicnet_Id = $(az stack-hci-vm network lnet show --name "<your-lnet-name>" --resource-group $resource_group_name --query "id" -o tsv)가져올 수도 있습니다.

매개 변수를 사용하여 az aksarc create 명령을 --enable-oidc-issuer --enable-workload-identity 실행합니다. entra-admin-group-object-ids를 제공하고 프록시 모드 액세스를 위한 Microsoft Entra ID 관리 그룹의 구성원인지 확인합니다.

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

몇 분 후 명령이 완료되면 클러스터에 대한 JSON 형식 정보가 반환됩니다.

프로비전된 클러스터를 성공적으로 만든 후 워크로드 ID 확장을 배포하는 데 다소 시간이 걸릴 수 있습니다. 다음 명령을 사용하여 워크로드 ID 확장 상태를 확인합니다.

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

Azure Portal에서 Kubernetes 클러스터의 속성 섹션에서 wiextension 확장을 볼 수 있습니다.

Important

AKS Arc 클러스터에 대한 보안 향상의 일환으로 워크로드 ID 사용은 두 가지 변경 내용을 트리거합니다. 먼저 Kubernetes 서비스 계정 서명 키는 45일마다 자동으로 회전하며 90일 동안 유효합니다. 둘째, 플래그를 --service-account-extend-token-expiration 사용하지 않도록 설정하여 토큰 유효성을 1년에서 최대 24시간으로 줄입니다.

환경 변수에 OIDC 발급자 URL 저장

AKS 클러스터가 성공적으로 만들어지면 OIDC 발급자 URL을 가져와서 환경 변수에 저장할 수 있습니다. 다음 명령을 실행합니다.

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

2단계: Kubernetes 서비스 계정을 만들고 Azure 관리 ID에 바인딩

먼저 관리 ID를 만듭니다. az identity create 명령을 실행합니다.

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

다음으로 관리 ID의 클라이언트 ID에 대한 변수를 만듭니다.

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

Kubernetes 서비스 계정 만들기

Kubernetes 서비스 계정을 만들고 이전 단계에서 만든 관리 ID의 클라이언트 ID로 주석을 추가합니다.

az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

새 창을 엽니다. 다음 CLI 명령을 복사하여 붙여넣습니다.

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

다음 출력은 서비스 계정을 성공적으로 만드는 방법을 보여줍니다.

serviceaccount/workload-identity-sa created

3단계: 관리 ID에 페더레이션 자격 증명을 만들어 OIDC 발급자를 신뢰합니다.

먼저 페더레이션 ID 자격 증명을 만듭니다. az identity federated-credential create 명령을 호출하여 관리 ID, 서비스 계정 발급자 및 주체 간에 페더레이션 ID 자격 증명을 만듭니다. Microsoft Entra의 페더레이션된 ID 자격 증명에 대한 자세한 내용은 Microsoft Entra ID의 페더레이션된 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

참고 항목

페더레이션 ID 자격 증명을 추가한 후 전파하는 데 몇 초 정도 걸립니다. 캐시가 새로 고쳐질 때까지 즉시 수행된 토큰 요청이 실패할 수 있습니다. 이 문제를 방지하려면 페더레이션 ID 자격 증명을 만든 후 잠시 지연을 추가하는 것이 좋습니다.

4단계: 애플리케이션 배포

애플리케이션 Pod를 배포할 때 매니페스트는 Kubernetes 서비스 계정 만들기 단계에서 만든 서비스 계정을 참조해야 합니다. 다음 매니페스트는 계정, 특히 및 metadata\namespace 속성을 참조하는 spec\serviceAccountName 방법을 보여 줍니다. image에 이미지를 지정하고 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 -

Important

워크로드 ID를 사용하는 애플리케이션 Pod에 Pod 사양에 레이블 azure.workload.identity/use: "true" 이 포함되어 있는지 확인합니다. 그렇지 않으면 다시 시작한 후 Pod가 실패합니다.

예: Azure Key Vault에 액세스할 수 있는 권한 부여

이 단계의 지침에서는 Pod에서 Azure Key Vault의 비밀, 키 또는 인증서에 액세스하는 방법을 설명합니다. 이 섹션의 예에서는 워크로드 ID에 대한 키 자격 증명 모음의 비밀에 대한 액세스를 구성하지만 유사한 단계를 수행하여 키 또는 인증서에 대한 액세스를 구성할 수 있습니다.

다음 예에서는 Azure RBAC(Azure 역할 기반 액세스 제어) 권한 모델을 사용하여 Pod에 키 자격 증명 모음에 대한 액세스 권한을 부여하는 방법을 보여 줍니다. Azure Key Vault용 Azure RBAC 권한 모델에 대한 자세한 내용은 Azure RBAC를 사용하여 애플리케이션에 Azure Key Vault에 액세스할 수 있는 권한 부여를 참조하세요.

제거 방지 및 RBAC 권한 부여가 사용하도록 설정된 키 자격 증명 모음을 만듭니다. 제거 방지 및 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)

새 키 자격 증명 모음에서 비밀을 만들 수 있도록 RBAC Key Vault 비밀 책임자 역할을 자신에게 할당합니다. 새 역할 할당은 전파하고 권한 부여 서버에서 업데이트하는 데 최대 5분이 소요될 수 있습니다.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets Officer" --scope $KVId --assignee-principal-type ServicePrincipal
```

키 자격 증명 모음에서 비밀을 만듭니다.

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

이전에 만든 사용자 할당 관리 ID에 Key Vault 비밀 사용자 역할을 할당합니다. 이 단계에서는 관리 ID에 키 자격 증명 모음에서 비밀을 읽을 수 있는 권한을 부여합니다.
```
az role assignment create --assignee-object-id $MSIPrincipalId --role "Key Vault Secrets User" --scope $KVId --assignee-principal-type ServicePrincipal
```

키 자격 증명 모음 URL에 대한 환경 변수를 만듭니다.

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

서비스 계정 및 키 자격 증명 모음 URL을 참조하는 Pod를 배포합니다.

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

AKS Arc 클러스터 삭제

AKS Arc 클러스터를 삭제하려면 az aksarc delete 명령을 사용하세요.

az aksarc delete -n $aks_cluster_name -g $resource_group_name

참고 항목

PodDisruptionBudget(PDB) 리소스를 사용하여 AKS Arc 클러스터를 삭제할 때 알려진 문제가 있습니다. 삭제 시 이러한 PDB 리소스를 제거하지 못할 수 있습니다. Microsoft는 이 문제를 인식하고 있으며 수정 작업을 진행 중입니다.

PDB는 워크로드 ID 사용 AKS Arc 클러스터에 기본적으로 설치됩니다. AKS Arc 클러스터를 사용하도록 설정된 워크로드 ID를 삭제하려면 문제 해결 가이드참조하세요.

다음 단계

이 문서에서는 Kubernetes 클러스터를 배포하고 애플리케이션 워크로드가 해당 자격 증명으로 인증하도록 준비하기 위해 워크로드 ID를 사용하도록 구성했습니다. 이제 애플리케이션을 배포하고 최신 버전의 Azure ID 클라이언트 라이브러리와 함께 워크로드 ID를 사용하도록 구성할 준비가 되었습니다.

다음을 통해 공유

Azure Arc 클러스터에서 사용하도록 설정된 AKS에서 워크로드 ID 배포 및 구성(미리 보기)

필수 조건

환경 변수 내보내기

활성 구독 설정

리소스 그룹 만들기

1단계: 워크로드 ID를 사용하도록 설정된 AKS Arc 클러스터 만들기

환경 변수에 OIDC 발급자 URL 저장

2단계: Kubernetes 서비스 계정을 만들고 Azure 관리 ID에 바인딩

Kubernetes 서비스 계정 만들기

3단계: 관리 ID에 페더레이션 자격 증명을 만들어 OIDC 발급자를 신뢰합니다.

4단계: 애플리케이션 배포

예: Azure Key Vault에 액세스할 수 있는 권한 부여

AKS Arc 클러스터 삭제

다음 단계

피드백

추가 리소스