Azure Arc 지원 Kubernetes 클러스터의 Azure RBAC 사용(미리 보기)
Kubernetes ClusterRoleBinding 및 RoleBinding 개체 형식은 Kubernetes에서 기본적으로 권한 부여를 정의하는 데 도움이 됩니다. 이 기능을 사용하면 Azure에서 Microsoft Entra ID 및 역할 할당을 사용하여 클러스터에 대한 권한 부여 검사를 제어할 수 있습니다. Azure 역할 할당을 사용하면 배포, Pod 및 서비스와 같은 Kubernetes 개체를 읽고 쓰고 삭제할 수 있는 사용자를 세부적으로 제어할 수 있습니다.
이 기능의 개념적 개요는 Azure Arc 지원 Kubernetes의 Azure RBAC를 참조하세요.
Important
Azure Arc 지원 Kubernetes 미리 보기 기능은 셀프 서비스, 옵트인 기반에서 사용할 수 있습니다. 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. Azure Arc 지원 Kubernetes 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다.
필수 조건
최신 버전의
connectedk8sAzure CLI 확장을 설치합니다.az extension add --name connectedk8sconnectedk8s확장이 이미 설치되어 있는 경우 다음 명령을 사용하여 최신 버전으로 업데이트할 수 있습니다.az extension update --name connectedk8s기존 Azure Arc 지원 Kubernetes 클러스터를 연결합니다.
- 아직 클러스터를 연결하지 않은 경우 빠른 시작을 사용합니다.
- 최신 버전으로 에이전트를 업그레이드합니다.
참고 항목
Red Hat OpenShift, 사용자가 클러스터의 API 서버에 액세스할 수 없는 클라우드 공급자(예: Elastic Kubernetes Service 또는 Google Kubernetes Engine)의 관리되는 Kubernetes 제품에 대해 이 기능을 설정할 수 없습니다. Azure Kubernetes Service(AKS) 클러스터의 경우 이 기능은 고유하게 제공되며 AKS 클러스터를 Azure Arc에 연결할 필요가 없습니다.
Microsoft Entra 애플리케이션 설정
서버 애플리케이션 생성
새 Microsoft Entra 애플리케이션을 생성하고
appId값을 가져옵니다. 이 값은 이후 단계에서serverApplicationId로 사용됩니다.CLUSTER_NAME="<name-of-arc-connected-cluster>" TENANT_ID="<tenant>" SERVER_UNIQUE_SUFFIX="<identifier_suffix>" SERVER_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Server" --identifier-uris "api://${TENANT_ID}/${SERVER_UNIQUE_SUFFIX}" --query appId -o tsv) echo $SERVER_APP_ID서버 애플리케이션에 "로그인 및 사용자 프로필 읽기" API 권한을 부여하려면 이 JSON을 복사하여 oauth2-permissions.json이라는 파일에 저장합니다.
{ "oauth2PermissionScopes": [ { "adminConsentDescription": "Sign in and read user profile", "adminConsentDisplayName": "Sign in and read user profile", "id": "<paste_the_SERVER_APP_ID>", "isEnabled": true, "type": "User", "userConsentDescription": "Sign in and read user profile", "userConsentDisplayName": "Sign in and read user profile", "value": "User.Read" } ] }애플리케이션의 그룹 멤버십 클레임을 업데이트합니다.
oauth2-permissions.json파일과 동일한 디렉터리에서 명령을 실행합니다. Azure Arc 지원 Kubernetes용 RBAC를 사용하려면signInAudience를 AzureADMyOrg로 설정해야 합니다.az ad app update --id "${SERVER_APP_ID}" --set groupMembershipClaims=All az ad app update --id ${SERVER_APP_ID} --set api=@oauth2-permissions.json az ad app update --id ${SERVER_APP_ID} --set signInAudience=AzureADMyOrg SERVER_OBJECT_ID=$(az ad app show --id "${SERVER_APP_ID}" --query "id" -o tsv) az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${SERVER_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'서비스 주체를 생성하고
password필드 값을 받습니다. 나중에 클러스터에서 이 기능을 사용하도록 설정할 때,serverApplicationSecret으로서 이 값이 필요합니다. 이 비밀은 기본적으로 1년 동안 유효하며 그 후에는 회전해야 합니다. 사용자 지정 만료 기간을 설정하려면az ad sp credential reset을 사용합니다.az ad sp create --id "${SERVER_APP_ID}" SERVER_APP_SECRET=$(az ad sp credential reset --id "${SERVER_APP_ID}" --query password -o tsv)az ad app permission을 사용하여 애플리케이션에 "로그인 및 사용자 프로필 읽기" API 권한을 부여합니다.az ad app permission add --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --api-permissions e1fe6dd8-ba31-4d61-89e7-88639da4683d=Scope az ad app permission grant --id "${SERVER_APP_ID}" --api 00000003-0000-0000-c000-000000000000 --scope User.Read
클라이언트 애플리케이션 생성하기
새 Microsoft Entra 애플리케이션을 생성하고
appId값을 가져옵니다. 이 값은 이후 단계에서clientApplicationId로 사용됩니다.CLIENT_UNIQUE_SUFFIX="<identifier_suffix>" CLIENT_APP_ID=$(az ad app create --display-name "${CLUSTER_NAME}Client" --is-fallback-public-client --public-client-redirect-uris "api://${TENANT_ID}/${CLIENT_UNIQUE_SUFFIX}" --query appId -o tsv) echo $CLIENT_APP_ID이 클라이언트 애플리케이션의 서비스 주체를 만듭니다.
az ad sp create --id "${CLIENT_APP_ID}"서버 애플리케이션에 대해
oAuthPermissionId값을 받습니다.az ad app show --id "${SERVER_APP_ID}" --query "api.oauth2PermissionScopes[0].id" -o tsv클라이언트 애플리케이션에 대해 필요한 권한을 부여합니다. Azure Arc 지원 Kubernetes용 RBAC를 사용하려면
signInAudience를 AzureADMyOrg로 설정해야 합니다.az ad app permission add --id "${CLIENT_APP_ID}" --api "${SERVER_APP_ID}" --api-permissions <oAuthPermissionId>=Scope RESOURCE_APP_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "requiredResourceAccess[0].resourceAppId" -o tsv) az ad app permission grant --id "${CLIENT_APP_ID}" --api "${RESOURCE_APP_ID}" --scope User.Read az ad app update --id ${CLIENT_APP_ID} --set signInAudience=AzureADMyOrg CLIENT_OBJECT_ID=$(az ad app show --id "${CLIENT_APP_ID}" --query "id" -o tsv) az rest --method PATCH --headers "Content-Type=application/json" --uri https://graph.microsoft.com/v1.0/applications/${CLIENT_OBJECT_ID}/ --body '{"api":{"requestedAccessTokenVersion": 1}}'
서버 애플리케이션에 대한 역할 할당 만들기
서버 애플리케이션은 요청을 작성하는 사용자가 요청에 포함된 Kubernetes 개체에 대한 권한이 있음을 확인할 수 있도록 Microsoft.Authorization/*/read 권한이 필요합니다.
다음 콘텐츠가 포함된 accessCheck.json이라는 파일을 만듭니다.
{ "Name": "Read authorization", "IsCustom": true, "Description": "Read authorization", "Actions": ["Microsoft.Authorization/*/read"], "NotActions": [], "DataActions": [], "NotDataActions": [], "AssignableScopes": [ "/subscriptions/<subscription-id>" ] }<subscription-id>을 실제 구독 ID로 바꿉니다.다음 명령을 실행하여 새 사용자 지정 역할을 만듭니다.
ROLE_ID=$(az role definition create --role-definition ./accessCheck.json --query id -o tsv)생성한 역할을 사용하여 서버 애플리케이션에서 역할 할당을
assignee로 만듭니다.az role assignment create --role "${ROLE_ID}" --assignee "${SERVER_APP_ID}" --scope /subscriptions/<subscription-id>
클러스터에서 Azure RBAC 사용 설정
다음 명령을 실행하여 Azure Arc 지원 Kubernetes 클러스터에서 Azure RBAC(역할 기반 액세스 제어)를 사용하도록 설정합니다.
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"
참고 항목
위 명령을 실행하기 전 컴퓨터의 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.yamlvolumes아래에 다음 사양 추가:- name: azure-rbac hostPath: path: /etc/guard type: DirectoryvolumeMounts아래에 다음 사양 추가:- mountPath: /etc/guard name: azure-rbac readOnly: true
kube-apiserver가 정적 Pod가 아닌 경우:편집 모드에서
apiserver매니페스트를 엽니다.sudo vi /etc/kubernetes/manifests/kube-apiserver.yamlvolumes아래에 다음 사양 추가:- name: azure-rbac secret: secretName: azure-arc-guard-manifestsvolumeMounts아래에 다음 사양 추가:- 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,WebhookKubernetes 클러스터가 버전 1.19.0 이상이면 다음
apiserver인수도 설정해야 합니다.- --authentication-token-webhook-version=v1apiserverPod를 업데이트하기 위해 편집기를 저장하고 종료합니다.
Cluster API를 사용하여 생성한 클러스터
워크로드 클러스터에서 인증 및 권한 부여 웹후크 구성 파일을 포함하는 가드 비밀을 컴퓨터에 복사합니다.
kubectl get secret azure-arc-guard-manifests -n kube-system -o yaml > azure-arc-guard-manifests.yamlazure-arc-guard-manifests.yaml 파일에 있는
namespace필드를 워크로드 클러스터 생성을 위해 사용자 지정 리소스를 적용하려는 관리 클러스터 내의 네임스페이스로 변경합니다.이 매니페스트를 적용합니다.
kubectl apply -f azure-arc-guard-manifests.yamlkubectl 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: v1KubeadmControlPlane개체를 업데이트하기 위해 저장하고 종료합니다. 이러한 변경 사항이 워크로드 클러스터에 적용될 때까지 기다립니다.
사용자가 클러스터에 액세스하기 위한 역할 할당 만들기
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 버전에 따라 약간 다른 단계가 필요합니다.
다음 명령을 실행하여 사용자에 대해 자격 증명을 설정합니다.
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을 변환합니다. 예를 들어 Microsoft Entra 사용자의 디바이스 코드 로그인의 경우 명령은 다음과 같습니다.
export KUBECONFIG=/path/to/kubeconfig kubelogin convert-kubeconfig
클러스터로 요청을 보냅니다.
kubectl명령을 실행합니다. 예시:kubectl get nodeskubectl 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
서버 애플리케이션의 비밀 새로 고침
서버 애플리케이션의 서비스 주체에 대한 비밀이 만료된 경우 이를 회전해야 합니다.
SERVER_APP_SECRET=$(az ad sp credential reset --name "${SERVER_APP_ID}" --credential-description "ArcSecret" --query password -o tsv)
클러스터의 비밀을 업데이트합니다. 이 명령이 원래 실행되었을 때 구성한 선택적 매개 변수를 포함하세요.
az connectedk8s enable-features -n <clusterName> -g <resourceGroupName> --features azure-rbac --app-id "${SERVER_APP_ID}" --app-secret "${SERVER_APP_SECRET}"
다음 단계
- 클러스터 연결을 사용하여 클러스터에 안전하게 연결
- Arc 지원 Kubernetes의 Azure RBAC 아키텍처에 대해 참조하세요.