Microsoft 디스커버리의 관리되는 ID

Microsoft 검색은 사용자 할당 UI(관리 ID)를 사용하여 사용자를 대신하여 Azure 리소스에 대해 인증합니다. 비밀 또는 연결 문자열을 관리하는 대신 관리 ID를 만들고, 필요한 Azure 역할을 부여하고, 검색 리소스를 만들 때 해당 리소스 ID를 제공합니다. 그런 다음 검색 플랫폼은 해당 ID를 사용하여 스토리지 계정, 컨테이너 레지스트리, AI 서비스 및 MRG(관리되는 리소스 그룹) 리소스에 액세스합니다.

사용자 할당 관리 ID를 지정하는 이유

검색에는 다음과 같은 이유로 사용자가 할당한(시스템 할당이 아닌) 관리 ID가 필요합니다.

Reason Explanation
고객 소유권 고유한 구독에서 ID의 수명 주기를 만들고 관리하고 제어합니다.
리소스 간에 공유 작업 영역, 슈퍼컴퓨터 및 스토리지 작업에서 단일 UAMI를 재사용하여 관리 오버헤드를 줄일 수 있습니다.
E 프로비전된 역할 할당 Discovery에 처음부터 필요한 권한이 있도록 리소스를 만들기 전에 역할을 할당합니다.
변경할 수 없는 바인딩 작업 영역 ID 및 슈퍼컴퓨터 클러스터 ID는 생성 시 바인딩되며 나중에 변경할 수 없으므로 일관된 보안 상태를 보장합니다. 만든 후 슈퍼컴퓨터의 kubelet 및 워크로드 ID를 업데이트할 수 있습니다.

중요합니다

작업 영역 ID 및 슈퍼컴퓨터 클러스터 ID는 만든 후에 변경할 수 없습니다 . 프로비전된 후에는 변경할 수 없습니다. 슈퍼컴퓨터의 kubelet 및 워크로드 ID를 업데이트할 수 있습니다. 리소스를 만들기 전에 ID 전략을 계획합니다.

디스커버리에서 사용자의 신원을 사용하는 방법

작업 공간 또는 슈퍼컴퓨터가 생성될 때, Discovery 제어 평면이 수행하는 작업은 다음과 같습니다.

  • UAMI를 읽습니다. ID가 존재하고 서비스에서 작동할 수 있는지 확인합니다.
  • 자체 관리 ID 연산자 할당: 검색 서비스 주체는 관리되는 리소스 작업에 ID를 사용할 수 있도록 UAMI에서 관리 ID 운영자 역할을 가져옵니다.
  • 런타임에 UAMI 사용: 슈퍼컴퓨터에서 실행되는 도구는 ID를 사용하여 컨테이너 이미지를 끌어오고 Blob Storage에 액세스합니다. 에이전트는 이를 사용하여 Azure OpenAI 및 스토리지와 상호 작용합니다.

리소스 종류당 ID 슬롯

다른 검색 리소스는 다양한 방법으로 관리 ID를 사용합니다.

Workspace

작업 영역에는 속성을 통해 제공되는 단일 UAMI가 workspaceIdentity 필요합니다. 검색은 UAMI를 사용하여 다음을 수행합니다.

  • 작업 영역 식별: UAMI는 작업 영역을 구독의 리소스에 바인딩하는 보안 주체입니다.
  • 데이터 읽기 및 쓰기: Azure Blob Storage 계정은 스토리지 컨테이너를 통해 데이터를 읽고 씁니다.
  • 컨테이너 이미지 끌어오기: 슈퍼컴퓨터에서 도구를 실행할 때 Azure Container Registry 컨테이너 이미지를 가져옵니다.

Discovery는 UAMI가 아닌 자체 서비스 주체를 사용하여 MRG(Azure Cosmos DB, AI 서비스, 검색 인덱스 및 Azure OpenAI)를 프로비전하고 운영합니다. UAMI에는 MRG에 대한 역할이 필요하지 않습니다.

슈퍼컴퓨터

슈퍼컴퓨터는 세 개의 ID 슬롯을 사용하며, 이 슬롯은 모두 단순성을 위해 동일한 UAMI를 참조하거나 최소 권한에 대해 별도의 UAMI를 참조할 수 있습니다.

슬롯 Purpose
클러스터 ID AKS 컨트롤 플레인에서 네트워킹 및 부하 분산 장치와 같은 클러스터 수준 리소스를 관리하는 데 사용됩니다.
Kubelet ID 노드 수준에서 컨테이너 레지스트리에서 컨테이너 이미지를 끌어오고 Azure 리소스에 액세스하는 데 사용됩니다.
워크로드 정체성 슈퍼컴퓨터에서 도구와 에이전트를 실행하는 Pod의 페더레이션된 자격 증명으로 사용됩니다.

책장

책장은 해당 workloadIdentities 속성을 통해 UAMI를 참조합니다. Discovery는 자체 서비스 주체를 사용하여 bookshelf MRG(AI Search, SQL, AI Services)를 프로비전하고 운영합니다. 이 서비스는 또한 내부 리소스 간 인증을 위해 bookshelf MRG 내에 시스템 관리 ID를 생성합니다.

필수 역할 할당

검색 리소스를 만들기 전에 UAMI에 다음 기본 제공 역할을 할당해야 합니다. 리소스 그룹 범위에서 이러한 역할을 할당합니다.

역할 역할 정의 ID Purpose
Microsoft 검색 플랫폼 기여자(미리 보기) 01288891-85ee-45a7-b367-9db3b752fc65 작업 영역, 프로젝트, 에이전트 및 도구와 같은 검색 리소스를 관리합니다.
Storage Blob 데이터 기여자 ba92f5b4-2d11-453d-a403-e96b0029c9fe Azure Storage 계정에서 Blob을 읽고 씁니다.
아크풀 7f951dda-4ed3-4680-a7ca-43fe172d538d Container Registry에서 컨테이너 이미지를 끌어오기.

특수 시나리오에 필요한 다른 역할은 관리 ID 구성을 참조하세요.

검색 리소스 간 엔드 투 엔드 ID 흐름

전체 검색 스택을 배포할 때 플랫폼은 세 개의 MRG(작업 영역, 책장 및 슈퍼컴퓨터)를 만듭니다. 각 MRG에는 서비스에서 관리하는 Azure 리소스가 포함됩니다.

서비스가 자동으로 관리하는 내용

작업 영역, bookshelf 또는 슈퍼컴퓨터를 만들 때 자동으로 검색합니다.

  • 서비스가 MRG 리소스를 프로비전하고 작동할 수 있도록 MRG에 역할 할당을 만듭니다. 리소스에는 Microsoft Foundry, Azure Cosmos DB, Azure AI 검색, Storage, Azure Key Vault 및 AKS(Azure Kubernetes Service) 포함됩니다.
  • 서비스에서 MRG 배포에 사용할 수 있도록 UAMI에 관리 ID 운영자를 할당합니다.
  • 내부 리소스-리소스 인증(Azure Container Apps, Foundry, SQL)을 위한 각 작업 영역 및 bookshelf MRG 내에 시스템 관리 ID를 만듭니다.

이러한 ID 또는 역할 할당을 만들거나 관리할 필요가 없습니다. 서비스에서 완전히 관리되는 수명 주기입니다.

책임 있는 사항

다음 작업을 담당합니다.

  • UAMI 만들기: 검색 리소스를 만들기 전에 세 가지 핵심 역할(검색 플랫폼 기여자, 스토리지 Blob 데이터 기여자 및 AcrPull)을 할당합니다.
  • UAMI 리소스 ID를 제공합니다. 작업 영역 또는 슈퍼컴퓨터를 만들 때 ID를 입력합니다.

런타임의 UAMI

UAMI는 에이전트 및 도구가 런타임에 사용하는 ID입니다.

Operation Azure 리소스에 액세스됨 필수 역할
스토리지 컨테이너의 데이터 읽기/쓰기 Azure Blob Storage Storage Blob 데이터 기여자
끌어오기 도구 컨테이너 이미지 Container Registry 아크풀
검색 리소스 관리 검색 리소스 공급자 Microsoft 검색 플랫폼 기여자(미리 보기)
AKS 클러스터 네트워킹 운영 VNet(Azure Virtual Network) 서브넷 네트워크 기여자(슈퍼컴퓨터 클러스터 ID)

슈퍼컴퓨터의 경우 UAMI는 다음 세 개의 슬롯에 사용됩니다.

  • 클러스터 ID: AKS 컨트롤 플레인은 이를 사용하여 부하 분산 장치 및 네트워킹을 관리합니다.
  • Kubelet ID: 노드 수준 에이전트는 이를 사용하여 Container Registry에서 이미지를 끌어오고 Azure 리소스에 액세스합니다.
  • 워크로드 ID: Pod는 페더레이션된 자격 증명을 사용하여 도구 및 에이전트를 실행합니다.

단일 공유 UAMI와 함수당 별도의 ID 중에서 선택하는 방법에 대한 지침은 관리 ID 모범 사례 권장 사항을 참조하세요.

고급 구성: ID당 세분화된 역할 할당

필요한 역할 할당 섹션에서는 단일 공유 UAMI가 리소스 그룹 범위에서 세 가지 핵심 역할을 모두 수신하는 가장 간단한 방법을 설명합니다. 더 엄격한 보안 제어가 필요한 프로덕션 환경의 경우 각 ID가 액세스하는 특정 리소스로 범위가 지정된 최소 권한 역할 할당이 있는 별도의 UI를 할당합니다.

중요합니다

워크로드 ID는 도구 실행을 통해 에이전트에서 액세스할 수 있습니다. LLM(대문자 모델)에 의해 구동되는 에이전트는 런타임에 이 ID를 사용하는 도구를 호출하므로 워크로드 ID의 권한을 최소화하는 것이 중요합니다. 도구 작업에 꼭 필요한 권한만 할당합니다. 에이전트가 의도한 범위를 벗어나 ID를 사용하는 경우 워크로드 ID에 대한 광범위한 권한으로 인해 위험이 발생합니다.

ID별 역할 할당

다음 표에서는 별도의 UI를 사용할 때 각 ID에 대해 권장되는 세분화된 역할 할당을 보여 줍니다.

아이덴티티 역할 Scope Purpose
작업 영역 ID Microsoft 검색 플랫폼 기여자(미리 보기) 리소스 그룹 프로젝트, 채팅 모델 배포 및 스토리지 컨테이너와 같은 작업 영역 리소스를 관리합니다.
작업 영역 ID Storage Blob 데이터 기여자 스토리지 계정 백업 스토리지 계정의 작업 영역 데이터, 채팅 모델 아티팩트 및 프로젝트 자산을 읽고 씁니다.
클러스터 ID 플랫폼 관리형 네트워크 기여자 노드 리소스 그룹/VNet 클러스터 수준 네트워킹, 부하 분산 장치 및 노드 리소스 그룹 리소스를 관리합니다.
클러스터 ID 관리형 ID 운영자 노드 리소스 그룹 클러스터 워크로드에 대한 관리 ID에서 작동합니다.
Kubelet ID 아크풀 리소스 그룹(Container Registry 포함) 도구에 대한 끌어오기 컨테이너 이미지는 리소스 그룹에 프로비전된 모든 Container Registry에서 실행됩니다.
Kubelet ID Storage Blob 데이터 기여자 스토리지 계정 Pod를 시작하는 동안 백업 스토리지 계정에서 워크로드 아티팩트 및 입력을 읽습니다.
워크로드 정체성 Storage Blob 데이터 기여자 스토리지 계정 에이전트 워크로드(페더레이션 ID)로 도구를 실행하는 동안 데이터에 액세스합니다.

별도의 ID가 보안을 향상시키는 이유

단일 공유 UAMI를 사용하는 경우 워크로드 ID(에이전트가 도구 실행을 통해 사용)는 검색 플랫폼 기여자 및 AcrPull을 비롯한 모든 역할을 상속합니다. 이렇게 하면 LLM 기반 에이전트가 필요한 것보다 더 광범위한 액세스 권한을 부여합니다.

ID를 분리하면:

  • 워크로드 ID는 스토리지 계정 수준에서 Storage Blob 데이터 기여자만 수신하며, 이는 에이전트가 도구를 통해 액세스할 수 있는 것을 제한합니다.
  • 클러스터 ID는 에이전트 워크로드에 노출되지 않는 네트워킹 및 운영자 역할을 받습니다.
  • Kubelet ID는 에이전트 도구 실행과 격리된 이미지 끌어오기 및 Pod 시작 데이터 액세스를 처리합니다.

이렇게 분리하면 에이전트가 데이터 액세스 이외의 작업에 해당 ID를 사용하려고 하더라도 권한이 부족하여 요청이 실패합니다.

세분화된 할당을 사용하는 경우

다음과 같은 경우 범위가 지정된 역할과 함께 별도의 ID를 사용합니다.

  • 조직에는 최소 권한 액세스 제어가 필요합니다.
  • 중요한 데이터를 처리하고 폭발 반경을 제한하려는 도구를 실행합니다.
  • 규정 준수 요구 사항은 제어 평면 및 데이터 평면 ID를 분리해야 합니다.
  • 인프라 작업과 독립적으로 에이전트 데이터 액세스를 감사하려고 합니다.

공유 ID와 별도의 ID 중에서 선택하는 방법에 대한 지침은 관리 ID 모범 사례 권장 사항을 참조하세요.

제한점

  • UAMI는 UAMI를 사용하는 검색 리소스와 동일한 지역에 있어야 합니다.
  • 리소스를 만든 후에는 작업 영역 ID 및 슈퍼컴퓨터 클러스터 ID를 변경할 수 없습니다. 리소스를 삭제하고 다시 만들어야 합니다. 를 통해 PATCH슈퍼컴퓨터의 kubelet 및 워크로드 ID를 업데이트할 수 있습니다.
  • 역할 할당 전파는 최대 10분이 걸릴 수 있습니다. 검색 리소스를 만들기 전에 역할 할당을 만듭니다.
  • 검색을 수행하려면 UAMI에서 관리 ID 운영자 역할이 필요합니다. 리소스를 만드는 동안(예: Azure Policy 제한으로 인해) 이 역할 할당이 실패하면 작업 영역 프로비저닝이 실패합니다.

관련 콘텐츠

  • 에 마지막으로 업데이트됨