Azure Arc 지원 Kubernetes 클러스터의 Azure RBAC 사용

Microsoft Entra ID 및 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 Azure Arc 지원 Kubernetes 클러스터에서 권한 부여 검사를 제어할 수 있습니다. Azure 역할 할당을 사용하면 배포, Pod 및 서비스와 같은 Kubernetes 개체를 읽고 쓰고 삭제할 수 있는 사용자를 세부적으로 제어할 수 있습니다. Kubernetes ClusterRoleBinding 및 RoleBinding 개체 형식은 기본적으로 Kubernetes에서 권한 부여를 정의하는 데 도움이 됩니다.

이 기능에 대한 개념적 개요는 Azure Arc 지원 Kubernetes의 Azure RBAC를 참조하세요.

필수 구성 요소

• Azure CLI를 최신 버전으로 설치하거나 업그레이드 합니다.

• 최신 버전의 connectedk8s Azure CLI 확장을 설치합니다.

  az extension add --name connectedk8s
  

  connectedk8s 확장이 이미 설치되어 있는 경우 다음 명령을 사용하여 최신 버전으로 업데이트할 수 있습니다.

  az extension update --name connectedk8s
  

• 기존 Azure Arc 지원 Kubernetes 클러스터를 연결합니다.

  • 클러스터를 아직 연결하지 않은 경우 빠른 시작을 사용합니다.
  • 에이전트를 최신 버전으로 업그레이드합니다.

클러스터에서 Azure RBAC 사용 설정

1. 다음 명령을 실행하여 클러스터 MSI ID를 가져옵니다.

   az connectedk8s show -g <resource-group> -n <connected-cluster-name>
   

2. 출력에서 ID(identity.principalId)를 가져와 다음 명령을 실행하여 연결된 클러스터 관리 ID CheckAccess 판독자 역할을 클러스터 MSI에 할당하십시오.

   az role assignment create --role "Connected Cluster Managed Identity CheckAccess Reader" --assignee "<Cluster MSI ID>" --scope <cluster ARM ID>
   

3. 다음 명령을 실행하여 Azure Arc 지원 Kubernetes 클러스터에서 Azure RBAC(역할 기반 액세스 제어)를 사용하도록 설정합니다.

   az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
   

   참고

   명령을 실행 enable-features 하기 전에 컴퓨터의 kubeconfig 파일이 Azure RBAC를 사용하도록 설정하려는 클러스터를 가리키는지 확인합니다.

   --skip-azure-rbac-list와 함께 이 명령을 사용하여 사용자 이름, 전자 메일, OpenID 연결의 권한 부여 검사를 진행하고, Azure RBAC 대신 Kubernetes 네이티브 ClusterRoleBinding 및 RoleBinding 개체를 사용하여 쉼표로 구분된 목록을 만듭니다.

다음으로, 일반 클러스터(사양 apiserver에서 조정자가 실행되지 않는 경우) 또는 클러스터 API를 사용하여 만든 클러스터 중 어떤 것을 사용하는지에 따라 적절한 섹션의 단계를 따릅니다.

apiserver 사양에서 실행 중인 조정자 없는 제네릭 클러스터

1. 클러스터의 모든 마스터 노드에 SSH한 다음, 다음 단계를 완료합니다.

   kube-apiserver이(가) 정적 Pod인 경우:

   1. kube-system 네임스페이스의 azure-arc-guard-manifests 비밀에는 두 개의 파일 guard-authn-webhook.yaml 및 guard-authz-webhook.yaml이(가) 포함됩니다. 이러한 파일을 노드의 /etc/guard 디렉터리에 복사합니다.

      sudo mkdir -p /etc/guard
      kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authn-webhook.yaml"' | base64 -d > /etc/guard/guard-authn-webhook.yaml
      kubectl get secrets azure-arc-guard-manifests -n kube-system -o json | jq -r '.data."guard-authz-webhook.yaml"' | base64 -d > /etc/guard/guard-authz-webhook.yaml
      

   2. 편집 모드에서 apiserver 매니페스트를 엽니다.

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      

   3. volumes 아래에 다음 사양 추가:

      - hostPath:
          path: /etc/guard
          type: Directory
        name: azure-rbac
      

   4. volumeMounts 아래에 다음 사양 추가:

      - mountPath: /etc/guard
        name: azure-rbac
        readOnly: true
      

   귀하의 kube-apiserver가 정적 포드가 아닌 경우:

   1. 편집 모드에서 apiserver 매니페스트를 엽니다.

      sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
      

   2. volumes 아래에 다음 사양 추가:

      - name: azure-rbac
        secret:
          secretName: azure-arc-guard-manifests
      

   3. volumeMounts 아래에 다음 사양 추가:

      - mountPath: /etc/guard
        name: azure-rbac
        readOnly: true
      

2. 다음 apiserver 인수 추가:

   - --authentication-token-webhook-config-file=/etc/guard/guard-authn-webhook.yaml
   - --authentication-token-webhook-cache-ttl=5m0s
   - --authorization-webhook-cache-authorized-ttl=5m0s
   - --authorization-webhook-config-file=/etc/guard/guard-authz-webhook.yaml
   - --authorization-webhook-version=v1
   - --authorization-mode=Node,RBAC,Webhook
   

   다음 인수를 설정합니다.apiserver

   - --authentication-token-webhook-version=v1
   

3. apiserver Pod를 업데이트하기 위해 편집기를 저장하고 종료합니다.

Cluster API를 사용하여 생성한 클러스터

1. 워크로드 클러스터에서 인증 및 권한 부여 웹후크 구성 파일을 포함하는 가드 비밀을 컴퓨터에 복사합니다.

   kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
   

2. namespaceazure-arc-guard-manifests.yaml 파일의 필드를 워크로드 클러스터 만들기를 위해 사용자 지정 리소스를 적용하는 관리 클러스터 내의 네임스페이스로 변경합니다.

3. 이 매니페스트를 적용합니다.

   kubectl apply -f azure-arc-guard-manifests.yaml
   

4. kubectl edit kcp <clustername>-control-plane을(를) 실행하여 KubeadmControlPlane 개체를 편집합니다.

   1. files 아래에 다음 사양 추가:

      - contentFrom:
          secret:
            key: guard-authn-webhook.yaml
            name: azure-arc-guard-manifests
        owner: root:root
        path: /etc/kubernetes/guard-authn-webhook.yaml
        permissions: "0644"
      - contentFrom:
          secret:
            key: guard-authz-webhook.yaml
            name: azure-arc-guard-manifests
        owner: root:root
        path: /etc/kubernetes/guard-authz-webhook.yaml
        permissions: "0644"
      

   2. 다음 사양을 다음 아래에 추가합니다.apiServer>extraVolumes

      - hostPath: /etc/kubernetes/guard-authn-webhook.yaml
        mountPath: /etc/guard/guard-authn-webhook.yaml
        name: guard-authn
        readOnly: true
      - hostPath: /etc/kubernetes/guard-authz-webhook.yaml
        mountPath: /etc/guard/guard-authz-webhook.yaml
        name: guard-authz
        readOnly: true
      

   3. 다음 사양을 다음 아래에 추가합니다.apiServer>extraArgs

      authentication-token-webhook-cache-ttl: 5m0s
      authentication-token-webhook-config-file: /etc/guard/guard-authn-webhook.yaml
      authentication-token-webhook-version: v1
      authorization-mode: Node,RBAC,Webhook
      authorization-webhook-cache-authorized-ttl: 5m0s
      authorization-webhook-config-file: /etc/guard/guard-authz-webhook.yaml
      authorization-webhook-version: v1
      

   4. KubeadmControlPlane 개체를 업데이트하기 위해 저장하고 종료합니다. 이러한 변경 사항이 워크로드 클러스터에 적용될 때까지 기다립니다.

사용자가 클러스터에 액세스하기 위한 역할 할당 만들기

Azure Arc 지원 Kubernetes 리소스 소유자는 기본 제공 역할 또는 사용자 지정 역할을 사용하여 다른 사용자에게 Kubernetes 클러스터 액세스 권한을 부여할 수 있습니다.

기본 제공 역할

다음 기본 제공 역할은 Kubernetes 클러스터에서 일반적인 작업을 수행할 수 있는 액세스를 제공합니다. 이러한 역할은 Microsoft Entra ID 사용자, 그룹 또는 서비스 주체에게 부여할 수 있습니다.

Azure Portal 또는 Azure CLI를 사용하여 클러스터로 범위가 지정된 기본 제공 역할 할당을 만들 수 있습니다. 그러나 네임스페이스로 범위가 할당된 역할 할당을 만드는 데는 Azure CLI만 사용할 수 있습니다.

Azure Portal에서 Azure Arc 지원 Kubernetes 클러스터로 범위가 지정된 역할 할당을 만들려면 클러스터로 이동한 다음, 서비스 메뉴에서 IAM(Access Control) 을 선택합니다.

Azure CLI를 사용하여 역할 할당을 만들려면 다음 명령을 사용합니다.

az role assignment create --role "Azure Arc Kubernetes Cluster Admin" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID

AZURE-AD-ENTITY-ID 은 사용자 이름(예: testuser@mytenant.onmicrosoft.com)이거나 appId 서비스 주체의 값일 수 있습니다.

클러스터 내의 특정 네임스페이스로 범위가 지정된 역할 할당을 만들려면 범위를 수정합니다.

az role assignment create --role "Azure Arc Kubernetes Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>

사용자 지정 역할

역할 할당의 용도에 따라 고유 역할 정의를 만들도록 선택할 수 있습니다. 자세한 내용은 역할 정의를 생성하는 데 사용할 수 있는 데이터 작업의 전체 목록을 참조하세요.

다음 예제에서는 사용자가 배포를 읽을 수 있지만 다른 액세스 권한은 제공하지 않는 사용자 지정 역할 정의를 보여 줍니다. 사용자 지정 역할에는 데이터 작업 중 하나가 사용되며, 이를 사용해서 역할 할당이 생성되는 범위(클러스터 또는 네임스페이스)의 모든 배포를 볼 수 있습니다.

{
    "Name": "Arc Deployment Viewer",
    "Description": "Lets you view all deployments in cluster/namespace.",
    "Actions": [],
    "NotActions": [],
    "DataActions": [
        "Microsoft.Kubernetes/connectedClusters/apps/deployments/read"
    ],
    "NotDataActions": [],
    "assignableScopes": [
        "/subscriptions/<subscription-id>"
    ]
}

이 역할 정의를 사용하려면 다음 JSON 개체를 custom-role.json파일에 복사합니다. <subscription-id> 자리 표시자를 실제 구독 ID로 바꿉니다. 그런 다음, 다음 단계를 완료합니다.

1. custom-role.json저장한 폴더에서 다음 명령을 실행하여 역할 정의를 만듭니다.

   az role definition create --role-definition @custom-role.json
   

2. 역할 할당을 만들어 이 사용자 지정 역할 정의를 할당합니다.

   az role assignment create --role "Arc Deployment Viewer" --assignee <AZURE-AD-ENTITY-ID> --scope $ARM_ID/namespaces/<namespace-name>
   

사용자 자격 증명으로 kubectl 구성

클러스터에 액세스하는 데 필요한 kubeconfig 파일을 가져오는 방법에는 두 가지가 있습니다.

• Azure Arc 지원 Kubernetes 클러스터의 클러스터 연결 기능(az connectedk8s proxy)을 사용합니다.
• 클러스터 관리자는 kubeconfig 파일을 모든 사용자와 공유할 수 있습니다.

클러스터 연결 사용

다음 명령을 실행하여 프록시 프로세스를 시작합니다.

az connectedk8s proxy -n <clusterName> -g <resourceGroupName>

프록시 프로세스가 실행되면 콘솔에서 다른 탭을 열어 클러스터에 요청을 보내기 시작할 수 있습니다.

공유 kubeconfig 파일 사용

1. 다음 명령을 실행하여 사용자에 대해 자격 증명을 설정합니다. serverApplicationId은(는) 6256c85f-0aad-4d50-b960-e6e9b21efe35(으)로, clientApplicationId은(는) 3f4439ff-e698-4d6d-84fe-09c9d574f06b(으)로 지정합니다.

   kubectl config set-credentials <testuser>@<mytenant.onmicrosoft.com> \
   --auth-provider=azure \
   --auth-provider-arg=environment=AzurePublicCloud \
   --auth-provider-arg=client-id=<clientApplicationId> \
   --auth-provider-arg=tenant-id=<tenantId> \
   --auth-provider-arg=apiserver-id=<serverApplicationId>
   

2. 이전에 만든 kubeconfig 파일을 엽니다. contexts에서 클러스터와 연결된 컨텍스트가 이전 단계에서 만든 사용자 자격 증명을 가리키는지 확인합니다. 현재 컨텍스트를 이러한 사용자 자격 증명으로 설정하려면 다음 명령을 실행합니다.

   kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
   

3. 다음에서 구성 모드 설정을 추가합니다.user>config

   name: testuser@mytenant.onmicrosoft.com
   user:
       auth-provider:
       config:
           apiserver-id: $SERVER_APP_ID
           client-id: $CLIENT_APP_ID
           environment: AzurePublicCloud
           tenant-id: $TENANT_ID
           config-mode: "1"
       name: azure
   

4. Exec 플러그인은 kubectl이(가) 외부 명령을 실행하여 apiserver에 보낼 사용자 자격 증명을 수신할 수 있도록 하는 Kubernetes 인증 전략입니다. Kubernetes 버전 1.26부터 exec 플러그 인을 사용하여 사용자 자격 증명을 받으려면 Azure 인증을 구현하는 자격 증명(exec) 플러그 인인 Azure kubeloginclient-go을 사용해야 합니다. Azure kubelogin을 설치하려면:

   • Windows 또는 Mac의 경우 Azure kubelogin 설치 지침을 따릅니다.

   • Linux 또는 Ubuntu 의 경우 최신 버전의 kubelogin을 다운로드한 다음, 다음 명령을 실행합니다.

     curl -LO https://github.com/Azure/kubelogin/releases/download/"$KUBELOGIN_VERSION"/kubelogin-linux-amd64.zip 
     
     unzip kubelogin-linux-amd64.zip 
     
     sudo mv bin/linux_amd64/kubelogin /usr/local/bin/ 
     
     sudo chmod +x /usr/local/bin/kubelogin 
     

5. Kubelogin은 PoP(소유 증명) 토큰을 요청하여 Azure Arc 지원 클러스터로 인증하는 데 사용할 수 있습니다. kubelogin을 사용하여 kubeconfig를 변환하여 적절한 로그인 모드를 사용합니다. 예를 들어 Microsoft Entra 사용자로 디바이스 코드 로그인 의 경우 명령은 다음과 같습니다.

   export KUBECONFIG=/path/to/kubeconfig
   
   kubelogin convert-kubeconfig --pop-enabled --pop-claims 'u=<ARM ID of cluster>"
   

클러스터로 요청을 보냅니다.

1. kubectl 명령을 실행합니다. 예를 들면 다음과 같습니다.

   • kubectl get nodes
   • kubectl get pods

2. 브라우저 기반 인증에 대한 메시지가 표시되면 디바이스 로그인 URL(https://microsoft.com/devicelogin)을 복사하여 웹 브라우저에서 엽니다.

3. 콘솔에 인쇄된 코드를 입력합니다. 터미널에서 코드를 복사하여 디바이스 인증 입력 프롬프트에 붙여 넣습니다.

4. 사용자 이름(testuser@mytenant.onmicrosoft.com) 및 연결된 암호를 입력합니다.

5. 사용자가 Azure의 리소스에 액세스할 수 없다는 오류 메시지가 표시되면 요청된 리소스에 액세스할 권한이 없음을 의미합니다. 이 경우 Azure 테넌트 관리자가 이 사용자에게 리소스에 대한 액세스 권한을 부여하는 새 역할 할당을 만들어야 합니다.

Microsoft Entra ID에서 조건부 액세스 사용

Microsoft Entra ID를 Azure Arc 지원 Kubernetes 클러스터와 통합하는 경우 조건부 액세스를 사용하여 클러스터에 대한 액세스를 제어할 수도 있습니다.

클러스터와 함께 사용할 조건부 액세스 정책 예를 만들려면 다음 안내를 따릅니다.

1. Azure Portal 맨 위에서 Microsoft Entra ID를 검색하여 선택합니다.
2. 서비스 메뉴의 관리 아래에서 엔터프라이즈 애플리케이션을 선택합니다.
3. 서비스 메뉴의 보안 아래에서 조건부 액세스를 선택합니다.
4. 서비스 메뉴에서 정책을 선택합니다. 그런 다음 새 정책 만들기를 선택합니다.
5. 정책의 이름을 입력합니다(예: arc-k8s-policy.).
6. 할당에서 사용자 또는 워크로드 ID에서 현재 값을 선택합니다. 그런 다음 , 이 정책이 적용되는 대상에서 사용자 및 그룹이 선택되어 있는지 확인합니다.
7. 포함에서 사용자 및 그룹 선택을 선택합니다. 정책을 적용할 사용자 및 그룹을 선택합니다. 이 예시에서는 클러스터에 대한 관리 액세스 권한이 있는 동일한 Microsoft Entra 그룹을 선택합니다.
8. 클라우드 앱 또는 작업에서 현재 값을 선택합니다. 그런 다음 , 이 정책이 적용되는 항목 선택에서 클라우드 앱 이 선택되어 있는지 확인합니다.
9. 포함에서 리소스 선택을 선택합니다. 그런 다음 이전에 만든 서버 애플리케이션을 검색하여 선택합니다.
10. Access 컨트롤에서 권한 부여에서 현재 값을 선택합니다. 그런 다음 권한 부여를 선택합니다.
11. 디바이스가 규격을 준수하도록 요구 확인란을 선택한 다음, 선택을 클릭합니다.
12. 정책 사용에서 켜기를 선택합니다.
13. 조건부 액세스 정책을 적용하려면 만들기를 선택합니다.

클러스터에 다시 액세스합니다. 예를 들어, kubectl get nodes 명령을 실행하여 클러스터의 노드를 봅니다.

kubectl get nodes

정책이 올바르게 적용되었는지 확인하려면 지침에 따라 다시 로그인합니다. 로그인에 성공했음을 나타내는 오류 메시지가 표시되지만, 리소스에 액세스하기 위해 관리자는 Microsoft Entra ID에서 액세스 요청을 관리하는 디바이스를 요구합니다. 자세한 내용을 보려면 다음 단계를 수행합니다.

1. Azure Portal에서 Microsoft Entra ID로 이동합니다.
2. 서비스 메뉴의 관리 아래에서 엔터프라이즈 애플리케이션을 선택합니다.
3. 서비스 메뉴의 작업에서 로그인 로그를 선택합니다.
4. 조건부 액세스의 상태 및 성공의 실패를 보여 주는 위쪽 항목을 선택합니다. 그런 다음 세부 정보 아래에서 조건부 액세스를 선택합니다. 사용자가 만든 조건부 액세스 정책이 표시되므로 디바이스를 준수해야 합니다.

Microsoft Entra ID를 사용하여 Just-In-Time 클러스터 액세스 구성

클러스터 액세스 제어를 위한 또 다른 옵션은 PIM(Privileged Identity Management)이며, 이를 통해 사용자에게 Just-In-Time 요청에 대해 더 높은 수준의 액세스가 가능합니다.

사용자 그룹에 대한 Just-In-Time 액세스 요청을 구성하려면 다음 단계를 완료합니다.

1. Azure Portal 맨 위에서 Microsoft Entra ID를 검색하여 선택합니다.

2. 서비스 메뉴의 관리에서 그룹을 선택합니다. 그런 다음 , 새 그룹을 선택합니다.

3. 그룹 형식의 경우 보안이 선택되어 있는지 확인합니다. 그룹 이름(예: myJITGroup.)을 입력합니다. 추가 선택을 한 다음 만들기를 선택합니다.

   

4. 그룹 페이지로 돌아갑니다. 새로 만든 그룹을 검색하여 선택합니다.

5. 서비스 메뉴의 작업에서 Privileged Identity Management를 선택합니다. 그런 다음 , 이 그룹에 대해 PIM 사용을 선택합니다.

6. 할당 추가를 선택하여 액세스 권한을 부여하기 시작합니다.

7. 역할 선택에서 멤버를 선택합니다. 그런 다음 클러스터 액세스 권한을 부여할 사용자 및 그룹을 선택합니다. 그룹 관리자는 언제든지 이러한 할당을 수정할 수 있습니다. 계속 진행할 준비가 되면 다음을 선택합니다.

   

8. 활성의 할당 유형을 선택하고 원하는 기간을 선택하고 근거를 제공합니다. 계속 진행할 준비가 되면 할당을 선택합니다.

   

이러한 단계 및 옵션에 대한 자세한 내용은 Privileged Identity Management의 그룹에 대한 자격 할당을 참조하세요.

할당이 완료되면 클러스터에 액세스하여 Just-In-Time 액세스가 작동하는지 확인합니다. 예를 들어, kubectl get nodes 명령을 사용하여 클러스터의 노드를 봅니다.

kubectl get nodes

인증 요구 사항을 확인하고 인증 단계를 따릅니다. 인증에 성공하면 다음과 비슷한 내용이 출력됩니다.

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

NAME      STATUS   ROLES    AGE      VERSION
node-1    Ready    agent    6m36s    v1.18.14
node-2    Ready    agent    6m42s    v1.18.14
node-3    Ready    agent    6m33s    v1.18.14

다음 단계

• Arc 지원 Kubernetes에서 Azure RBAC의 아키텍처에 대해 알아봅니다.
• 클러스터 연결을 사용하여 Arc 지원 Kubernetes 클러스터에 안전하게 연결합니다.
• Azure Arc 지원 Kubernetes에 대한 보안 설명서의 지침에 따라 다른 방법으로 클러스터를 보호하는 데 도움이 됩니다.