서비스 주체를 사용하여 인증
대화형 인증을 사용하거나 사용자 계정으로 인증하는 것이 부적절한 경우도 있습니다. 이러한 경우는 웹 서비스, 다른 작업자 역할 또는 자동화된 시스템에서 작업을 제출하려고 할 때 발생할 수 있습니다. 한 가지 옵션은 설명하는 관리 ID를 구성하는 것이고, 이 문서에서 설명하는 서비스 주체를 사용하여 인증하는 옵션도 있습니다.
필수 구성 요소: 서비스 주체 및 애플리케이션 비밀 만들기
서비스 주체로 인증하려면 먼저 서비스 주체를 만들어야 합니다.
서비스 주체를 만들고 액세스 권한을 할당하고 자격 증명을 만들려면 다음을 수행합니다.
-
참고
리디렉션 URI를 설정할 필요가 없습니다.
- 만들어지면 애플리케이션(클라이언트) ID 및 디렉터리(테넌트) ID를 기록합니다.
애플리케이션으로 로그인하려면 자격 증명을 만듭니다.
- 애플리케이션 설정에서 인증서 및 비밀을 선택합니다.
- 클라이언트 비밀에서 새 비밀 만들기를 선택합니다.
- 설명과 기간을 입력한 다음 추가를 선택합니다.
- 비밀 값을 즉시 안전한 장소에 복사합니다. 다시 확인할 수 없습니다.
작업 영역에 액세스할 수 있는 권한을 서비스 주체에게 부여합니다.
- Azure Portal을 엽니다.
- 검색 창에서 작업 영역을 만든 리소스 그룹의 이름을 입력합니다. 결과에 나타나는 리소스 그룹을 선택합니다.
- 리소스 그룹 개요에서 액세스 제어(IAM) 를 선택합니다.
- 역할 할당 추가를 선택합니다.
- 서비스 주체를 검색하고 선택합니다.
- 기여자 또는 소유자 역할을 할당합니다.
참고
리소스 그룹 또는 작업 영역에서 역할 할당을 만들려면 역할 할당 범위에서 ‘소유자’ 또는 ‘사용자 액세스 관리자’여야 합니다. 구독에서 서비스 주체를 만들 수 있는 권한이 없는 경우에는 Azure 구독의 ‘소유자’ 또는 ‘관리자’로부터 권한을 요청해야 합니다.
리소스 그룹 또는 작업 영역 수준에서만 권한이 있는 경우 다음을 사용하여 기여자 역할 아래에 서비스 주체를 만들 수 있습니다.
az ad sp create-for-rbac --role Contributor --scopes /subscriptions/<SUBSCRIPTION-ID>
서비스 주체를 사용하여 인증
옵션 1: 환경 변수 사용: Workspace
개체를 만드는 데 사용되는 기본 자격 증명은 여러 종류의 인증을 시도하는 DefaultAzureCredential입니다.
첫 번째는 EnvironmentCredential이며, 다음과 같은 환경 변수를 통해 서비스 주체 자격 증명을 전달합니다.
- AZURE_TENANT_ID: 서비스 주체의 테넌트 ID. '디렉터리' ID라고도 합니다.
- AZURE_CLIENT_ID: 서비스 주체의 클라이언트 ID
- AZURE_CLIENT_SECRET: 서비스 주체의 클라이언트 암호 중 하나
옵션 2: ClientSecretCredential 사용: Workspace
개체를 인스턴스화하는 동안 ClientSecretCredential을 전달하거나 credentials
속성을 설정합니다.
from azure.identity import ClientSecretCredential
tenant_id = os.environ["AZURE_TENANT_ID"]
client_id = os.environ["AZURE_CLIENT_ID"]
client_secret = os.environ["AZURE_CLIENT_SECRET"]
credential = ClientSecretCredential(tenant_id=tenant_id, client_id=client_id, client_secret=client_secret)
workspace.credentials = credential
참고
workspace.login()
메서드는 사용되지 않으며 더 이상 필요하지 않습니다. 처음으로 서비스를 호출하면 Workspace
생성자 또는 해당 credentials
속성에 전달된 자격 증명을 사용하여 인증을 시도합니다. 자격 증명이 전달되지 않은 경우 DefaultAzureCredential에서 몇 가지 인증 방법을 시도합니다.
피드백
https://aka.ms/ContentUserFeedback
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요.다음에 대한 사용자 의견 제출 및 보기