적용 대상: ✔️ AKS 자동 ✔️ AKS 표준
AKS는 5가지 고유한 시나리오에서 ID를 사용합니다. 각 시나리오는 다른 질문에 답변하고 고유한 구성 모델을 가지고 있습니다.
대부분의 프로덕션 AKS 워크로드에서 AKS Automatic은 이 문서에 설명된 동일한 AKS ID 모델을 유지하면서 ID 관련 기본값을 포함하여 프로덕션 준비 플랫폼 기준부터 시작하기 때문에 권장되는 기본값입니다.
이 문서에서는 각 시나리오를 간략하게 소개하고, 지침이 AKS 자동 및 AKS 표준에 매핑되는 방법을 설명하고, 심층 분석 설명서를 가리킵니다.
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 워크로드 ID 개요 |
AKS Automatic 및 AKS Standard의 ID 보안 태세
이 문서의 5가지 ID 시나리오는 AKS 자동 및 AKS 표준 모두에 적용됩니다. 주요 차이점은 운영 태세입니다.
- AKS 자동은 더 미리 구성된 ID 및 보안 기본값을 제공합니다.
- AKS Standard는 더 많은 수동 제어를 제공하며 더 많은 설정 선택 항목이 필요합니다.
대부분의 프로덕션 워크로드에서 AKS 자동을 기본 시작점으로 사용하고, 더 심층적인 사용자 지정 플랫폼 구성이 필요한 경우 AKS 표준을 사용합니다.
AKS 자동의 개요는 AKS(Azure Kubernetes Service) 자동 소개를 참조하세요.
AKS 자동 및 AKS 표준 ID 보안 태세 비교
| ID 영역 | AKS 자동 자세 | AKS 표준 자세 | 자세히 알아보기 |
|---|---|---|---|
| Kubernetes API 인증 | 권장 모델로 Microsoft Entra 통합을 사용하는 프로덕션 지향 기본값 | 로컬 계정 및 Entra 통합 선택 항목을 포함하여 구성 가능 | 클러스터 인증 개념 |
| Kubernetes API 권한 부여 | kubernetes 권한 부여에 대한 AZURE RBAC가 미리 구성됨 | 클러스터 구성에서 선택한 로컬 계정 우선 및 권한 부여 모델 | 클러스터 권한 부여 개념 |
| AKS 리소스 권한 부여 | AKS 리소스 작업에서 표준 Azure RBAC 모델 사용 | AKS 리소스 작업에서 표준 Azure RBAC 모델 사용 | kubeconfig 액세스 제어 |
| 클러스터 ID | 프로덕션 기준 기본값과 함께 관리 ID 모델 사용 | 운영자가 선택한 설정에서 관리 ID 모델 사용 | AKS의 관리 ID |
| 워크로드 정체성 | 워크로드 ID 및 OIDC 발급자가 미리 구성됨 | 선택 사항 및 연산자에 의해 구성됨 | 워크로드 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 자동 및 Microsoft Entra 통합부터 시작합니다.
AKS가 Kubernetes API 요청을 인증하는 방법에 대한 자세한 내용은 클러스터 인증 개념을 참조하세요.
B. Kubernetes 컨트롤 플레인 권한 부여
호출자가 Kubernetes API에 인증되면 AKS는 두 모델 중 하나(또는 둘 다)를 사용하여 요청에 권한을 부여합니다.
-
Kubernetes RBAC: API 서버에서 평가하는 네이티브 Kubernetes
RoleClusterRole및RoleBinding모델입니다. 사용 권한은 Kubernetes 개체로 클러스터에서 존재합니다. -
Microsoft Entra ID 권한 부여: AKS 권한 부여 웹후크는 Azure 역할 할당을 사용하여 권한 부여 결정을 Microsoft Entra ID에 위임합니다. Azure RBAC 역할 할당은
dataActions모든 표준 Kubernetes API 리소스에 대해 지원되며, Azure ABAC 조건이 있는 역할 할당은 사용자 지정 리소스에 대해 지원됩니다. Microsoft Entra ID 중앙에서 권한을 관리하여 구독, 관리 그룹 또는 리소스 그룹 범위에서 단일 역할 할당에서 많은 클러스터를 제어합니다.
AKS 자동에서 Kubernetes 권한 부여에 대한 Azure RBAC는 프로덕션 준비 기본 상태의 일부로 미리 구성됩니다.
각 모델을 사용하는 시기에 대한 비교 및 지침은 클러스터 권한 부여 개념을 참조하세요.
C. AKS 리소스 권한 부여(Azure Resource Manager)
Kubernetes API 호출에 권한을 부여하는 것 외에도 AKS 리소스 자체에 대한 Azure 수준 작업에 권한을 부여해야 합니다. 가장 일반적인 예는 클러스터 kubeconfig를 끌어올 수 있는 사용자를 제어하는 것입니다. 이 작업은 Azure RBAC를 사용하여 세분적으로 제어할 수 있는 독립 실행형 Azure Resource Manager 작업입니다. 이 작업은 리소스 공급자에 대해 Microsoft.ContainerService 표준 Azure RBAC를 사용하고, Kubernetes API 권한 부여와는 별개이며, AKS 자동 및 AKS 표준에도 동일한 방식으로 적용됩니다. 자세한 내용은 Azure 기본 제공 역할의 클러스터 구성 파일 및 기본 제공 역할에대한 액세스 제한을 참조하세요.
D. 클러스터 ID(클러스터 → Azure)
AKS 클러스터는 Azure 관리 ID를 사용하여 사용자를 대신하여 Azure 리소스를 작동합니다( 예: 부하 분산 장치를 만들거나 디스크를 연결하거나 Azure Container Registry에서 이미지를 끌어오기). 주요 ID는 다음과 같습니다.
- 컨트롤 플레인 ID: 클러스터 컨트롤 플레인에서 클러스터에 대한 Azure 리소스를 관리하는 데 사용됩니다.
- Kubelet ID: 각 노드의 kubelet에서 Azure Container Registry 같은 서비스에 인증하는 데 사용됩니다.
- 추가 기능/확장 ID: 일부 AKS 추가 기능 및 확장은 자체 관리 ID를 사용합니다.
AKS Automatic은 미리 구성된 프로덕션 기본값을 통해 설정 마찰을 줄이면서 동일한 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를 사용합니다.
AKS 자동은 미리 구성된 기본값으로 워크로드 ID 및 OIDC 발급자를 포함합니다. AKS Standard에서 이러한 기능은 선택 사항이며 운영자가 구성합니다.
더 이상 사용되지 않는 Microsoft Entra Pod 관리 ID 를 새 워크로드에 사용하지 마세요.
의사 결정 가이드
| 목표 | 다음 문서를 사용하십시오 |
|---|---|
| 대부분의 워크로드에 대한 프로덕션 준비 ID 기준부터 시작 | AKS 자동 소개 |
| 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 워크로드 ID 개요 |
클러스터를 다운로드할 수 있는 사용자 제한 kubeconfig |
클러스터 구성 파일에 대한 액세스 제한 |
| 기본 ID 상태를 사용하여 프로덕션 준비 클러스터 만들기 | AKS 자동 클러스터 만들기 |
AKS 서비스 권한 참조
AKS에서 사용하는 Azure 권한(클러스터를 만드는 ID, 런타임 시 클러스터 ID, 추가 클러스터 ID 권한 및 AKS 노드 액세스)은 AKS 서비스 권한 참조를 참조하세요.
관련 콘텐츠
- AKS(Azure Kubernetes Service) 자동 소개
- AKS(Azure Kubernetes Service) 자동 클러스터 만들기
- 클러스터 인증 개념
- 클러스터 권한 부여 개념
- Kubernetes API에 Microsoft Entra ID 권한 부여 사용
- AKS의 관리 ID
- Microsoft Entra 워크로드 ID 개요
Kubernetes 및 AKS 핵심 개념에 대한 자세한 내용은 다음 문서를 참조하세요.