다음을 통해 공유


Go용 Azure ID 클라이언트 라이브러리의 자격 증명 체인

Azure Identity 클라이언트 라이브러리는 Azure Core 라이브러리의 TokenCredential 인터페이스를 구현하는 공용 형식인 자격 증명을 제공합니다. 자격 증명은 Microsoft Entra ID에서 액세스 토큰을 획득하기 위한 고유한 인증 흐름을 나타냅니다. 이러한 자격 증명을 함께 연결하여 순서가 있는 일련의 인증 메커니즘을 시도할 수 있도록 구성할 수 있습니다.

연결된 자격 증명의 작동 방식

런타임에 자격 증명 체인은 시퀀스의 첫 번째 자격 증명을 사용하여 인증을 시도합니다. 해당 자격 증명이 액세스 토큰을 획득하지 못하면 액세스 토큰을 성공적으로 가져올 때까지 시퀀스의 다음 자격 증명이 시도됩니다. 다음 시퀀스 다이어그램은 이 동작을 보여 줍니다.

자격 증명 체인 시퀀스를 보여 주는 다이어그램

자격 증명 체인을 사용하는 이유

연결된 자격 증명은 다음과 같은 이점을 제공할 수 있습니다.

  • 환경 인식: 앱이 실행되는 환경에 따라 가장 적합한 자격 증명을 자동으로 선택합니다. 이 코드가 없으면 다음과 같은 코드를 작성해야 합니다.

    // Set up credential based on environment (Azure or local development)
    if os.Getenv("WEBSITE_HOSTNAME") != "" {
        clientID := azidentity.ClientID("abcd1234-...")
        opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
        cred, err := azidentity.NewManagedIdentityCredential(&opts)
    
        if err != nil {
          // TODO: handle error
        }
    }
    else {
        // Use Azure CLI Credential
        credential, err = azidentity.NewAzureCLICredential(nil)
    
        if err != nil {
          // TODO: handle error
        }
    }
    
  • 원활한 전환: 앱은 인증 코드를 변경하지 않고 로컬 개발에서 스테이징 또는 프로덕션 환경으로 이동할 수 있습니다.

  • 향상된 복원력: 이전에 액세스 토큰을 획득하지 못한 경우 다음 자격 증명으로 이동하는 대체 메커니즘을 포함합니다.

연결된 자격 증명을 선택하는 방법

Go를 사용하면 자격 증명 체인을 선택할 수 있는 두 가지가 있습니다.

  • 미리 구성된 체인사용: DefaultAzureCredential 형식으로 구현된 미리 구성된 체인을 사용합니다. 이 방법은 DefaultAzureCredential 개요 섹션을 참조하세요.
  • 사용자 지정 자격 증명 체인빌드: 빈 체인으로 시작하고 필요한 것만 포함합니다. 이 방법은 ChainedTokenCredential 개요 섹션을 참조하세요.

DefaultAzureCredential 개요

DefaultAzureCredential는 의견에 따라 미리 구성된 자격 증명 체인입니다. 가장 일반적인 인증 흐름 및 개발자 도구와 함께 많은 환경을 지원하도록 설계되었습니다. 도식 형식의 기본 연결 구조는 다음과 같습니다.

DefaultAzureCredential 인증 흐름을 보여 주는 다이어그램

DefaultAzureCredential 자격 증명을 시도하는 순서는 다음과 같습니다.

주문 자격 증명 설명
1 환경 환경 변수 컬렉션을 읽어 애플리케이션 서비스 주체(애플리케이션 사용자)가 앱에 대해 구성되어 있는지 확인합니다. 그렇다면 DefaultAzureCredential 이러한 값을 사용하여 Azure에 앱을 인증합니다. 이 메서드는 서버 환경에서 가장 자주 사용되지만 로컬로 개발할 때도 사용할 수 있습니다.
2 워크로드 정체성 앱이 워크로드 ID를 사용하도록 설정된 Azure 호스트에 배포된 경우 해당 계정을 인증합니다.
3 관리된 신원 관리 ID를 사용하도록 설정된 Azure 호스트에 앱을 배포하는 경우 해당 관리 ID를 사용하여 Azure에 앱을 인증합니다.
4 Azure CLI 개발자가 Azure CLI의 az login 명령을 사용하여 Azure에 인증한 경우 동일한 계정을 사용하여 Azure에 앱을 인증합니다.
5 Azure Developer CLI 개발자가 Azure Developer CLI의 azd auth login 명령을 사용하여 Azure에 인증한 경우 해당 계정으로 인증합니다.

가장 간단한 형식으로 다음과 같이 매개 변수가 없는 DefaultAzureCredential 버전을 사용할 수 있습니다.

import (
    "github.com/Azure/azure-sdk-for-go/sdk/azidentity"
    "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
    )

// create a credential
credential, err := azidentity.NewDefaultAzureCredential(nil)
if err != nil {
    // TODO: handle error
}

// create a Blob service client 
accountURL := "https://<my_account_name>.blob.core.windows.net"
client, err := azblob.NewClient(accountURL, credential, nil)
if err != nil {
    // TODO: handle error
}

ChainedTokenCredential 개요

ChainedTokenCredential는 앱의 요구에 맞게 자격 증명을 추가할 수 있는 비어 있는 체인입니다. 예를 들어:

managed, err := azidentity.NewManagedIdentityCredential(nil)
if err != nil {
  // handle error
}

azCLI, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
  // handle error
}

chain, err := azidentity.NewChainedTokenCredential([]azcore.TokenCredential{managed, azCLI}, nil)
if err != nil {
  // handle error
}

앞의 코드 샘플은 두 개의 자격 증명으로 구성된 맞춤형 자격 증명 체인을 만듭니다. ManagedIdentityCredential 먼저 시도되고, 필요한 경우 AzureCliCredential이어서 시도됩니다. 그래픽 형태에서의 체인은 다음과 같이 보입니다.

관리 ID 자격 증명 및 Azure CLI 자격 증명으로 구성된 ChainedTokenCredential 인스턴스에 대한 인증 흐름을 보여 주는 다이어그램

성능 향상을 위해 프로덕션 환경에서 ChainedTokenCredential의 자격 증명 순서를 최적화하세요. 로컬 개발 환경에서 사용하기 위한 자격 증명을 마지막으로 추가해야 합니다.

DefaultAzureCredential에 대한 사용 지침

DefaultAzureCredential 의심할 여지 없이 Azure ID 클라이언트 라이브러리를 시작하는 가장 쉬운 방법이지만 이러한 편의상 장단점이 있습니다. Azure에 앱을 배포한 후에는 앱의 인증 요구 사항을 이해해야 합니다. 이러한 이유로, DefaultAzureCredential에서 다음 솔루션 중 하나로 이동하는 것을 강력히 고려하십시오.

  • ManagedIdentityCredential같은 특정 자격 증명 구현입니다.
  • 앱이 실행되는 Azure 환경에 최적화된 간소화된 ChainedTokenCredential 구현입니다.

그 이유는 다음과 같습니다.

  • 디버깅 과제: 인증에 실패하면 잘못된 자격 증명을 디버그하고 식별하기가 어려울 수 있습니다. 한 자격 증명에서 다음 자격 증명으로의 진행률과 각 자격 증명의 성공/실패 상태를 보려면 로깅을 사용하도록 설정해야 합니다. 자세한 내용은 연결된 자격 증명 디버그을 참조하세요.
  • 성능 오버헤드: 여러 자격 증명을 순차적으로 시도하는 프로세스로 인해 성능 오버헤드가 발생할 수 있습니다. 예를 들어 로컬 개발 머신에서 실행하는 경우 관리 ID를 사용할 수 없습니다. 따라서 해당 exclude접두사 속성을 통해 명시적으로 사용하지 않도록 설정하지 않는 한 ManagedIdentityCredential 항상 로컬 개발 환경에서 실패합니다.
  • 예측할 수 없는 동작: 특정 환경 변수가 있는지 확인합니다. 호스트 컴퓨터의 시스템 수준에서 이러한 환경 변수를 추가하거나 수정할 수 있습니다. 이러한 변경 내용은 전역적으로 적용되므로 해당 컴퓨터에서 실행되는 모든 앱에서 런타임에 DefaultAzureCredential 동작을 변경합니다.

연결된 자격 증명을 디버그하다

예기치 않은 문제를 진단하거나 연결된 자격 증명이 무엇을 수행하고 있는지 이해하려면 앱에서 로깅을 활성화하십시오. 필요에 따라 로그를 Azure ID 클라이언트 라이브러리에서 내보낸 이벤트로만 필터링합니다. 예를 들어:

import azlog "github.com/Azure/azure-sdk-for-go/sdk/azcore/log"
// print log output to stdout
azlog.SetListener(func(event azlog.Event, s string) {
    fmt.Println(s)
})
// include only azidentity credential logs
azlog.SetEvents(azidentity.EventAuthentication)

특정 자격 증명 유형의 오류를 해결하는 방법에 대한 지침은 문제 해결 가이드참조하세요.