AKS는 5가지 고유한 시나리오에서 ID를 사용합니다. 각 시나리오는 다른 질문에 답변하고 고유한 구성 모델을 가지고 있습니다. 이 문서에서는 각각에 대해 간략하게 소개하고 심층 분석 설명서를 가리킵니다.
AKS의 5가지 ID 시나리오
| Scenario | 이 질문이 다루는 내용 | 심층 분석 문서 |
|---|---|---|
| A. Kubernetes의 컨트롤 플레인 인증 | Kubernetes API를 누르는 호출자는 누구인가요? | 클러스터 인증 개념, 외부 ID 공급자 |
| B. Kubernetes 컨트롤 플레인 권한 부여 | Kubernetes API에 인증되면 호출자가 수행할 수 있는 작업 | 클러스터 권한 부여 개념 |
| C. AKS 리소스 권한 부여(Azure Resource Manager) | AKS 리소스에서 kubeconfig를 끌어오기와 같은 Azure 수준의 작업을 수행할 수 있는 사람은 누구인가요? |
클러스터 구성 파일, Azure 기본 제공 역할에 대한 액세스 제한 |
| D. 클러스터 ID(클러스터 → Azure) | AKS 클러스터는 사용자를 대신하여 리소스를 관리하기 위해 Azure에서 어떻게 작동하나요? | AKS의 관리 ID |
| E. 워크로드 아이덴티티 (Pod → Azure) | Pod는 Key Vault 또는 Storage와 같은 Azure 서비스에 어떻게 인증합니까? | Microsoft Entra Workload ID 개요 |
이 문서의 나머지 부분에는 각 시나리오에 대한 간략한 방향이 있습니다.
A. Kubernetes 컨트롤 플레인 인증
Kubernetes 컨트롤 플레인 인증은 Kubernetes API 서버를 호출하는 사용자 또는 서비스 주체의 ID를 설정합니다. AKS는 다음을 지원합니다.
- Microsoft Entra ID(권장). Entra ID ID 및 그룹을 사용하여 클러스터에 로그인합니다. Microsoft Entra가 통합 설정을 구성하고 사용자를 대신하여 통합을 순환합니다. 사용하도록 설정하려면 Microsoft Entra 통합 사용을 참조하세요.
- 로컬 계정. Entra ID를 우회하는 기본 제공 클러스터 관리자 인증서입니다. 프로덕션 환경에서 로컬 계정을 사용하지 않도록 설정하는 것이 좋습니다. 로컬 계정 관리를 참조하세요.
- 외부 ID 공급자. Microsoft Entra ID 이외의 OIDC 규격 ID 공급자를 사용합니다. 외부 ID 공급자 인증을 참조하세요.
AKS가 Kubernetes API 요청을 인증하는 방법에 대한 자세한 내용은 클러스터 인증 개념을 참조하세요.
B. Kubernetes 컨트롤 플레인 권한 부여
호출자가 Kubernetes API에 인증되면 AKS는 두 모델 중 하나(또는 둘 다)를 사용하여 요청에 권한을 부여합니다.
- Kubernetes RBAC. API 서버에서 평가를 받는 네이티브 Kubernetes
Role/ClusterRole/RoleBinding모델입니다. 사용 권한은 Kubernetes 개체로 클러스터에서 존재합니다. - Microsoft Entra ID 권한 부여. AKS 권한 부여 웹후크는 Azure 역할 할당을 사용하여 Microsoft Entra ID에 권한 부여 결정을 위임합니다. Azure RBAC 역할 할당은
dataActions모든 표준 Kubernetes API 리소스에 대해 지원되며, Azure ABAC 조건이 있는 역할 할당은 사용자 지정 리소스에 대해 지원됩니다. 권한은 Microsoft Entra ID에서 중앙에서 관리되며 구독, 관리 그룹 또는 리소스 그룹 범위에서 단일 역할 할당에서 많은 클러스터를 제어할 수 있습니다.
각 모델을 사용하는 시기에 대한 병렬 비교 및 지침은 클러스터 권한 부여 개념을 참조하세요.
C. AKS 리소스 권한 부여(Azure Resource Manager)
Kubernetes API 호출에 권한을 부여하는 것 외에도 AKS 리소스 자체에 대한 Azure 수준 작업에 권한을 부여해야 합니다. 가장 일반적인 예는 클러스터 kubeconfig를 끌어올 수 있는 사용자를 제어하는 것입니다. 이 작업은 Azure RBAC를 사용하여 세분적으로 제어할 수 있는 독립 실행형 Azure Resource Manager 작업입니다. 별도로 Kubernetes API 권한 부여를 받는 것과 달리, 리소스 공급자에 대한 Microsoft.ContainerService 표준 Azure RBAC입니다.
Azure 기본 제공 역할의 클러스터 구성 파일 및 기본 제공 역할에 대한 액세스 제한을 참조하세요.
D. 클러스터 ID(클러스터 → Azure)
AKS 클러스터는 Azure 관리 ID를 사용하여 사용자를 대신하여 Azure 리소스를 작동합니다( 예: 부하 분산 장치를 만들거나 디스크를 연결하거나 Azure Container Registry에서 이미지를 끌어오기). 주요 ID는 다음과 같습니다.
- 컨트롤 플레인 ID입니다. 클러스터 컨트롤 플레인에서 클러스터에 대한 Azure 리소스를 관리하는 데 사용됩니다.
- Kubelet 아이덴티티입니다. 각 노드의 kubelet에서 Azure Container Registry와 같은 서비스에 인증하는 데 사용됩니다.
- 애드온/확장 프로그램의 식별 정보. 일부 AKS 추가 기능 및 확장은 자체 관리 ID를 사용합니다.
각 ID 유형 및 시스템 할당 ID와 사용자 할당 ID를 사용하는 방법에 대한 자세한 내용은 AKS의 관리 ID를 참조하세요.
E. 워크로드 아이덴티티 (Pod → Azure)
워크로드 ID를 사용하면 AKS 클러스터에서 실행되는 Pod가 클러스터에 비밀을 저장하지 않고 Microsoft Entra로 보호되는 Azure 서비스(예: Key Vault, Storage 또는 Cosmos DB)에 인증할 수 있습니다. AKS는 Microsoft Entra 애플리케이션 또는 사용자 할당 관리 ID에 페더레이션된 Kubernetes 서비스 계정 토큰을 프로젝션하는 Microsoft Entra 워크로드 ID를 사용합니다.
더 이상 사용되지 않는 Microsoft Entra Pod 관리 ID 를 새 워크로드에 사용하지 마세요.
의사 결정 가이드
| 목표 | 다음 문서를 사용하십시오 |
|---|---|
| Microsoft Entra ID를 사용하여 클러스터에 사용자 로그인 | Microsoft Entra 통합 사용 |
| 여러 클러스터에서 Kubernetes API에서 누가 어떤 작업을 수행할 수 있는지 제어하기 | Kubernetes API에 Microsoft Entra ID 권한 부여 사용 |
| 특정 사용자 지정 리소스 종류에 대한 액세스 제한 | Entra ID 권한 부여의 ABAC 조건 |
| Kubernetes 개체로 클러스터별, 네임스페이스별 권한 작성 | Entra 통합과 함께 Kubernetes RBAC 사용 |
| 클러스터가 ACR에서 끌어오거나 디스크를 연결하도록 허용 | AKS의 관리 ID |
| Pod가 비밀 없이 Key Vault 또는 스토리지에 도달하도록 허용 | Microsoft Entra Workload ID 개요 |
클러스터를 다운로드할 수 있는 사용자 제한 kubeconfig |
클러스터 구성 파일에 대한 액세스 제한 |
AKS 서비스 권한 참조
AKS에서 사용하는 Azure 권한(클러스터를 만드는 ID, 런타임 시 클러스터 ID, 추가 클러스터 ID 권한 및 AKS 노드 액세스)은 AKS 서비스 권한 참조를 참조하세요.
다음 단계
- 클러스터 인증 개념
- 클러스터 권한 부여 개념
- Kubernetes API에 Microsoft Entra ID 권한 부여 사용
- AKS의 관리 ID
- Microsoft Entra Workload ID 개요
Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.