이 문서에서는 Amazon EKS(Amazon Elastic Kubernetes Service) 및 AKS(Azure Kubernetes Service)가 클라우드 플랫폼 서비스에 액세스하기 위해 Kubernetes 워크로드에 대한 ID를 제공하는 방법을 설명합니다. AWS(Amazon Web Services) IAM(Identity and Access Management) 및 Microsoft Entra ID에 대한 자세한 비교는 다음을 참조하세요.
이 가이드에서는 AKS 클러스터, 기본 제공 서비스 및 추가 항목이 관리 ID 를 사용하여 부하 분산 장치 및 관리 디스크와 같은 Azure 리소스에 액세스하는 방법을 설명합니다. 또한 이 문서에서는 AKS 워크로드가 연결 문자열, 액세스 키 또는 사용자 자격 증명 없이도 Azure 리소스에 액세스할 수 있도록 Microsoft Entra 워크로드 ID 사용하는 방법을 보여 줍니다.
Amazon EKS ID 및 액세스 관리
Amazon EKS에는 Kubernetes Pod 내에서 AWS 서비스를 호출하는 두 가지 네이티브 옵션인 서비스 계정에 대한 IAM 역할 및 Amazon EKS 서비스 연결 역할이 있습니다.
서비스 계정에 대한 IAM 역할은 IAM 역할을 Kubernetes 서비스 계정과 연결합니다. 이 서비스 계정은 서비스 계정을 사용하는 모든 Pod의 컨테이너에 AWS 권한을 제공합니다. 서비스 계정에 대한 IAM 역할은 다음과 같은 이점을 제공합니다.
최소 권한: AWS API를 호출하기 위해 해당 노드 Pod의 노드 IAM 역할에 대한 확장 권한을 제공할 필요가 없습니다. IAM 권한의 범위를 서비스 계정으로 지정할 수 있으며 해당 서비스 계정을 사용하는 Pod만 해당 권한에 액세스할 수 있습니다. 또한 이 기능을 사용하면
kiam
또는kube2iam
등의 타사 솔루션이 필요하지 않습니다.자격 증명 격리: 컨테이너는 속한 서비스 계정과 연결된 IAM 역할에 대한 자격 증명만 검색할 수 있습니다. 컨테이너는 다른 Pod에 속하는 다른 컨테이너의 자격 증명에 액세스할 수 없습니다.
감사 가능성: Amazon CloudTrail은 회고 감사를 보장하는 데 도움이 되는 액세스 및 이벤트 로깅을 제공합니다.
Amazon EKS 서비스 연결 역할dms Amazon EKS에 직접 연결되는 고유한 IAM 역할입니다. 서비스 연결 역할은 Amazon EKS에서 미리 정의되며 해당 역할을 대신하여 다른 AWS 서비스를 호출하는 데 필요한 모든 권한을 포함합니다. Amazon EKS 노드 IAM 역할의 경우 Amazon EKS 노드 kubelet
디먼은 노드를 대신하여 AWS API를 호출합니다. 노드는 IAM 인스턴스 프로필 및 관련 정책에서 이러한 API 호출에 대한 권한을 얻습니다.
AKS 클러스터 관리 ID
AKS 클러스터에는 부하 분산 장치 및 관리 디스크와 같은 Azure 리소스에 액세스할 수 있는 ID가 필요합니다. 이 ID는 관리 ID 또는 서비스 주체일 수 있습니다. 기본적으로 AKS 클러스터를 만들면 시스템이 할당한 관리 ID가 자동으로 만들어집니다. Azure 플랫폼은 ID를 관리하며 비밀을 프로비전하거나 회전할 필요가 없습니다. Microsoft Entra 관리 ID에 대한 자세한 내용은 Azure 리소스에 대한 관리 ID를 참조 하세요.
AKS는 서비스 주체를 자동으로 만들지 않으므로 서비스 주체를 사용하려면 만들어야 합니다. 서비스 주체는 결국 만료되며 클러스터를 계속 작동하려면 갱신해야 합니다. 서비스 주체를 관리하면 복잡성이 추가되므로 관리 ID를 대신 사용하는 것이 더 쉽습니다.
관리 ID는 기본적으로 관리를 간소화하는 서비스 주체에 대한 래퍼입니다. 서비스 주체와 관리 ID 모두에 대해 동일한 권한 요구 사항이 적용됩니다. 관리 ID는 인증서 기반 인증을 사용합니다. 각 관리 ID 자격 증명은 90일 후에 만료되며 45일 후에 회전됩니다.
AKS는 시스템이 할당한 관리 ID 및 사용자가 할당한 관리 ID의 두 유형을 모두 사용하며 이러한 ID는 변경할 수 없습니다. 노드 리소스 그룹 외부의 리소스를 사용하여 AKS 가상 네트워크, 연결된 Azure 디스크, 고정 IP 주소, 경로 테이블 또는 사용자 할당 kubelet
ID를 만들거나 사용하는 경우 Azure CLI는 역할 할당을 자동으로 추가합니다.
Bicep 템플릿, Azure Resource Manager 템플릿 또는 Terraform 모듈과 같은 AKS 클러스터를 만드는 다른 방법을 사용하는 경우 클러스터 관리 ID의 주체 ID를 사용하여 역할 할당을 수행해야 합니다. AKS 클러스터 ID에는 가상 네트워크 내의 서브넷에서 네트워크 참가자 이상의 역할이 있어야 합니다. 기본 제공 네트워크 참가자 역할을 사용하는 대신 사용자 지정 역할을 정의하려는 경우 다음 권한이 필요합니다.
Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/read
클러스터 ID가 기존 리소스에 액세스해야 하는 경우(예: 기존 가상 네트워크에 AKS 클러스터를 배포하는 경우) 사용자가 할당한 관리 ID를 사용해야 합니다. 시스템이 할당한 컨트롤 플레인 ID를 사용하는 경우 리소스 공급자는 클러스터를 만들기 전에 해당 주체 ID를 가져올 수 없으므로 클러스터를 프로비전하기 전에 적절한 역할 할당을 만들 수 없습니다.
관리 ID 요약
AKS는 다음의 기본 제공 서비스 및 추가 항목에 대해 사용자가 할당한 관리 ID를 사용합니다.
ID | 이름 | 사용 사례 | 기본 권한 | 사용자 고유의 ID 가져오기 |
---|---|---|---|---|
제어 평면 | AKS 클러스터 이름 | 수신 부하 분산 장치 및 AKS 관리 공용 IP, 클러스터 자동 크기 조정기, Azure Disk 및 Azure 파일 CSI 드라이버를 포함한 클러스터 리소스 관리 | 노드 리소스 그룹에 대한 기여자 역할 | 지원 여부 |
kubelet | AKS Cluster Name-agentpool | Azure Container Registry를 사용하여 인증 | NA(Kubernetes v1.15 이상) | 지원 여부 |
추가 기능 | HTTPApplicationRouting | 필요한 네트워크 리소스 관리 | 노드 리소스 그룹에 대한 읽기 권한자 역할, DNS 영역에 대한 기여자 역할 | 아니요 |
추가 기능 | 수신 애플리케이션 게이트웨이 | 필요한 네트워크 리소스 관리 | 노드 리소스 그룹에 대한 기여자 역할 | 아니요 |
추가 기능 | omsagent | Azure Monitor에 AKS 메트릭 전송 | 모니터링 메트릭 게시자 역할 | 아니요 |
추가 기능 | Virtual-Node(ACIConnector) | Azure Container Instances에 필요한 네트워크 리소스 관리 | 노드 리소스 그룹에 대한 기여자 역할 | 아니요 |
자세한 내용은 Azure Kubernetes Service에서 관리 ID 사용을 참조하세요.
Kubernetes에 대한 Microsoft Entra 워크로드 ID
Kubernetes 워크로드에는 Azure Key Vault 및 Microsoft Graph와 같은 Microsoft Entra 보호 리소스에 액세스하려면 Microsoft Entra 애플리케이션 자격 증명이 필요합니다. 개발자에게 일반적인 과제는 솔루션의 여러 구성 요소 간의 통신을 보호하는 비밀 및 자격 증명을 관리하는 방법입니다.
Kubernetes용 Microsoft Entra 워크로드 ID Azure Cosmos DB, Azure Key Vault 또는 Azure Blob Storage와 같은 클라우드 서비스에 액세스하기 위해 자격 증명을 관리할 필요가 없습니다. AKS 호스팅 워크로드 애플리케이션은 Microsoft Entra 워크로드 ID 사용하여 연결 문자열, 사용자 이름 및 암호 또는 기본 키와 같은 명시적 자격 증명 대신 Microsoft Entra 보안 토큰을 사용하여 Azure 관리형 서비스에 액세스할 수 있습니다.
다음 다이어그램과 같이 Kubernetes 클러스터는 Kubernetes 서비스 계정에 토큰을 발급하는 보안 토큰 발급자가 됩니다. 이러한 토큰을 Microsoft Entra 애플리케이션에서 신뢰할 수 있도록 구성할 수 있습니다. 그런 다음, Azure ID SDK 또는 MSAL(Microsoft 인증 라이브러리)을 사용하여 Microsoft Entra 액세스 토큰으로 토큰을 교환할 수 있습니다.
kubelet
에이전트는 구성 파일 경로에서 워크로드에 서비스 계정 토큰을 투영합니다.- Kubernetes 워크로드는 프로젝션된 서명된 서비스 계정 토큰을 Microsoft Entra ID로 보내고 액세스 토큰을 요청합니다.
- Microsoft Entra ID는 OIDC 검색 문서를 사용하여 사용자 정의 관리 ID 또는 등록된 애플리케이션에 대한 신뢰를 확인하고 들어오는 토큰의 유효성을 검사합니다.
- Microsoft Entra ID는 보안 액세스 토큰을 발급합니다.
- Kubernetes 워크로드는 Microsoft Entra 액세스 토큰을 사용하여 Azure 리소스에 액세스합니다.
Kubernetes에 대한 Microsoft Entra 워크로드 ID 페더레이션은 현재 Microsoft Entra 애플리케이션에서만 지원되지만 동일한 모델은 잠재적으로 Azure 관리 ID로 확장될 수 있습니다.
Microsoft Entra 워크로드 ID 대한 자세한 내용, 자동화 및 설명서는 다음을 참조하세요.
- Azure 워크로드 ID 오픈 소스 프로젝트
- 워크로드 ID 페더레이션
- Kubernetes와의 Microsoft Entra 워크로드 ID 페더레이션
- 외부 OIDC ID 공급자와의 Microsoft Entra 워크로드 ID 페더레이션
- 최소 Microsoft Entra 워크로드 ID 페더레이션
- Microsoft Entra 워크로드 ID
- Microsoft Entra 워크로드 ID 빠른 시작
- .NET Standard 애플리케이션에서 사용자 할당 관리 ID가 있는 Kubernetes에 Microsoft Entra 워크로드 ID 사용
워크로드 예제
예제 워크로드는 AKS 클러스터에서 프런트 엔드 및 백 엔드 서비스를 실행합니다. 워크로드 서비스는 Microsoft Entra 워크로드 ID 사용하여 Microsoft Entra 보안 토큰을 사용하여 다음 Azure 서비스에 액세스합니다.
- Azure Key Vault
- Azure Cosmos DB
- Azure Storage 계정
- Azure Service Bus 네임스페이스
사전 요구 사항
- OIDC 발급자를 사용하도록 설정된 AKS 클러스터를 설정합니다.
- 변경 허용 웹후크를 설치합니다.
- 워크로드에 대한 Kubernetes 서비스 계정을 만듭니다.
- 빠른 시작에 표시된 대로 Microsoft Entra 애플리케이션을 만듭니다.
- 필요한 Microsoft Entra 등록 애플리케이션에 올바른 권한이 있는 역할을 할당합니다.
- Microsoft Entra 애플리케이션과 서비스 계정 발급자 및 주체 간에 페더레이션 ID 자격 증명을 설정합니다.
- 워크로드 애플리케이션을 AKS 클러스터에 배포합니다.
Microsoft Entra 워크로드 ID 메시지 흐름
AKS 애플리케이션은 AKS 클러스터의 OIDC 발급자 에서 해당 서비스 계정에 대한 보안 토큰을 가져옵니다. Microsoft Entra 워크로드 ID 보안 토큰을 Microsoft Entra ID에서 발급한 보안 토큰과 교환하고 애플리케이션은 Microsoft Entra ID 발급 보안 토큰을 사용하여 Azure 리소스에 액세스합니다.
다음 다이어그램에서는 프런트 엔드 및 백 엔드 애플리케이션이 Azure PaaS(Platform as a Service) 서비스를 사용하기 위해 Microsoft Entra 보안 토큰을 획득하는 방법을 보여 줍니다.
이 아키텍처의 Visio 파일을 다운로드합니다.
- Kubernetes는 Pod 또는 배포 사양에 따라 노드에서 예약될 때 Pod에 토큰을 발급합니다.
- Pod는 OIDC에서 발급한 토큰을 Microsoft Entra ID로 전송하여 특정
appId
및 리소스에 대한 Microsoft Entra 토큰을 요청합니다. - Microsoft Entra ID는 애플리케이션에 대한 트러스트를 확인하고 들어오는 토큰의 유효성을 검사합니다.
- Microsoft Entra ID는 보안 토큰을 발급합니다
{sub: appId, aud: requested-audience}
. . - Pod는 Microsoft Entra 토큰을 사용하여 대상 Azure 리소스에 액세스합니다.
Kubernetes 클러스터에서 엔드투엔드 Microsoft Entra 워크로드 ID 사용하려면 다음을 수행합니다.
- 해당 토큰의 유효성 검사를 허용하도록 토큰을 발급하고 OIDC 검색 문서를 게시하도록 AKS 클러스터를 구성합니다.
- Kubernetes 토큰을 신뢰하도록 Microsoft Entra 애플리케이션을 구성합니다.
- 개발자는 Kubernetes 서비스 계정을 사용하여 Kubernetes 토큰을 가져오기 위해 배포를 구성합니다.
- Microsoft Entra 워크로드 ID Microsoft Entra 토큰에 대한 Kubernetes 토큰을 교환합니다.
- AKS 클러스터 워크로드는 Microsoft Entra 토큰을 사용하여 Microsoft Graph와 같은 보호된 리소스에 액세스합니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
- Paolo Salvatori | 수석 서비스 엔지니어
- Martin Gjoshevski | 선임 서비스 엔지니어
기타 기여자:
- Laura Nicolas | 선임 소프트웨어 엔지니어
- Chad Kittel | 주 소프트웨어 엔지니어
- Ed Price | 선임 콘텐츠 프로그램 관리자
- Theano Petersen | 기술 작가
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.
다음 단계
- Amazon EKS 전문가용 AKS
- Kubernetes 모니터링 및 로깅
- Kubernetes에 대한 네트워크 액세스 보호
- Kubernetes 클러스터에 대한 스토리지 옵션
- Kubernetes에 대한 비용 관리
- Kubernetes 노드 및 노드 풀 관리
- 클러스터 거버넌스
- AWS용 Microsoft Entra ID 관리 및 액세스 관리