Łańcuchy poświadczeń w bibliotece klienta tożsamości Azure dla Go

Biblioteka klienta tożsamości platformy Azure udostępnia poświadczenia — typy publiczneimplementujące interfejs TokenCredential biblioteki klienta Azure Core. Poświadczenie reprezentuje odrębny przepływ uwierzytelniania na potrzeby uzyskiwania tokenu dostępu z identyfikatora Entra firmy Microsoft. Te poświadczenia można połączyć w łańcuch, aby utworzyć uporządkowaną sekwencję mechanizmów uwierzytelniania do wypróbowania.

Jak działa poświadczenie łańcuchowe

W czasie wykonywania łańcuch poświadczeń próbuje uwierzytelnić się przy użyciu pierwszego poświadczenia w sekwencji. Jeśli to poświadczenie nie może uzyskać tokenu dostępu, zostanie podjęta próba następnego poświadczenia w sekwencji itd., dopóki token dostępu nie zostanie pomyślnie uzyskany. Poniższy diagram sekwencji ilustruje to zachowanie:

Dlaczego warto używać łańcuchów poświadczeń

Poświadczenie łańcuchowe może oferować następujące korzyści:

• Rozpoznawanie środowiska: Automatycznie wybiera najbardziej odpowiednie poświadczenie na podstawie środowiska, w którym aplikacja jest uruchomiona. Bez niego musisz napisać kod podobny do następującego:

  // 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
      }
  }
  

• bezproblemowe przejścia: Aplikacja może przejść z lokalnego środowiska deweloperskiego do środowiska przejściowego lub produkcyjnego bez zmiany kodu uwierzytelniania.

• Ulepszona odporność: obejmuje mechanizm rezerwowy, który przechodzi do następnego poświadczenia, gdy nie można uzyskać tokenu dostępu przed.

Jak wybrać poświadczenie łańcuchowe

W języku Go istnieją dwie opcje tworzenia łańcuchów poświadczeń:

• Użyj wstępnie skonfigurowanego łańcucha: użyj wstępnie skonfigurowanego łańcucha zaimplementowanego przez typ DefaultAzureCredential. Aby zapoznać się z tym podejściem, zobacz sekcję DefaultAzureCredential overview.
• Utwórz niestandardowy łańcuch poświadczeń: zacznij od pustego łańcucha i uwzględnij tylko potrzebne elementy. Aby skorzystać z tego podejścia, zobacz sekcję ChainedTokenCredential overview.

Omówienie DefaultAzureCredential

DefaultAzureCredential jest subiektywnie skonfigurowanym łańcuchem poświadczeń. Jest ona przeznaczona do obsługi wielu środowisk wraz z najczęściej używanymi przepływami uwierzytelniania i narzędziami deweloperskich. W postaci graficznej podstawowy łańcuch wygląda następująco:

Kolejność, w której DefaultAzureCredential sprawdza poświadczenia.

Zamówienie	Poświadczenie	Opis
1	środowiska	Czyta zestaw zmiennych środowiskowych , aby ustalić, czy główną jednostkę usługi aplikacji (użytkownika aplikacji) skonfigurowano dla tej aplikacji. Jeśli tak, DefaultAzureCredential używa tych wartości do uwierzytelniania aplikacji na platformie Azure. Ta metoda jest najczęściej używana w środowiskach serwera, ale może być również używana podczas opracowywania lokalnie.
2	Tożsamość Obciążenia Pracą	Jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną Tożsamością Obciążenia, uwierzytelnij to konto.
3	Tożsamość zarządzana	Jeśli aplikacja zostanie wdrożona na hoście platformy Azure z włączoną tożsamością zarządzaną, uwierzytelnij aplikację na platformie Azure przy użyciu tej tożsamości zarządzanej.
4	Azure CLI	Jeśli deweloper uwierzytelnił się w usłudze Azure za pomocą polecenia az login Azure CLI, uwierzytelnij aplikację w usłudze Azure, używając tego samego konta.
5	Azure Developer CLI	Jeśli deweloper uwierzytelnił się w Azure przy użyciu polecenia azd auth login Azure Developer CLI, uwierzytelnij się przy użyciu tego konta.

W najprostszej formie można użyć bez parametrów wersji DefaultAzureCredential w następujący sposób:

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 — omówienie

ChainedTokenCredential to pusty łańcuch, do którego dodajesz poświadczenia zgodnie z potrzebami aplikacji. Na przykład:

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
}

Powyższy przykładowy kod tworzy dostosowany łańcuch poświadczeń składający się z dwóch poświadczeń. Najpierw podejmowana jest próba z ManagedIdentityCredential, a w razie potrzeby z AzureCliCredential. W formie graficznej łańcuch wygląda następująco:

Napiwek

Aby uzyskać lepszą wydajność, zoptymalizuj kolejność poświadczeń w ChainedTokenCredential dla środowiska produkcji. Poświadczenia przeznaczone do użytku w lokalnym środowisku programistycznym powinny zostać dodane na końcu.

Instrukcje dotyczące użycia elementu DefaultAzureCredential

DefaultAzureCredential jest niewątpliwie najprostszym sposobem rozpoczęcia pracy z biblioteką klienta tożsamości platformy Azure, ale z tą wygodą wiążą się pewne kompromisy. Po wdrożeniu aplikacji na platformie Azure należy zrozumieć wymagania dotyczące uwierzytelniania aplikacji. Z tego powodu zdecydowanie należy rozważyć przejście z DefaultAzureCredential do jednego z następujących rozwiązań:

• Konkretna implementacja uwierzytelnienia, taka jak ManagedIdentityCredential.
• Uproszczona implementacja ChainedTokenCredential zoptymalizowana pod kątem środowiska Azure, w którym działa Twoja aplikacja.

Oto dlaczego:

• Problemy z debugowaniem: w przypadku niepowodzenia uwierzytelniania, debugowanie oraz identyfikacja wadliwych poświadczeń mogą być trudne. Należy włączyć rejestrowanie, aby zobaczyć postęp z jednego poświadczenia do następnego i stan powodzenia/niepowodzenia każdego z nich. Aby uzyskać więcej informacji, zobacz Debugowanie poświadczeń łańcuchowych.
• Obciążenie wydajności: Proces sekwencyjnego próbowania wielu poświadczeń może wprowadzić obciążenie wydajności. Na przykład tożsamość zarządzana jest niedostępna podczas uruchamiania na lokalnym komputerze deweloperskim. W związku z tym ManagedIdentityCredential zawsze kończy się niepowodzeniem w lokalnym środowisku rozwojowym, chyba że jawnie wyłączony przez odpowiednią właściwość z prefiksem exclude.
• Nieprzewidywalne zachowanie: DefaultAzureCredential sprawdza obecność niektórych zmiennych środowiskowych . Możliwe, że ktoś może dodać lub zmodyfikować te zmienne środowiskowe na poziomie systemu na maszynie hosta. Te zmiany są stosowane globalnie i w związku z tym zmieniają zachowanie DefaultAzureCredential w czasie wykonywania w dowolnej aplikacji uruchomionej na tym komputerze.

Debugowanie poświadczeń łańcuchowych

Aby zdiagnozować nieoczekiwany problem lub zrozumieć, co robi poświadczenie łańcuchowe, włączyć rejestrowanie w aplikacji. Opcjonalnie przefiltruj dzienniki tylko do tych zdarzeń emitowanych z biblioteki klienta tożsamości platformy Azure. Na przykład:

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)

Aby uzyskać wskazówki dotyczące rozwiązywania błędów z określonych typów poświadczeń, zobacz przewodnik rozwiązywania problemów .