한눈에 보기

AKS의 pod 관리 ID(pod-managed identity)는 끝까지 preview였고, AKS 애드온은 2025년 9월까지만 패치와 지원을 받았다. 오픈소스 프로젝트 aad-pod-identity는 2022년 10월 deprecated, 2023년 9월 보관(archived)됐다(Microsoft Learn). 지금 이 구성을 쓰고 있다면 지원 없이 돌고 있는 셈이다. 대체재인 Microsoft Entra 워크로드 ID는 GA이며 AKS Automatic에는 기본으로 켜져 있다(Microsoft Learn).

워크로드 ID의 원리는 AKS 입문 4회에서 다뤘다. 이번 회는 기존 pod 관리 ID에서 옮기는 절차에 집중한다.

경로 고르기: 앱의 SDK 버전이 기준

Microsoft의 이전 가이드는 세 경로를 제시한다.

• 경로 · 맞는 경우
• 병행 배포 · 앱이 이미 워크로드 ID를 지원하는 Azure Identity SDK 버전을 쓸 때. pod 관리 ID와 나란히 띄워 검증한 뒤 제거
• 이전용 사이드카 · 구버전 SDK라 당장 코드를 못 바꿀 때. 사이드카가 IMDS 요청을 받아 OIDC 토큰 교환으로 대신 처리. Linux 전용, 임시 방편
• 코드 수정 · 앱을 최신 Azure Identity로 바꾼 뒤 이전

워크로드 ID를 지원하는 최소 SDK 버전은 다음과 같다(Microsoft Learn).

• 언어 · 패키지 · 최소 버전
• .NET · Azure.Identity · 1.9.0
• Java · azure-identity · 1.9.0
• Python · azure-identity · 1.13.0
• Node.js · @azure/identity · 3.2.0
• Go · azidentity · 1.3.0
• C++ · azure-identity-cpp · 1.6.0

코드에서는 DefaultAzureCredential이나 WorkloadIdentityCredential을 쓴다. 사이드카는 장기 운영용이 아니라고 Microsoft가 명시했으니, 사이드카로 옮기더라도 SDK 업그레이드 일정을 함께 잡는다.

1단계: 클러스터에서 워크로드 ID 켜기

2단계: 기존 관리 ID에 페더레이션 자격 증명 만들기

pod 관리 ID에서 쓰던 사용자 할당 관리 ID를 그대로 재사용할 수 있다. Azure 쪽 역할 할당을 다시 만들 필요가 없다는 뜻이다. 그 ID에 "이 클러스터의 이 서비스 계정이 보낸 토큰을 믿는다"는 페더레이션 자격 증명을 추가한다.

관리 ID 하나에 페더레이션 자격 증명은 최대 20개다. 반영에 수 초에서 수 분이 걸리므로, 만든 직후의 토큰 요청은 실패할 수 있다.

3단계: 서비스 계정과 pod 바꾸기

Deployment의 pod 템플릿에는 serviceAccountName: my-app-sa와 레이블 azure.workload.identity/use: "true"를 넣는다. 값은 문자열이어야 한다. 사이드카 경로라면 어노테이션 azure.workload.identity/inject-proxy-sidecar: "true"를 더한다.

자주 걸리는 함정은 다음과 같다(Microsoft Learn).

• 레이블을 빠뜨리면 pod가 재시작된 뒤 인증에 실패한다.
• 서비스 계정 어노테이션을 바꿨다면 pod를 재시작해야 반영된다.
• 토큰 범위는 https://management.azure.com/.default처럼 v2 형식으로 준다.
• 토큰 파일 경로를 코드에 박지 말고 AZUREFEDERATEDTOKENFILE 환경 변수를 쓴다.
• virtual node에서는 워크로드 ID를 쓸 수 없다.

4단계: 검증 후 pod 관리 ID 제거

새 pod가 워크로드 ID로 Azure 자원에 접근하는지 확인했다면, 앱 매니페스트에서 aadpodidbinding 레이블을 지우고 pod 관리 ID를 정리한다(Microsoft Learn).

마지막 두 명령으로 AzureIdentity와 AzureIdentityBinding이 남지 않았는지 확인한다. 애드온이 아니라 Helm으로 직접 aad-pod-identity를 설치했다면, 제거 절차는 Microsoft 문서에 따로 나와 있지 않으니 설치할 때 쓴 방식으로 지운다.

KEDA를 쓰고 있다면 함께 점검한다. KEDA 2.15부터는 pod 관리 ID를 지원하지 않으므로 스케일러 인증도 워크로드 ID로 바꿔야 한다(Microsoft Learn).

정리

• 앱별 Azure Identity SDK 버전부터 조사해 경로를 정한다.
• 기존 관리 ID에 페더레이션 자격 증명을 더하면 역할 할당은 그대로 쓸 수 있다.
• 서비스 계정 어노테이션과 pod 레이블, 둘 다 있어야 한다.
• 검증이 끝나면 pod 관리 ID와 aadpodidbinding 레이블을 지운다.

다음 회에서는 2027년 6월 1일 시작되는 플랫폼 강제 업그레이드에 대비하는 방법을 다룬다.

출처

• Migrate from pod managed identity to workload identity — Microsoft Learn
• Microsoft Entra Workload ID with AKS — Microsoft Learn
• Deploy and configure workload identity on AKS — Microsoft Learn
• Use Microsoft Entra pod-managed identities in AKS — Microsoft Learn
• KEDA add-on for AKS — Microsoft Learn

이 글은 공개 출처를 바탕으로 AI가 자동 생성한 초안을 검토해 발행했으며, 중요한 판단 전에는 연결된 원문을 확인해야 합니다.