Azure Kubernetes Service의 Microsoft Entra ID를 통해 Kubernetes 역할 기반 액세스 제어 사용

아티클
08/03/2024

사용자 인증을 위해 Microsoft Entra ID를 사용하도록 AKS(Azure Kubernetes Service)를 구성할 수 있습니다. 이 구성에서는 Microsoft Entra 인증 토큰을 사용하여 AKS 클러스터에 로그인합니다. 인증되면 기본 제공 Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어)를 사용하여 사용자의 ID 또는 그룹 멤버 자격을 기반으로 네임스페이스 및 클러스터 리소스에 대한 액세스를 관리할 수 있습니다.

이 문서는 다음을 수행하는 방법을 보여줍니다.

Microsoft Entra 그룹 멤버 자격을 기반으로 하는 AKS 클러스터의 Kubernetes RBAC를 사용하여 액세스를 제어합니다.
Microsoft Entra ID에서 예제 그룹과 사용자를 만듭니다.
AKS 클러스터에 Role 및 RoleBinding을 만들어서 리소스를 만들고 볼 수 있는 적절한 권한을 부여합니다.

시작하기 전에

Microsoft Entra 통합이 사용하도록 설정된 기존 AKS 클러스터가 있습니다. 이 구성을 사용하는 AKS 클러스터가 필요한 경우 AKS와 Microsoft Entra ID 통합을 참조하세요.
Kubernetes RBAC는 AKS 클러스터를 만드는 동안 기본적으로 사용하도록 설정됩니다. Microsoft Entra 통합과 Kubernetes RBAC를 사용하여 클러스터를 업그레이드하려면 기존 AKS 클러스터에서 Microsoft Entra 통합을 사용하도록 설정합니다.
Azure CLI 버전 2.0.61 이상이 설치 및 구성되어 있어야 합니다. az --version을 실행하여 버전을 찾습니다. 설치 또는 업그레이드해야 하는 경우 Azure CLI 설치를 참조하세요.
Terraform을 사용하는 경우 Terraform 버전 2.99.0 이상을 설치합니다.

Azure Portal 또는 Azure CLI를 사용하여 Kubernetes RBAC와 Microsoft Entra 통합이 사용하도록 설정되어 있는지 확인합니다.

Azure Portal
Azure CLI

Azure Portal를 사용하여 확인하려면 다음을 수행합니다.

Azure Portal에 로그인하고 AKS 클러스터 리소스로 이동합니다.
서비스 메뉴의 설정에서 클러스터 구성을 선택합니다.
인증 및 권한 부여 섹션에서 Kubernetes RBAC를 사용한 Microsoft Entra 인증 옵션이 선택되어 있는지 확인합니다.

Azure CLI az aks show 명령을 사용하여 확인할 수 있습니다. myResourceGroup 값을 AKS 클러스터 리소스를 호스트하는 리소스 그룹 이름으로 바꾸고 myAKSCluster를 AKS 클러스터의 실제 이름으로 바꿉니다.

az aks show --resource-group myResourceGroup --name myAKSCluster

사용하도록 설정된 경우 출력에는 enableAzureRbac의 값이 false라고 표시됩니다.

Microsoft Entra ID에서 데모 그룹 만들기

이 문서에서는 Kubernetes RBAC와 Microsoft Entra ID에서 클러스터 리소스에 대한 액세스를 제어하는 방법을 보여 주기 위한 두 가지 사용자 역할을 만들어 보겠습니다. 다음 두 가지 예제 역할이 사용됩니다.

애플리케이션 개발자
- appdev 그룹에 속한 aksdev라는 사용자
사이트 안정성 엔지니어
- opssre 그룹에 속한 akssre라는 사용자

프로덕션 환경에서는 Microsoft Entra 테넌트 내에서 기존 사용자와 그룹을 사용할 수 있습니다.

먼저 az aks show 명령을 사용하여 AKS 클러스터의 리소스 ID를 가져옵니다. 그런 다음, 다른 명령에서 참조될 수 있도록 AKS_ID라는 변수에 리소스 ID를 할당합니다.
```
AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)
```
az ad group create 명령을 사용하여 애플리케이션 개발자를 위한 Microsoft Entra ID의 첫 번째 예제 그룹을 만듭니다. 다음 예제는 appdev라는 그룹을 만듭니다.
```
APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
```
az role assignment create 명령을 사용하여 appdev 그룹에 대한 Azure 역할 할당을 만듭니다. 이 할당을 사용하면 그룹의 모든 멤버가 kubectl을 사용하여 AKS 클러스터에 'Azure Kubernetes Service 클러스터 사용자' Role을 부여하는 방식으로 클러스터와 상호 작용할 수 있습니다.
```
az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID
```

팁

Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.와 같은 오류가 발생할 경우 Microsoft Entra 그룹 개체 ID가 디렉터리를 통해 전파되기를 몇 초간 기다렸다가 az role assignment create 명령을 다시 실행합니다.

이름이 opssre인 두 번째 SRE 예제 그룹을 만듭니다.

OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)

Azure 역할 할당을 만들어 그룹 멤버에게 'Azure Kubernetes Service 클러스터 사용자' Role을 부여합니다.

az role assignment create \
  --assignee $OPSSRE_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID

Microsoft Entra ID에서 데모 사용자 만들기

이제 애플리케이션 개발자 및 SRE용으로 Microsoft Entra ID에서 만든 두 가지 예제 그룹을 사용하여 두 예제 사용자를 만들어 보겠습니다. 이 문서의 끝 부분에서 Kubernetes RBAC 통합을 테스트하려면 해당 계정을 사용하여 AKS 클러스터에 로그인합니다.

애플리케이션 개발자에 대한 사용자 계정 이름과 암호를 설정합니다.

애플리케이션 개발자에 대한 UPN(사용자 계정 이름)과 암호를 설정합니다. UPN에는 테넌트의 확인된 도메인 이름이 포함되어야 합니다(예: aksdev@contoso.com).

다음 명령은 UPN을 묻는 메시지를 표시하고, 이후 명령에서 사용할 수 있도록 AAD_DEV_UPN으로 설정합니다.

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

다음 명령은 암호를 묻는 메시지를 표시하고, 이후 명령에서 사용할 수 있도록 AAD_DEV_PW로 설정합니다.

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

사용자 계정 만들기

az ad user create 명령을 사용하여 Microsoft Entra ID에서 첫 번째 사용자 계정을 만듭니다. 다음 예제는 AAD_DEV_UPN 및 AAD_DEV_PW의 값을 사용하여 표시 이름이 AKS Dev인 사용자와 UPN, 안전한 암호를 만듭니다.

AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

az ad group member add 명령을 사용하여 이전 섹션에서 만든 appdev 그룹에 사용자를 추가합니다.

az ad group member add --group appdev --member-id $AKSDEV_ID

SRE의 UPN 및 암호를 설정합니다. UPN에는 테넌트의 확인된 도메인 이름이 포함되어야 합니다(예: akssre@contoso.com). 다음 명령은 UPN을 묻는 메시지를 표시하고, 이후 명령에서 사용할 수 있도록 AAD_SRE_UPN으로 설정합니다.

echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN

다음 명령은 암호를 묻는 메시지를 표시하고, 이후 명령에서 사용할 수 있도록 AAD_SRE_PW로 설정합니다.

echo "Please enter the secure password for SREs: " && read AAD_SRE_PW

두 번째 사용자 계정을 만듭니다. 다음 예제는 AAD_SRE_UPN 및 AAD_SRE_PW의 값을 사용하여 표시 이름이 AKS SRE인 사용자와 UPN, 안전한 암호를 만듭니다.

# Create a user for the SRE role
AKSSRE_ID=$(az ad user create \
  --display-name "AKS SRE" \
  --user-principal-name $AAD_SRE_UPN \
  --password $AAD_SRE_PW \
  --query id -o tsv)

# Add the user to the opssre Azure AD group
az ad group member add --group opssre --member-id $AKSSRE_ID

app devs용 AKS 클러스터 리소스 만들기

Microsoft Entra 그룹, 사용자 및 Azure 역할 할당을 만들었습니다. 이제 서로 다른 그룹이 특정 리소스에 액세스할 수 있도록 AKS 클러스터를 구성해 보겠습니다.

az aks get-credentials 명령을 사용하여 클러스터 관리자 자격 증명을 가져옵니다. 다음 섹션 중 하나에서 일반 사용자 클러스터 자격 증명을 가져와서 Microsoft Entra 인증 흐름이 작동하는지 확인합니다.

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

kubectl create namespace 명령을 사용하여 AKS 클러스터에서 네임스페이스를 만듭니다. 다음 예제는 dev라는 네임스페이스를 만듭니다.

kubectl create namespace dev

참고 항목

Kubernetes에서 Roles는 부여할 권한을 정의하고 RoleBindings는 이를 원하는 사용자 또는 그룹에 적용합니다. 이러한 할당은 주어진 네임스페이스 또는 전체 클러스터에 적용될 수 있습니다. 자세한 내용은 Kubernetes RBAC 권한 부여 사용을 참조하세요.

Kubernetes RBAC 바인딩 권한을 부여한 사용자가 동일한 Microsoft Entra 테넌트에 있는 경우 UPN(userPrincipalName)에 따라 권한을 할당합니다. 사용자가 다른 Microsoft Entra 테넌트에 있는 경우에는 대신 objectId 속성을 쿼리하고 사용합니다.

네임스페이스에 대한 전체 권한을 부여하는 dev 네임스페이스의 Role을 만듭니다. 프로덕션 환경에서는 다른 사용자 또는 그룹에 대해 보다 세부적인 사용 권한을 지정할 수 있습니다. role-dev-namespace.yaml이라는 파일을 만들고, 다음 YAML 매니페스트를 붙여넣습니다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

kubectl apply 명령을 사용하여 Role을 만들고 YAML 매니페스트의 파일 이름을 지정합니다.

kubectl apply -f role-dev-namespace.yaml

az ad group show 명령을 사용하여 appdev 그룹의 리소스 ID를 가져옵니다. 이 그룹은 다음 단계에서 RoleBinding의 주체로 설정됩니다.

az ad group show --group appdev --query id -o tsv

appdev 그룹의 RoleBinding을 만들어 네임스페이스 액세스 시 이전에 만든 Role을 사용합니다. rolebinding-dev-namespace.yaml라는 파일을 만들고 다음 YAML 매니페스트를 붙여 넣습니다. 마지막 줄에서 groupObjectId를 이전 명령의 그룹 개체 ID 출력으로 바꿉니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

팁

단일 사용자에 대한 RoleBinding을 만들려면 위 샘플에서 kind: User를 지정하고 groupObjectId를 UPN(사용자 계정 이름)으로 바꿉니다.

kubectl apply 명령을 사용하여 RoleBinding을 만들고 YAML 매니페스트의 파일 이름을 지정합니다.

kubectl apply -f rolebinding-dev-namespace.yaml

SRE에 대한 AKS 클러스터 리소스 만들기

이제 이전 단계를 반복하여 SRE에 대한 네임스페이스, Role, RoleBinding을 만듭니다.

kubectl create namespace 명령을 사용하여 sre의 네임스페이스를 만듭니다.

kubectl create namespace sre

role-sre-namespace.yaml이라는 파일을 만들고, 다음 YAML 매니페스트를 붙여넣습니다.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

kubectl apply 명령을 사용하여 Role을 만들고 YAML 매니페스트의 파일 이름을 지정합니다.

kubectl apply -f role-sre-namespace.yaml

az ad group show 명령을 사용하여 opssre 그룹의 리소스 ID를 가져옵니다.

az ad group show --group opssre --query id -o tsv

opssre 그룹에 대한 RoleBinding을 만들어서 네임스페이스 액세스에 대해 이전에 만든 역할을 사용합니다. rolebinding-sre-namespace.yaml라는 파일을 만들고 다음 YAML 매니페스트를 붙여 넣습니다. 마지막 줄에서 groupObjectId를 이전 명령의 그룹 개체 ID 출력으로 바꿉니다.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-access
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
- kind: Group
  namespace: sre
  name: groupObjectId

kubectl apply 명령을 사용하여 RoleBinding을 만들고 YAML 매니페스트의 파일 이름을 지정합니다.

kubectl apply -f rolebinding-sre-namespace.yaml

Microsoft Entra ID를 사용하여 클러스터 리소스와 상호 작용

이제 AKS 클러스터에서 리소스를 만들고 관리할 때 예상되는 권한을 테스트해 보겠습니다. 이 예제에서는 할당된 사용자의 네임스페이스에서 Pod를 예약 및 확인하고, 할당된 네임스페이스 외부에서 Pod를 예약 및 확인합니다.

az aks get-credentials 명령을 사용하여 kubeconfig 컨텍스트를 초기화합니다. 이전 섹션에서는 클러스터 관리자 자격 증명을 사용하여 컨텍스트를 설정했습니다. 관리 사용자는 Microsoft Entra 로그인 프롬프트를 무시합니다. --admin 매개 변수를 사용하지 않으면 Microsoft Entra ID를 사용하여 모든 요청을 인증해야 하는 사용자 컨텍스트가 적용됩니다.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

dev 네임스페이스에서 kubectl run 명령을 사용하여 기본 NGINX Pod를 예약합니다.

kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

문서의 시작 부분에서 로그인 프롬프트로 만든 자체 appdev@contoso.com 계정의 자격 증명을 입력합니다. 성공적으로 로그인되면 이후 kubectl 명령에 대해 계정 토큰이 캐시됩니다. 다음 예제 출력과 같이 NGINX이 성공적으로 예약됩니다.

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.

pod/nginx-dev created

kubectl get pods 명령을 사용하여 dev 네임스페이스에서 Pod를 확인합니다.

kubectl get pods --namespace dev

NGINX Pod의 상태가 '실행 중'인지 확인합니다. 출력은 아래 나와 있는 출력과 유사합니다.

$ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

할당된 네임스페이스 외부에서 클러스터 리소스 만들기 및 보기

dev 네임스페이스 외부에서 Pod를 확인해 봅니다. kubectl get pods 명령을 다시 사용하여 이번에는 --all-namespaces를 확인합니다.

kubectl get pods --all-namespaces

사용자의 그룹 멤버 자격에는 다음 예제 출력과 같이 이 작업을 허용하는 Kubernetes Role이 없습니다.

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

동일한 방식으로 sre 네임스페이스와 같은 다른 네임스페이스의 Pod를 예약해 봅니다. 다음 예제 출력과 같이 사용자의 그룹 멤버 자격은 권한을 부여하는 Kubernetes Role 및 RoleBinding과 일치하지 않습니다.

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

AKS 클러스터 리소스에 대한 SRE 액세스 테스트

Microsoft Entra 그룹 멤버 자격 및 Kubernetes RBAC가 서로 다른 사용자와 그룹 간에 올바르게 작동하는지 확인하려면 opssre 사용자로 로그인되어 있을 때 이전 명령을 사용해 보세요.

aksdev 사용자에게 이전에 캐시된 인증 토큰을 지우는 az aks get-credentials 명령을 사용하여 kubeconfig 컨텍스트를 초기화합니다.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

할당된 sre 네임스페이스에서 Pod를 예약하고 확인합니다. 메시지가 표시되면 문서의 시작 부분에서 만든 자체 opssre@contoso.com 자격 증명을 사용하여 로그인합니다.

kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre

다음 예제 출력과 같이 성공적으로 Pod을 만들고 확인할 수 있습니다.

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

3. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.

pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

할당된 SRE 네임스페이스의 외부에서 Pod을 확인하거나 예약해 봅니다.

kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

다음 예제 출력에 표시된 것처럼 kubectl 명령은 실패합니다. 사용자의 그룹 멤버 자격과 Kubernetes Role 및 RoleBinding은 다른 네임스페이스에서 리소스를 만들거나 관리할 수 있는 권한을 부여하지 않습니다.

$ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

리소스 정리

이 문서에서는 AKS 클러스터의 리소스와 Microsoft Entra ID의 사용자 및 그룹을 만들었습니다. 모든 리소스를 정리하려면 다음 명령을 실행합니다.

# Get the admin kubeconfig context to delete the necessary cluster resources.

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

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

다음 단계

Kubernetes 클러스터를 보호하는 방법에 관한 자세한 내용은 AKS에 대한 액세스 및 ID 옵션을 참조하세요.
ID 및 리소스 제어에 관한 모범 사례는 AKS의 인증 및 권한 부여 모범 사례를 참조하세요.

다음을 통해 공유