Windows Server용 Microsoft Entra ID 및 Kubernetes RBAC를 사용하여 액세스 제어
적용 대상: Azure Local 22H2의 AKS, Windows Server의 AKS
사용자 인증을 위해 Microsoft Entra ID를 사용하도록 AKS(Azure Kubernetes Service)를 구성할 수 있습니다. 이 구성에서는 Microsoft Entra 인증 토큰을 사용하여 Kubernetes 클러스터에 로그인합니다. 인증되면 기본 제공 Kubernetes RBAC(Kubernetes 역할 기반 액세스 제어)를 사용하여 사용자의 ID 또는 그룹 멤버 자격을 기반으로 네임스페이스 및 클러스터 리소스에 대한 액세스를 관리할 수 있습니다.
이 문서에서는 AKS Arc의 Microsoft Entra 그룹 멤버 자격을 기반으로 Kubernetes 클러스터에서 Kubernetes RBAC를 사용하여 액세스를 제어하는 방법을 설명합니다. Microsoft Entra ID에서 데모 그룹 및 사용자를 만듭니다. 그런 다음 클러스터에서 역할 및 역할 바인딩을 만들어 리소스를 만들고 볼 수 있는 적절한 권한을 부여합니다.
필수 조건
Microsoft Entra ID를 사용하여 Kubernetes RBAC를 설정하기 전에 다음 필수 구성 요소가 필요합니다.
- AKS Arc에서 만든 Kubernetes 클러스터입니다. 클러스터를 설정해야 하는 경우 Windows Admin Center 또는 PowerShell을 사용하여 AKS를 배포하기 위한 지침을 참조하세요.
- Azure Arc 연결. Kubernetes 클러스터에 대한 Azure Arc 연결이 있어야 합니다. Azure Arc를 사용하도록 설정하는 방법에 대한 자세한 내용은 Azure 로컬 클러스터의 Azure Kubernetes Service를 Azure Arc 지원 Kubernetes에 연결합니다.
- 다음 명령줄 도구에 액세스해야 합니다.
-
Azure CLI 및 connectedk8s 확장. Azure CLI는 Azure 리소스를 만들고 관리하는 데 사용되는 명령 집합입니다. Azure CLI가 있는지 확인하려면 명령줄 도구를 열고 다음
az -v
을 입력합니다. 또한 Kubernetes 클러스터에 대한 채널을 열기 위해 connectedk8s 확장을 설치합니다. 설치 지침은 Azure CLI를 설치하는 방법을 참조하세요. -
Kubectl. 이 Kubernetes 명령줄 도구를 사용하면 Kubernetes 클러스터를 대상으로 하는 명령을 실행할 수 있습니다. kubectl을 설치했는지 확인하려면 명령 프롬프트를 열고 다음
kubectl version --client
을 입력합니다. kubectl 클라이언트 버전이 버전 v1.24.0 이상인지 확인합니다. 설치 지침은 kubectl을 참조 하세요. - PowerShell 및 AksHci PowerShell 모듈. PowerShell은 명령줄 셸, 스크립팅 언어 및 구성 관리 프레임워크로 구성된 플랫폼 간 태스크 자동화 솔루션입니다. AKS Arc를 설치한 경우 AksHci PowerShell 모듈에 액세스할 수 있습니다.
- 명령을 사용하여
az connectedk8s proxy
프록시 모드로 어디서나 Kubernetes 클러스터에 액세스하려면 Azure Arc 지원 Kubernetes 클러스터 사용자 역할 권한에 포함된 Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action이 필요합니다. 한편, 온보딩 프로세스를 수행하는 에이전트와 컴퓨터가 Azure Arc 지원 Kubernetes 네트워크 요구 사항의 네트워크 요구 사항을 충족하는지 확인해야 합니다.
-
Azure CLI 및 connectedk8s 확장. Azure CLI는 Azure 리소스를 만들고 관리하는 데 사용되는 명령 집합입니다. Azure CLI가 있는지 확인하려면 명령줄 도구를 열고 다음
선택적 첫 번째 단계
구성원이 포함된 Microsoft Entra 그룹이 아직 없는 경우 그룹을 만들고 일부 구성원을 추가하여 이 문서의 지침을 따를 수 있습니다.
Microsoft Entra ID 및 Kubernetes RBAC로 작업하는 방법을 보여 주려면 Kubernetes RBAC 및 Microsoft Entra ID가 클러스터 리소스에 대한 액세스를 제어하는 방법을 보여 주는 데 사용할 수 있는 애플리케이션 개발자를 위한 Microsoft Entra 그룹을 만들 수 있습니다. 프로덕션 환경에서는 Microsoft Entra 테넌트 내에서 기존 사용자와 그룹을 사용할 수 있습니다.
Microsoft Entra ID에서 데모 그룹 만들기
먼저 명령을 사용하여 애플리케이션 개발자를 위해 테넌트에서 Microsoft Entra ID로 az ad group create
그룹을 만듭니다. 다음 예제에서는 Azure 테넌트에 로그인하라는 메시지를 표시한 다음 appdev라는 그룹을 만듭니다.
az login
az ad group create --display-name appdev --mail-nickname appdev
그룹에 사용자 추가
애플리케이션 개발자를 위한 Microsoft Entra ID로 만든 예제 그룹을 사용하여 그룹에 사용자를 appdev
추가합니다. 이 사용자 계정을 사용하여 AKS 클러스터에 로그인하고 Kubernetes RBAC 통합을 테스트합니다.
명령을 사용하여 이전 섹션에서 만든 appdev 그룹에 사용자를 추가합니다az ad group member add
. 세션을 종료하는 경우 .를 사용하여 az login
Azure에 다시 연결합니다.
$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID
Microsoft Entra 그룹의 AKS 클러스터 리소스에 사용자 지정 Kubernetes RBAC 역할 바인딩 만들기
Microsoft Entra 그룹이 클러스터에 액세스할 수 있도록 AKS 클러스터를 구성합니다. 그룹 및 사용자를 추가하려면 Microsoft Entra ID에서 데모 그룹 만들기를 참조하세요.
다음 명령을 사용하여 클러스터 관리자 자격 증명을 가져옵니다.
Get-AksHciCredential
Get-AksHciCredential -name <name-of-your-cluster>
명령을 사용하여 Kubernetes 클러스터에 네임스페이스를 만듭니다
kubectl create namespace
. 다음 예에서는dev
라는 네임스페이스를 만듭니다.kubectl create namespace dev
Kubernetes 에서 역할은 부여할 권한을 정의하고 RoleBindings는 원하는 사용자 또는 그룹에 권한을 적용합니다. 이러한 할당은 지정된 네임스페이스 또는 전체 클러스터에 적용할 수 있습니다. 자세한 내용은 Kubernetes RBAC 권한 부여 사용을 참조하세요.
개발 네임스페이스에 대한 역할을 만듭니다. 이 역할은 네임스페이스에 대한 모든 권한을 부여합니다. 프로덕션 환경에서는 다른 사용자 또는 그룹에 대해 더 세부적인 권한을 지정할 수 있습니다.
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
역할을 만들고 YAML 매니페스트의 파일 이름을 지정합니다.kubectl apply -f role-dev-namespace.yaml
명령을 사용하여
az ad group show
appdev 그룹의 리소스 ID를 가져옵니다. 이 그룹은 다음 단계에서 RoleBinding의 주체로 설정됩니다.az ad group show --group appdev --query objectId -o tsv
이
az ad group show
명령은 다음과 같이 사용하는 값을 반환합니다groupObjectId
.38E5FA30-XXXX-4895-9A00-050712E3673A
rolebinding-dev-namespace.yaml이라는 파일을 만들고 다음 YAML 매니페스트를 복사하여 붙여넣습니다. appdev 그룹이 네임스페이스 액세스에 역할을 사용할 수 있도록 하는 역할 바인딩을
role-dev-namespace
설정합니다. 마지막 줄에서 명령으로 생성된groupObjectId
그룹 개체 ID로 바꿉az ad group show
니다.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을 만들려면 샘플에서 UPN(사용자 계정 이름)을 지정
kind: User
하고 바꿉groupObjectId
니다.명령을 사용하여 RoleBinding을
kubectl apply
만들고 YAML 매니페스트의 파일 이름을 지정합니다.kubectl apply -f rolebinding-dev-namespace.yaml
rolebinding.rbac.authorization.k8s.io/dev-user-access created
AKS 클러스터 리소스에 기본 제공 Kubernetes RBAC 역할 사용
Kubernetes는 기본 제공 사용자 연결 역할도 제공합니다. 이러한 기본 제공 역할은 다음과 같습니다.
- 슈퍼 사용자 역할(클러스터 관리자)
- ClusterRoleBindings를 사용하여 클러스터 전체에 부여할 역할
- RoleBindings(관리자, 편집, 보기)를 사용하여 특정 네임스페이스 내에서 부여할 역할
기본 제공 Kubernetes RBAC 역할에 대한 자세한 내용은 Kubernetes RBAC 사용자 연결 역할을 참조하세요.
사용자 연결 역할
기본 ClusterRole | 기본 ClusterRoleBinding | 설명 |
---|---|---|
cluster-admin | system:masters 그룹 | 모든 리소스에 대해 모든 작업을 수행할 수 있도록 슈퍼 사용자 액세스를 허용합니다. ClusterRoleBinding에서 사용되는 경우 이 역할은 클러스터 및 모든 네임스페이스의 모든 리소스를 완전히 제어합니다. RoleBinding에서 사용되는 경우 네임스페이스 자체를 포함하여 역할 바인딩 네임스페이스의 모든 리소스를 완전히 제어할 수 있습니다. |
관리자 | None | 역할 바인딩을 사용하여 네임스페이스 내에서 부여할 관리자 액세스를 허용합니다. 역할 바인딩에서 사용되는 경우 네임스페이스 내에서 역할 및 역할 바인딩을 만드는 기능을 포함하여 네임스페이스의 대부분의 리소스에 대한 읽기/쓰기 액세스를 허용합니다. 이 역할은 리소스 할당량 혹은 네임스페이스 자체에 대한 쓰기 권한을 허용하지 않습니다. 또한 이 역할은 Kubernetes v1.22+를 사용하여 만든 클러스터의 엔드포인트에 대한 쓰기 액세스를 허용하지 않습니다. 자세한 내용은 엔드포인트에 대한 쓰기 액세스를 참조 하세요. |
edit | None | 네임스페이스에 있는 대부분의 개체에 대해 읽기/쓰기 액세스 권한을 허용합니다. 이 역할은 역할 또는 역할 바인딩을 보거나 수정할 수 없습니다. 그러나 이 역할을 사용하면 비밀에 액세스하고 네임스페이스에서 모든 ServiceAccount로 Pod를 실행할 수 있으므로 네임스페이스에서 모든 ServiceAccount의 API 액세스 수준을 얻는 데 사용할 수 있습니다. 또한 이 역할은 Kubernetes v1.22+를 사용하여 만든 클러스터의 엔드포인트에 대한 쓰기 액세스를 허용하지 않습니다. 자세한 내용은 엔드포인트에 대한 쓰기 액세스를 참조 하세요. |
view | None | 네임스페이스에 있는 대부분의 개체를 볼 수 있는 읽기 전용 권한을 허용합니다. 역할 또는 역할 바인딩 조회는 할 수 없습니다. 비밀의 내용을 읽으면 네임스페이스의 ServiceAccount 자격 증명에 액세스할 수 있으므로 이 역할은 비밀을 볼 수 없으므로 네임스페이스의 모든 ServiceAccount로 API 액세스를 허용합니다(권한 상승의 한 형태). |
Microsoft Entra ID와 함께 기본 제공 Kubernetes RBAC 역할 사용
Microsoft Entra ID와 함께 기본 제공 Kubernetes RBAC 역할을 사용하려면 다음 단계를 수행합니다.
Microsoft Entra 그룹에 기본 제공
view
Kubernetes RBAC 역할을 적용합니다.kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>
각 Microsoft Entra 사용자에게 기본 제공
view
Kubernetes RBAC 역할을 적용합니다.kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>
Microsoft Entra ID를 사용하여 클러스터 리소스 작업
이제 Kubernetes 클러스터에서 리소스를 만들고 관리할 때 필요한 권한을 테스트합니다. 이 예제에서는 사용자의 할당된 네임스페이스에서 Pod를 예약하고 봅니다. 그런 다음 할당된 네임스페이스 외부에서 Pod를 예약하고 보려고 합니다.
명령에 대한 입력으로 지정한 사용자 계정을 사용하여
$AKSDEV_ID
Azure에 로그인합니다az ad group member add
.az connectedk8s proxy
명령을 실행하여 클러스터에 대한 채널을 엽니다.az connectedk8s proxy -n <cluster-name> -g <resource-group>
프록시 채널이 설정되면 다른 세션을 열고 개발 네임스페이스의 명령을 사용하여 NGINX Pod를
kubectl run
예약합니다.kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
NGINX가 성공적으로 예약되면 다음 출력이 표시됩니다.
pod/nginx-dev created
이제 명령을 사용하여 네임스페이
kubectl get pods
스에서 Pod를dev
봅니다.kubectl get pods --namespace dev
NGINX가 성공적으로 실행되면 다음 출력이 표시됩니다.
NAME READY STATUS RESTARTS AGE nginx-dev 1/1 Running 0 4m
할당된 네임스페이스 외부에서 클러스터 리소스 만들기 및 보기
개발 네임스페이스 외부에서 Pod를 보려면 플래그가 kubectl get pods
있는 --all-namespaces
명령을 사용합니다.
kubectl get pods --all-namespaces
사용자의 그룹 멤버 자격에는 이 작업을 허용하는 Kubernetes 역할이 없습니다. 권한이 없으면 명령은 다음 오류를 생성합니다.
Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope