AKS권한 관리 방식: K8S의 IAM처리 방식의 이해 Entra ID, Service Account 등 이해와 차이점

1. AKS 권한 관리

AKS에서는 권한 관리 시스템이 크게 두 계층으로 나뉩니다:

• Azure RBAC: Azure 구독과 리소스에 대한 권한 부여. Microsoft Entra ID(구 Azure AD) 기반 인증과 권한 관리 서비스.
• Kubernetes RBAC: Kubernetes API 리소스(네임스페이스, 리소스, 오브젝트)에 대한 세분화된 권한 정책 및 Role, RoleBinding 메커니즘.

두 시스템은 역할 및 범위를 각각 관리하나, AKS에서는 통합된 사용자 경험을 위해 Microsoft Entra ID와 Azure RBAC 통합 인증이 가능

 

2. Kubernetes IAM 처리 방식 - Kubernetes RBAC

• Kubernetes RBAC(Role-Based Access Control) 은 네임스페이스/전체 클러스터 단위로 리소스 접근 권한을 역할(Role)에 할당하며, 이 역할을 사용자, 그룹, 서비스 계정에 RoleBinding 또는 ClusterRoleBinding으로 연결해 권한을 부여합니다.
• Kubernetes Role은 네임스페이스 내 권한, ClusterRole은 클러스터 전역 권한을 뜻합니다.
• Kubernetes의 인증(Authentication)과 권한 부여(Authorization) 체계가 분리되어 있어, 인증은 Microsoft Entra ID 등 외부 시스템과 연동이 가능하며, 권한 부여는 Kubernetes RBAC가 수행합니다.

3. Microsoft Entra ID(기존 Azure AD)와 연동

• AKS는 Microsoft Entra ID로부터 사용자 및 그룹 인증을 받아, Azure RBAC와 연동하여 Azure 및 Kubernetes 리소스에 대한 권한을 관리합니다.
• Microsoft Entra ID는 SAML, OAuth, OpenID Connect 등의 표준 프로토콜을 지원하며, 2단계 인증(MFA), 조건부 액세스 정책 등 강력한 보안 기능을 제공합니다.
• 관리자는 Entra ID 내 사용자 또는 그룹을 AKS 클러스터와 연동하여 Kubernetes API 서버에 대한 인증 및 권한 관리를 일원화할 수 있습니다.
• 회사 계정(SSO)와 통합 → 별도 계정 없이 조직의 Entra ID 계정 그대로 사용
• RBAC(Role-Based Access Control)과 연결 → 예: 특정 Entra 그룹에 “개발자” 권한 부여
• 계정 lifecycle 자동 관리 (직원이 퇴사/이동 시 Entra에서 비활성화되면 K8s 접근도 자동 차단)
• MFA(다중 인증), 조건부 액세스 같은 기업 보안 정책과 연동 가능

4. Kubernetes Service Account

• Service Account는 Kubernetes 내에서 Pod가 API 서버와 통신하거나 외부 리소스에 접근할 때 사용하는 ID입니다.
• 기본적으로 Pod 생성 시 자동 부여되는 기본 서비스 계정(default service account) 이 있으나, 사용 용도에 따라 별도의 Service Account를 직접 생성하고 필요한 권한을 부여할 수 있습니다.
• AKS에서는 Service Account와 Azure Managed Identity를 연동하여, Azure 리소스에 안전하게 액세스하는 Workload Identity 패턴도 지원합니다.

5. Azure Service Principal과 Managed Identity

• Service Principal은 애플리케이션 또는 자동화 프로세스에 권한을 부여하는 Azure AD 내 ID입니다.
• Service Principal은 Secret 유출/만료 리스크가 있어, Key Vault 보관, 만료 알림·로테션 자동화가 사실상 필수.
• 다만, 최근에는 Service Principal에 OIDC(페더레이션) 를 쓰면 “비밀 없는 SP”가 가능 → 보안·감사 측면 크게 개선.
• Managed Identity는 Azure 내 서비스에 제공되는 ID로, 별도의 비밀번호/키 관리 없이 Azure 리소스 접근 권한을 부여할 수 있어 보안성이 높습니다.
• Pod 레벨 권한 위임을 위해서는 Managed Identity가 Service Account와 연결되어 Azure 리소스 접근에 사용됩니다.

6. AKS 권한 부여 과정 흐름

단계	설명
1. 사용자 인증	Microsoft Entra ID가 사용자 또는 서비스 주체 인증 수행
2. Azure RBAC 확인	인증된 주체에 대해 Azure 리소스 권한 확인
3. Azure RBAC와 Kubernetes RBAC 통합	AKS에 설정된 역할이 Entra ID 사용자에게 매핑, Kubernetes API 접근 권한 결정
4. Kubernetes API 요청	Kubernetes API 서버가 RBAC 정책에 따라 요청자 권한을 확인 후, 리소스 접근 허용 또는 거부
5. Pod Workload 권한 부여	Pod가 Azure 리소스에 접근하는 경우, 연동된 Service Account 및 Managed Identity 토큰 사용

 

7. 주요 차이점 요약

구분	Microsoft Entra ID (Azure AD)	Kubernetes Service Account	Azure Service Principal / Managed Identity
주체	사용자, 그룹, 앱 신원	Kubernetes 내 Pod, 워크로드 ID	Azure 애플리케이션/자동화 프로세스 ID
권한 대상	Azure 리소스 및 구독 권한	Kubernetes 네임스페이스 및 클러스터 리소스	Azure 리소스(스토리지, Key Vault 등) 액세스
인증	OAuth 2.0, OpenID Connect, SAML 프로토콜 지원	토큰 기반 인증 (JWT, 서비스 토큰)	OAuth 토큰, Managed Identity 토큰 자동 관리
권한 부여	Azure RBAC 역할 관리	Kubernetes Role/ClusterRole / RoleBinding	Azure RBAC 역할 할당 또는 Managed Identity 권한 부여
관리	중앙 통합 관리, 보안 정책 강화	쿠버네티스 네임스페이스별 세부 권한 관리	키 및 인증 정보 자동 갱신, 보안 강화 가능

 

8. AKS 권한 관리 방안

• 최소 권한 원칙 준수: 필요한 최소 범위 권한만 부여
• 역할 바인딩은 그룹에 우선 적용: 사용자 직접 할당을 지양
• Managed Identity 활용 권장: 비밀번호/키 관리 부담 완화
• 정기 권한 검토와 감사: Azure Monitor, Kubernetes Audit Log 활용
• Azure AD PIM(Privileged Identity Management) 활용 가능: 권한 승격 및 접근 제어 강화
• 핵심은 Entra ID 기반 RBAC로 계정을 관리하는 게 모범 사례임.(HR과 연동하여 운영/개발 계정 관리)
• Azure Managed Identity 는 주로 CI/CD 자동화에 앱/pod 워크로드에 주로 활용됨
• AKS는 Azure AD Workload Identity + User-assigned MI 조합이 표준.

 

9. 관련 문서

https://learn.microsoft.com/ko-kr/azure/aks/operator-best-practices-identity

https://learn.microsoft.com/ko-kr/azure/aks/manage-azure-rbac?tabs=azure-cli

https://learn.microsoft.com/ko-kr/entra/identity/managed-identities-azure-resources/overview