Twój zespół platformowy chce usunąć długotrwałe poświadczenia dla CI/CD i dostępu w klastrze do zasobów Azure. GitHub Actions musi wdrażać szablony Bicep do Azure bez klucza tajnego klienta, a obciążenia AKS muszą uzyskiwać dostęp do Key Vault i Storage bez przechowywania kluczy tajnych jednostki usługi. Co należy skonfigurować? Każda poprawna odpowiedź stanowi część rozwiązania.

Poprawne odpowiedzi rozwiązują problem długotrwałych poświadczeń. Pierwsza opcja, tworząc rejestrację aplikacji w Entra ID z poświadczeniem federacyjnym GitHub OIDC, pozwala GitHub Actions na uwierzytelnianie się w Azure bez kluczy tajnych klienta. GitHub wymienia token OIDC z Entra ID na token dostępu Azure, co umożliwia wdrażanie szablonów Bicep. Druga opcja, włączenie Azure AD Workload Identity na AKS, umożliwia obciążeniom AKS dostęp do zasobów Azure (takich jak Key Vault i Storage) bez przechowywania kluczy tajnych jednostek usługi. Mapuje ona konto usługi Kubernetes do aplikacji Entra ID za pomocą poświadczeń tożsamości federacyjnej, pozwalając podom na uzyskanie tokenów dostępu Azure. Nieprawidłowe opcje: Generowanie PAT i przechowywanie go jako sekretu repozytorium to nadal użycie długotrwałego poświadczenia, co jest sprzeczne z celem. AAD Pod Identity jest przestarzałe i nie jest zalecanym podejściem dla nowych klastrów. Tworzenie jednostek usługi z certyfikatami i montowanie PFX w sekretach Kubernetes również wiąże się z zarządzaniem długotrwałymi poświadczeniami.