이 문서에서는 AKS(Azure Kubernetes Service)가 Kubernetes API( 즉, 컨트롤 플레인에 연결할 수 있는 사용자)에 대한 호출자를 인증하는 방법을 설명합니다. 권장되는 Microsoft Entra ID 기반 인증 경로 및 비상 액세스를 잠그는 방법에 대해 설명합니다.
AKS가 인증된 호출자가 수행할 수 있는 작업을 평가하는 방법은 클러스터 권한 부여 개념을 참조하세요.
AKS의 다른 ID 시나리오는 다음을 참조하세요.
- 클러스터-Azure 액세스를 위한 AKS의 관리 ID(예: ACR에서 이미지 끌어 오거나 디스크 연결).
- Pod에서 Azure로의 액세스에 대한 Microsoft Entra 워크로드 ID 개요(예: Key Vault를 호출하는 워크로드와 같은 경우).
네 가지 AKS ID 시나리오 모두에 대한 방향은 AKS에 대한 액세스 및 ID 옵션을 참조하세요.
Kubernetes API 서버에 인증(컨트롤 플레인)
Microsoft Entra ID(권장)
Kubernetes 자체는 ID 디렉터리를 제공하지 않습니다. 외부 ID 공급자가 없으면, 클러스터마다 로컬 자격 증명을 관리해야 하며, 이는 확장성이 부족하고 감사에 빈틈을 만들 수 있습니다.
컨트롤 플레인에 대한 Microsoft Entra ID 인증을 사용하여 AKS 클러스터를 배포하는 것이 좋습니다. 이 통합을 통해 클러스터는 Microsoft Entra ID에 대해 들어오는 Kubernetes API 요청의 유효성을 검사하고 권한 부여 결정에 호출자의 Entra ID를 사용합니다. Microsoft Entra ID는 ID 계층을 중앙 집중화하며, 사용자 또는 그룹 상태의 변경 내용은 클러스터 액세스에 자동으로 반영되며 조건부 액세스, 다단계 인증 및 Privileged Identity Management를 사용하도록 설정합니다.
설치는 AKS 컨트롤 플레인에 대한 Microsoft Entra ID 인증 사용을 참조하세요. 다음을 참고하십시오.
- 클러스터 인증을 위해 구성된 Microsoft Entra 테넌트는 AKS 클러스터를 보유하는 구독의 테넌트여야 합니다.
- 비대화형 로그인 또는 이전
kubectl버전의 경우 플러그 인을kubelogin사용합니다.
외부 ID 공급자(미리 보기)
일부 조직에서는 Microsoft Entra ID가 아닌 OIDC 규격 ID 공급자(예: GitHub, Google Workspace, Okta 또는 자체 호스팅 IdP)를 사용하여 클러스터 사용자를 인증해야 합니다. AKS는 외부 공급자가 발급한 토큰의 유효성을 검사하도록 Kubernetes API 서버의 JWT 인증자를 구성하는 구조적 인증을 통해 이를 지원합니다.
클러스터 ID를 Microsoft Entra ID 외부에 유지해야 하는 어려운 요구 사항이 있는 경우에만 이 옵션을 사용합니다. 그렇지 않으면 조건부 액세스, 다단계 인증 및 Privileged Identity Management와 보다 풍부한 통합을 위해 Microsoft Entra ID 경로를 선호합니다.
개요는 AKS 클러스터에 대한 외부 ID 공급자 인증을 참조하세요. 설정은 AKS 구조적 인증을 사용하여 외부 ID 공급자 구성을 참조하세요.
로컬 계정 사용 중지
로컬 계정은 Microsoft Entra ID를 우회하는 기본 제공 클러스터 관리자 인증서를 사용합니다. 이 자격 증명을 나열할 수 있는 모든 호출자는 중앙 집중식 감사, 조건부 액세스 및 Privileged Identity Management를 중단하는 Entra ID를 거치지 않고 전체 클러스터 관리자 액세스를 가져옵니다. 프로덕션 환경에서는 모든 액세스가 Microsoft Entra ID를 통해 흐르도록 로컬 계정을 사용하지 않도록 설정합니다.
많은 클러스터에서 대규모로 이를 적용하려면 기본 제공 Azure Policy Azure Kubernetes Service 클러스터를 할당하려면 구독 또는 관리 그룹 범위에서 로컬 인증 방법을 사용하지 않도록 설정해야 합니다 . 정책은 로컬 계정을 사용하도록 설정하여 만들거나 업데이트한 클러스터를 감사하거나 거부합니다. AKS 관련 기본 제공 정책의 전체 목록은 AKS에 대한 Azure Policy 기본 제공 정의를 참조하세요.
자세한 내용은 AKS에서 로컬 계정 관리를 참조하세요.
클러스터 노드에 인증
SSH 액세스 모드
Kubernetes API에 인증하는 것 외에도 문제 해결을 위해 SSH를 통해 노드에 직접 인증해야 할 수도 있습니다. AKS는 클러스터 또는 노드 풀당 설정하는 세 가지 SSH 액세스 모드를 지원합니다.
-
비활성화된 SSH(미리 보기): 노드에 대한 SSH 액세스를 완전히 차단합니다. 노드 수준의 액세스가
kubectl debug또는 다른 Kubernetes 네이티브 경로만을 통해 제어되는 프로덕션에 권장됩니다. - Microsoft Entra ID 기반 SSH(미리 보기): 관리할 SSH 키 없이 Microsoft Entra ID를 사용하여 노드에 로그인합니다. 이 모드는 나머지 클러스터 인증과 일치합니다. Entra ID에서 조건부 액세스 및 다단계 인증을 상속하고, Azure RBAC 및 Privileged Identity Management를 통한 Just-In-Time 권한 상승을 지원하며, Entra ID 로그인 로그를 통해 감사를 중앙 집중화합니다.
- 로컬 사용자 SSH: 기존 SSH 키 기반 액세스. Entra ID 기반 SSH가 옵션이 아닌 경우에만 이 옵션을 사용하고 키를 정기적으로 회전합니다.
설정 및 모드별 구성 단계는 AKS 클러스터 노드에서 SSH 액세스 관리를 참조하세요.