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

아티클
09/25/2024

Kubernetes ClusterRoleBinding 및 RoleBinding 개체 형식은 Kubernetes에서 기본적으로 권한 부여를 정의하는 데 도움이 됩니다. 이 기능을 사용하면 Azure에서 Microsoft Entra ID 및 역할 할당을 사용하여 클러스터에 대한 권한 부여 검사를 제어할 수 있습니다. Azure 역할 할당을 사용하면 배포, Pod 및 서비스와 같은 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 클러스터를 연결합니다.
- 아직 클러스터를 연결하지 않은 경우 빠른 시작을 사용합니다.
- 최신 버전으로 에이전트를 업그레이드합니다.

참고 항목

API 서버에 대한 사용자 액세스가 제한된 Red Hat OpenShift 또는 관리되는 Kubernetes 제품에는 Azure RBAC를 사용할 수 없습니다(예: Amazon EKS(Elastic Kubernetes Service), GKE(Google Kubernetes Engine)).

Azure RBAC는 현재 ARM64 아키텍처에서 작동하는 Kubernetes 클러스터를 지원하지 않습니다. Kubernetes RBAC를 사용하여 ARM64 기반 Kubernetes 클러스터에 대한 액세스 제어를 관리하세요.

Azure Kubernetes Service(AKS) 클러스터의 경우 이 기능은 고유하게 제공되며 AKS 클러스터를 Azure Arc에 연결할 필요가 없습니다.

Azure Stack HCI 23H2의 Azure Arc에서 사용하도록 설정된 AKS(Azure Kubernetes Service) 클러스터의 경우 Azure RBAC를 사용하도록 설정하는 것은 현재 Kubernetes 클러스터를 만드는 동안에만 지원됩니다. Azure RBAC를 사용하도록 설정된 Azure Arc에서 사용하도록 설정된 AKS 클러스터를 만들려면 Kubernetes 권한 부여 가이드에 Azure RBAC를 사용합니다. Azure RBAC는 Azure Stack HCI 버전 22H2에서 지원되지 않습니다.

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

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

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

출력에서 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>
```
다음 명령을 실행하여 Azure Arc 지원 Kubernetes 클러스터에서 Azure RBAC(역할 기반 액세스 제어)를 사용하도록 설정합니다.
```
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac
```
참고 항목

위 명령을 실행하기 전 컴퓨터의 kubeconfig 파일이 Azure RBAC 기능을 사용하도록 설정할 클러스터를 지정하는지 확인합니다.

Azure RBAC 대신 Kubernetes 네이티브 ClusterRoleBinding 및 RoleBinding 개체를 사용하여 권한 부여 검사를 진행 중인 사용자 이름, 이메일, OpenID 연결을 쉼표로 구분한 위 명령과 함께 --skip-azure-rbac-list을 사용합니다.

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

클러스터의 모든 마스터 노드에 SSH로 연결하고 다음 단계를 실행합니다.

kube-apiserver가 정적 Pod인 경우:

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

편집 모드에서 apiserver 매니페스트를 엽니다.
```
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
```

volumes 아래에 다음 사양 추가:

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

volumeMounts 아래에 다음 사양 추가:

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

kube-apiserver가 정적 Pod가 아닌 경우:

편집 모드에서 apiserver 매니페스트를 엽니다.
```
sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
```

volumes 아래에 다음 사양 추가:

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

volumeMounts 아래에 다음 사양 추가:

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

다음 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

Kubernetes 클러스터가 버전 1.19.0 이상이면 다음 apiserver 인수도 설정해야 합니다.

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

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

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

워크로드 클러스터에서 인증 및 권한 부여 웹후크 구성 파일을 포함하는 가드 비밀을 컴퓨터에 복사합니다.
```
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yaml
```
azure-arc-guard-manifests.yaml 파일에 있는 namespace 필드를 워크로드 클러스터 생성을 위해 사용자 지정 리소스를 적용하려는 관리 클러스터 내의 네임스페이스로 변경합니다.

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

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

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

다음 코드 조각을 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"

다음 코드 조각을 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

다음 코드 조각을 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

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

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

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

기본 제공 역할

역할	설명
Azure Arc Kubernetes 뷰어	네임스페이스에 있는 대부분의 개체를 볼 수 있는 읽기 전용 권한을 허용합니다. 비밀에 대한 `read` 권한은 네임스페이스에 있는 `ServiceAccount` 자격 증명에 대한 액세스를 허용하므로 이 역할은 비밀을 보는 것을 허용하지 않습니다. 이러한 자격 증명을 사용하면 해당 `ServiceAccount` 값(권한 상승 형태)을 통해 API에 액세스할 수 있습니다.
Azure Arc Kubernetes 작성자	네임스페이스에 있는 대부분의 개체에 대해 읽기/쓰기 액세스 권한을 허용합니다. 이 역할은 역할 또는 역할 바인딩을 보거나 수정할 수 없습니다. 그러나 이 역할은 네임스페이스의 모든 `ServiceAccount` 값으로 비밀에 액세스하고 Pod를 실행하도록 허용하므로 네임스페이스의 모든 `ServiceAccount` 값에 대한 API 액세스 수준을 얻는 데 사용할 수 있습니다.
Azure Arc Kubernetes 관리자	관리자 액세스 권한을 허용합니다. 네임스페이스 내에서 `RoleBinding`을 통해 부여하려는 의도입니다. `RoleBinding`에서 사용할 경우, 네임스페이스 내에서 역할 및 역할 바인딩 만들기 기능을 포함하여 네임스페이스에 있는 대부분의 리소스에 대한 읽기/쓰기 권한을 허용합니다. 이 역할은 리소스 할당량 혹은 네임스페이스 자체에 대한 쓰기 권한을 허용하지 않습니다.
Azure Arc Kubernetes 클러스터 관리자	슈퍼 사용자 액세스를 허용하여 모든 리소스에 대한 모든 작업을 실행할 수 있습니다. `ClusterRoleBinding`에서 사용할 경우, 클러스터 및 모든 네임스페이스의 모든 리소스를 완전히 제어할 수 있습니다. `RoleBinding`에서 사용할 경우, 네임스페이스 자체를 포함하여 역할 바인딩의 네임스페이스에 있는 모든 리소스에 대한 전체 제어 권한을 부여합니다.

클러스터 리소스의 Access Control(IAM) 창에서 Azure Portal 내의 Azure Arc 지원 Kubernetes 클러스터로 범위가 지정된 역할 할당을 생성할 수 있습니다. 다음 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>

참고 항목

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

사용자 지정 역할

역할 할당의 용도에 따라 고유 역할 정의를 만들도록 선택할 수 있습니다.

사용자의 배포 읽기만 허용하는 역할 정의에 대한 아래 예시를 확인하세요. 자세한 내용은 역할 정의를 생성하는 데 사용할 수 있는 데이터 작업의 전체 목록을 참조하세요.

아래 JSON 개체를 custom-role.json이라는 파일에 복사합니다. <subscription-id> 자리 표시자를 실제 구독 ID로 바꿉니다. 사용자 지정 역할에는 데이터 작업 중 하나가 사용되며, 이를 사용해서 역할 할당이 생성되는 범위(클러스터 또는 네임스페이스)의 모든 배포를 볼 수 있습니다.

{
    "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>"
    ]
}

custom-role.json을 저장한 폴더에서 아래 명령을 실행하여 역할 정의를 생성합니다.
```
az role definition create --role-definition @custom-role.json
```

이 사용자 지정 역할 정의를 사용하여 역할 할당을 생성합니다.

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 파일 사용

공유 kubeconfig를 사용하려면 Kubernetes 버전에 따라 약간 다른 단계가 필요합니다.

Kubernetes 버전 >= 1.26
Kubernetes < v1.26

다음 명령을 실행하여 사용자에 대해 자격 증명을 설정합니다. 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>

이전에 만든 kubeconfig 파일을 엽니다. contexts에서 클러스터와 연결된 컨텍스트가 이전 단계에서 만든 사용자 자격 증명을 가리키는지 확인합니다. 현재 컨텍스트를 이러한 사용자 자격 증명으로 설정하려면 다음 명령을 실행합니다.
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```
user>config 아래에서 config-mode 설정을 추가합니다.
```
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
```
참고 항목

Exec 플러그 인은 kubectl에서 외부 명령을 실행하여 apiserver로 보낼 사용자 자격 증명을 수신할 수 있는 Kubernetes 인증 전략입니다. Kubernetes 버전 1.26부터 기본 Azure 권한 부여 플러그 인은 더 이상 client-go 및 kubectl에 포함되지 않습니다. 이후 버전에서는 exec 플러그 인을 사용하여 사용자 자격 증명을 받으려면 Azure 인증을 구현하는 client-go 자격 증명(exec) 플러그 인에 해당하는 Azure Kubelogin을 사용해야 합니다.

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

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>"
```

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>

이전에 만든 kubeconfig 파일을 엽니다. contexts에서 클러스터와 연결된 컨텍스트가 이전 단계에서 만든 사용자 자격 증명을 가리키는지 확인합니다. 현재 컨텍스트를 이러한 사용자 자격 증명으로 설정하려면 다음 명령을 실행합니다.
```
kubectl config set-context --current=true --user=<testuser>@<mytenant.onmicrosoft.com>
```

user>config 아래에서 config-mode 설정을 추가합니다.

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

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

kubectl 명령을 실행합니다. 예시:
- kubectl get nodes
- kubectl get pods
브라우저 기반 인증에 대한 메시지가 표시되면 디바이스 로그인 URL(https://microsoft.com/devicelogin)을 복사하여 웹 브라우저에서 엽니다.
콘솔에 인쇄된 코드를 입력합니다. 터미널에서 코드를 복사하여 디바이스 인증 입력 프롬프트에 붙여 넣습니다.
사용자 이름(testuser@mytenant.onmicrosoft.com) 및 연결된 암호를 입력합니다.
이와 비슷한 오류 메시지가 표시되면 요청된 리소스에 액세스하도록 권한이 부여되지 않은 것입니다.
```
Error from server (Forbidden): nodes is forbidden: User "testuser@mytenant.onmicrosoft.com" cannot list resource "nodes" in API group "" at the cluster scope: User doesn't have access to the resource in Azure. Update role assignment to allow access.
```
이 사용자가 리소스에 액세스하도록 권한을 부여하려면 관리자가 새 역할 할당을 만들어야 합니다.

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

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

참고 항목

Microsoft Entra 조건부 액세스는 Microsoft Entra ID P2 기능입니다.

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

Azure Portal 위쪽에서 Microsoft Entra ID를 검색하고 선택합니다.
왼쪽의 Microsoft Entra ID에 대한 메뉴에서 엔터프라이즈 애플리케이션을 선택합니다.
왼쪽의 엔터프라이즈 애플리케이션에 메뉴에서 조건부 액세스를 선택합니다.
왼쪽의 조건부 액세스 메뉴에서 정책>새 정책을 차례로 선택합니다.
정책 이름(예: arc-k8s-policy)을 입력합니다.
사용자 및 그룹을 선택합니다. 포함에서 사용자 및 그룹 선택을 선택합니다. 정책을 적용할 사용자 및 그룹을 선택합니다. 이 예시에서는 클러스터에 대한 관리 액세스 권한이 있는 동일한 Microsoft Entra 그룹을 선택합니다.
클라우드 앱 또는 작업을 선택합니다. 포함에서 앱 선택을 선택합니다. 그런 다음 이전에 만든 서버 애플리케이션을 검색하여 선택합니다.
액세스 제어에서 권한 부여를 선택합니다. 액세스 권한 부여>디바이스가 규격으로 표시되어야 함을 선택합니다.
정책 사용에서 켜기>생성을 선택합니다.

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

kubectl get nodes

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

Azure Portal에서 Microsoft Entra ID로 이동합니다.
Enterprise 애플리케이션을 선택합니다. 그런 다음 활동 아래에서 로그인을 선택합니다.
맨 위에 있는 항목은 상태에 대해 실패, 조건부 액세스에 대해 성공을 표시합니다. 항목을 선택하고, 세부 정보에서 조건부 액세스를 선택합니다. 조건부 액세스 정책이 나열되어 있는지 확인합니다.

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

클러스터 액세스 제어를 위한 또 다른 옵션은 Just-In-Time 요청에 대해 PIM(Privileged Identity Management)을 사용하는 것입니다.

참고 항목

Microsoft Entra PIM은 Microsoft Entra ID P2 기능입니다. Microsoft Entra ID SKU에 대한 자세한 내용은 가격 책정 가이드를 참조하세요.

클러스터에 대한 Just-In-Time 액세스 요청을 구성하려면 다음 단계를 완료합니다.

Azure Portal 위쪽에서 Microsoft Entra ID를 검색하고 선택합니다.
테넌트 ID를 기록해 둡니다. 지침의 나머지 부분에서 해당 ID를 <tenant-id>로 지칭합니다.
왼쪽에 있는 Microsoft Entra ID 메뉴의 관리에서 그룹>새 그룹을 선택합니다.
그룹 유형에 대해 보안이 선택되어 있는지 확인합니다. 그룹 이름(예: myJITGroup)을 입력합니다. Microsoft Entra 역할을 이 그룹에 할당할 수 있습니다(미리 보기)에서 예를 선택합니다. 마지막으로 만들기를 선택합니다.
그리고 그룹 페이지로 돌아갑니다. 새로 생성된 그룹을 선택하고 개체 ID를 적어둡니다. 지침의 나머지 부분에서는 이 ID를 <object-id>로 지칭합니다.
Azure Portal로 돌아가서, 왼쪽의 작업 메뉴에서 권한 있는 액세스(미리 보기)를 선택합니다. 그런 다음 권한 있는 액세스를 사용하도록 설정을 선택합니다.
할당 추가를 선택하여 액세스 권한 부여를 시작합니다.
멤버의 역할을 선택하고, 클러스터 액세스 권한을 부여할 사용자 및 그룹을 선택합니다. 그룹 관리자는 언제든지 이러한 할당을 수정할 수 있습니다. 계속 진행할 준비가 되면 다음을 선택합니다.
활성의 할당 유형, 원하는 기간을 선택하고 사유를 입력합니다. 계속할 준비가 되면 할당을 선택합니다. 할당 형식에 대한 자세한 내용은 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 아키텍처에 대해 참조하세요.

다음을 통해 공유

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

필수 조건

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

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

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

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

기본 제공 역할

사용자 지정 역할

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

클러스터 연결 사용

공유 kubeconfig 파일 사용

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

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

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

다음 단계

피드백

추가 리소스

다음을 통해 공유

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

필수 조건

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

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

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

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

기본 제공 역할

사용자 지정 역할

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

클러스터 연결 사용

공유 kubeconfig 파일 사용

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

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

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

다음 단계

피드백

추가 리소스

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