AKS 인증 방식 비교 가이드

Azure Kubernetes Service(AKS)에서 클러스터에 안전하게 접근하고 적절한 권한을 관리하는 것은 운영 환경에서 매우 중요한 요소입니다. Azure는 조직의 요구사항과 보안 정책에 따라 선택할 수 있는 세 가지 주요 인증 방식을 제공합니다.

🔍 AKS 인증 방식 개요

AKS는 다음 세 가지 인증 방식을 지원합니다:

1. Kubernetes RBAC가 있는 로컬 계정
2. Kubernetes RBAC을 사용한 Microsoft Entra ID 인증
3. Azure RBAC을 사용한 Microsoft Entra ID 인증

1. Azure RBAC 역할 체계

인증방식에 대해서 알아보기전에 AKS 관련 Azure RBAC에 대해서 먼저 살펴보겠습니다.

AKS 리소스 관리 역할

AKS는 Azure 리소스 레벨에서 세 가지 주요 역할을 제공합니다.

AKS 내부 리소스 Azure RBAC 역할

Microsoft Entra ID 인증과 Azure RBAC을 조합한 방식에서 사용되는 네 가지 내장 역할입니다.
(더 자세한 내용은 뒷부분에서 다시 다루겠습니다.)

• Azure Kubernetes Service RBAC Cluster Admin: 클러스터 전체 관리자 권한
• Azure Kubernetes Service RBAC Admin: 네임스페이스 수준 관리자 권한
• Azure Kubernetes Service RBAC Writer: 읽기/쓰기 권한
• Azure Kubernetes Service RBAC Reader: 읽기 전용 권한

2. Kubernetes RBAC가 있는 로컬 계정

개념과 특징

로컬 계정 방식은 AKS의 기본 인증 방식으로, 클러스터 생성 시 자동으로 생성되는 관리자 자격증명을 사용합니다.
kubeconfig 파일에 클라이언트 인증서와 개인 키가 base64 인코딩되어 저장되며, 이는 쉽게 디코딩 가능하여 빠른 접근이 가능하지만 보안상 중대한 위험을 내포하고 있습니다.

초기 설정

클러스터 생성

# 기본 로컬 계정 방식으로 클러스터 생성
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--node-count 3 \
--generate-ssh-keys

관리자 로그인 절차

필수 권한 확인

자격증명을 가져오기 위해 필요한 권한:
(아래 2가지 권한 중 하나만 있어도 자격증명을 가져올 수 있고, 이보다 높은 권한(ex.기여자)도 당연히 가능합니다)

Azure Kubernetes Service 클러스터 관리 역할

• RBAC 권한: Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action

Azure Kubernetes Service 클러스터 사용자 역할

• RBAC 권한: Microsoft.ContainerService/managedClusters/listClusterUserCredential/action

자격증명 가져오기

az aks get-credentials \
--resource-group myResourceGroup \
--name myAKSCluster \
--admin

사용자 권한 관리

개별 사용자에게 제한된 권한을 부여하려면 수동으로 인증서를 생성하고 Kubernetes RBAC을 구성해야 합니다.

전체 과정 요약

로컬 계정 인증 방식에서 사용자별 권한 관리는 다음 3단계로 진행됩니다:

1. 인증서 생성 → 개발자용 클라이언트 인증서와 개인 키 생성
2. RBAC 설정 → Kubernetes RoleBinding으로 권한 정의
3. Kubeconfig 배포 → 인증서가 포함된 kubeconfig 파일을 개발자에게 전달

이 방식은 Azure CLI 로그인 없이도 독립적으로 클러스터에 접근할 수 있지만, 사용자가 추가될 때마다 수동 작업이 필요합니다.

인증서 생성 및 RBAC 설정

# 사용자 인증서 생성
openssl genrsa -out developer1.key 2048
openssl req -new -key developer1.key -out developer1.csr \
-subj "/CN=developer1"

# CSR 리소스 생성 (developer1-csr.yaml)
cat <<EOF > developer1-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: developer1
spec:
request: $(cat developer1.csr | base64 | tr -d '\n')
signerName: kubernetes.io/kube-apiserver-client
usages:
- client auth
EOF

# 클러스터에서 CSR 승인 후 인증서 추출
kubectl apply -f developer1-csr.yaml
kubectl certificate approve developer1
kubectl get csr developer1 -o jsonpath='{.status.certificate}' | base64 -d > developer1.crt

# RoleBinding 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer1-binding
  namespace: dev-namespace
subjects:
  - kind: User
    name: developer1
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit
  apiGroup: rbac.authorization.k8s.io

Kubeconfig 설정 및 배포

인증서 생성 후 개발자가 사용할 kubeconfig를 설정하고 배포하는 과정입니다:

# 생성한 인증서를 사용하여 개발자용 kubeconfig 설정
kubectl config set-credentials developer1 \
  --client-certificate=developer1.crt \
  --client-key=developer1.key \
  --embed-certs=true

kubectl config set-context developer1-context \
  --cluster=<your-cluster-name> \
  --namespace=developer1-namespace \
  --user=developer1

# 개발자에게 kubeconfig 파일 전달
kubectl config view --minify --flatten > developer1-kubeconfig.yaml

장단점 분석

사용 권장 시나리오

• 개발 및 테스트 환경: 빠른 프로토타이핑
• 개인 학습 환경: Kubernetes 기능 학습

3. Kubernetes RBAC을 사용한 Microsoft Entra ID 인증

개념과 특징

Microsoft Entra ID를 통한 인증과 Kubernetes RBAC을 통한 인가를 조합한 방식입니다. 중앙집중식 ID 관리의 이점을 활용하면서 Kubernetes 네이티브한 권한 제어의 유연성을 제공합니다.

인증 흐름도

초기 설정

필수 권한 확인

자격증명 다운로드를 위해 필요한 최소 권한 (다음 중 하나):

• Azure Kubernetes Service 클러스터 사용자 역할
• Azure Kubernetes Service 클러스터 관리 역할

클러스터 생성

# 클러스터 생성 시 관리자 그룹 지정 + 로컬 계정 비활성화
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-aad \
--aad-admin-group-object-ids <admin-group-object-id> \
--disable-local-accounts \
--generate-ssh-keys

로컬 계정 비활성화 (--disable-local-accounts)

비활성화가 필요한 이유

로컬 계정은 다음과 같은 보안 취약점을 가지고 있습니다:

• 토큰 만료 없음: 클라이언트 인증서가 영구적으로 유효하여 한 번 노출되면 지속적인 위험 존재
• 중앙집중식 관리 불가: 개별 kubeconfig 파일로 관리되어 사용자 접근 제어가 어려움
• 감사 추적 제한: 누가 언제 어떤 작업을 했는지 추적하기 어려움
• 즉시 권한 취소 불가: 퇴사자나 권한 변경 시 즉시 접근 차단이 어려움
• 파일 기반 보안 위험: kubeconfig 파일이 버전 관리 시스템이나 공유 저장소에 노출될 위험

비활성화 후 확인

로컬 계정 비활성화 후에는 관리자 인증서로 접근을 시도해도 실패해야 합니다:

# 이 명령은 실패해야 함 (정상적인 동작)
az aks get-credentials \
--resource-group myResourceGroup \
--name myAKSCluster \
--admin

# 오류 메시지 예시:
# "Getting static credential isn't allowed because this cluster is set to disable local accounts."

kubelogin 플러그인 설치

# Azure CLI와 함께 설치
az aks install-cli

# 수동 설치 (필요시)
curl -LO https://github.com/Azure/kubelogin/releases/latest/download/kubelogin-linux-amd64.zip

사용자 권한 관리 방법

Entra ID 그룹 생성 및 관리

개발팀별로 AKS 클러스터에 대한 접근 권한을 효율적으로 관리하기 위해 Entra ID 그룹을 생성하고 사용자를 그룹에 추가하는 방법입니다. 이 방법은 개별 사용자 권한 관리보다 훨씬 효율적이며, 팀 구성 변경 시에도 유연하게 대응할 수 있습니다.

# 개발팀 그룹 생성
az ad group create \
--display-name "AKS-Developers" \
--mail-nickname "aks-developers"

# 사용자를 그룹에 추가
az ad group member add \
--group "AKS-Developers" \
--member-id <user-object-id>

# 그룹 Object ID 확인
az ad group show \
--group "AKS-Developers" \
--query objectId -o tsv

Azure 역할 할당

# 그룹에 클러스터 사용자 역할 부여
az role assignment create \
--assignee-object-id <group-object-id> \
--role "Azure Kubernetes Service Cluster User Role" \
--scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>

Kubernetes RBAC 구성

# ClusterRole 정의
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-role
rules:
  - apiGroups: ["", "apps", "batch", "extensions"]
    resources: ["pods", "services", "deployments", "configmaps", "secrets"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["pods/log", "pods/exec"]
    verbs: ["get", "list"]
---
# ClusterRoleBinding 정의
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developer-binding
subjects:
  - kind: Group
    name: "<Group-Object-ID>"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

사용자 접근 절차

# 1. Azure 로그인
az login
az account set --subscription <subscription-id>

# 2. kubeconfig 다운로드
az aks get-credentials \
--resource-group myResourceGroup \
--name myAKSCluster \
--overwrite-existing

# 3. kubelogin 변환
kubelogin convert-kubeconfig -l azurecli

# 4. 클러스터 접근
kubectl get pods

kubelogin 변환을 하지 않을 경우 아래와 같이 kubectl 명령 입력 시 인증을 한번 더 거쳐야 하는 불편함이 있다.

네임스페이스 기반 권한 분리

# 네임스페이스별 Role 예시
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: dev-team-role
rules:
  - apiGroups: ["", "apps"]
    resources: ["*"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: development
subjects:
  - kind: Group
    name: "<Dev-Team-Group-Object-ID>"
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-team-role
  apiGroup: rbac.authorization.k8s.io

장단점 분석

4. Azure RBAC을 사용한 Microsoft Entra ID 인증

개념과 특징

Azure RBAC 시스템을 Kubernetes 리소스까지 확장한 방식입니다. Kubernetes RBAC 대신 Azure의 4가지 내장 역할을 사용하여 간단하면서도 일관된 권한 관리를 제공합니다.

클러스터 생성

# Azure RBAC 활성화 + 로컬 계정 비활성화
az aks create \
--resource-group myResourceGroup \
--name myAKSCluster \
--enable-aad \
--aad-admin-group-object-ids <admin-group-object-id> \
--enable-azure-rbac \
--disable-local-accounts \
--generate-ssh-keys

Azure RBAC 역할 매트릭스

권한 할당 방법

사용자별 권한 할당

# 개별 사용자에게 Writer 권한 부여
az role assignment create \
  --assignee <user-principal-name> \
  --role "Azure Kubernetes Service RBAC Writer" \
  --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>

# 그룹에 Reader 권한 부여
az role assignment create \
  --assignee-object-id <group-object-id> \
  --role "Azure Kubernetes Service RBAC Reader" \
  --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>

네임스페이스 수준 권한 할당

# 특정 네임스페이스에 대한 Admin 권한
az role assignment create \
  --assignee <user-principal-name> \
  --role "Azure Kubernetes Service RBAC Admin" \
  --scope /subscriptions/<subscription-id>/resourcegroups/<resource-group>/providers/Microsoft.ContainerService/managedClusters/<cluster-name>/namespaces/<namespace-name>

역할별 권한 상세 분석

사용자 접근 절차

# 1. Azure 로그인
az login
az account set --subscription <subscription-id>

# 2. kubeconfig 다운로드
az aks get-credentials \
--resource-group myResourceGroup \
--name myAKSCluster \
--overwrite-existing

# 3. kubelogin 변환 (Azure RBAC에서도 필요)
kubelogin convert-kubeconfig -l azurecli

# 4. 클러스터 접근
kubectl get pods

장단점 분석

5. 인증 방식에 따른 비교

✨ 결론

조직의 보안 요구사항, 팀 규모, 운영 복잡도를 종합적으로 고려하여 AKS 인증 방식을 선택하는 것이 중요합니다.

이러한 인증 전략을 통해 보안성과 운영 효율성을 모두 확보할 수 있으며, 궁극적으로 안전한 AKS 클러스터 환경을 구축할 수 있습니다.

이 포스트는 2025년 8월 기준 최신 Azure 공식 문서를 바탕으로 작성되었습니다. 최신 정보는 Microsoft Learn - AKS에서 액세스 및 ID 옵션에서 확인하실 수 있습니다.