Informacje o jednostkach usługi
Jednostki usługi umożliwiają uwierzytelnianie potoków, aplikacji i oprogramowania. W tej lekcji dowiesz się, dlaczego jednostki usługi są ważne dla potoków wdrażania, jak pasują do modelu zabezpieczeń platformy Azure i jak działają.
Dlaczego potok musi się uwierzytelniać?
Podczas wdrażania szablonu Bicep skutecznie poprosisz usługę Azure Resource Manager o utworzenie lub zmodyfikowanie zasobów platformy Azure. W tym przykładowym scenariuszu utworzono szablon Bicep w celu wdrożenia witryny sieci Web firmowej. Szablon Bicep deklaruje zasoby, które obejmują plan usługi aplikacja systemu Azure, aplikację i wystąpienie Szczegółowe informacje aplikacji.
Podczas wdrażania szablonu usługa Resource Manager sprawdza, czy zasoby istnieją. Jeśli tak nie jest, usługa Resource Manager je utworzy. Jeśli jakiekolwiek już istnieją, usługa Resource Manager gwarantuje, że ich konfiguracja jest zgodna z konfiguracją, którą określisz w szablonie.
Wszystkie te operacje wymagają uprawnień, ponieważ uzyskują dostęp do zasobów platformy Azure i modyfikują je. Określone uprawnienia wymagane do wdrożenia będą zależeć od tego, co zawiera szablon. Aby wdrożyć przykładowy szablon Bicep dla firmowej witryny internetowej twojej firmy, musisz mieć następujące uprawnienia w grupie zasobów, w której wdrażasz:
- Możliwość tworzenia wdrożeń. Wdrożenia są uważane za zasoby o typie
Microsoft.Resources/deployments. - Możliwość tworzenia i modyfikowania planów i aplikacji usługi App Service.
- Możliwość tworzenia i modyfikowania wystąpień usługi Application Szczegółowe informacje.
Do tej pory prawdopodobnie samodzielnie wdrożono szablony Bicep przy użyciu interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell. W przypadku korzystania z tych narzędzi zwykle używasz własnego konta użytkownika i uwierzytelniasz się za pomocą przeglądarki. Jest to nazywane użyciem własnej tożsamości. Po przesłaniu wdrożenia platforma Azure sprawdza, czy tożsamość ma niezbędne uprawnienia do wykonywania określonego szablonu Bicep.
Po przejściu do potoku należy użyć innego typu tożsamości, ponieważ sam potok uruchamia wdrożenia bez bezpośredniego zaangażowania.
Typy podmiotów zabezpieczeń
Microsoft Entra ID to usługa, która zarządza tożsamościami dla platformy Azure. Identyfikator Entra firmy Microsoft ma wiele typów tożsamości, które są również nazywane podmiotami zabezpieczeń:
- Użytkownik reprezentuje człowieka, który zwykle loguje się interaktywnie przy użyciu przeglądarki. Użytkownicy często mają dodatkowe testy zabezpieczeń do wykonania podczas logowania, takie jak uwierzytelnianie wieloskładnikowe (MFA) i dostęp warunkowy w oparciu o ich lokalizację lub sieć.
- Grupa reprezentuje kolekcję użytkowników. Grupy nie uwierzytelniają się bezpośrednio, ale zapewniają wygodny sposób przypisywania uprawnień do zestawu użytkowników razem.
- Jednostka usługi reprezentuje zautomatyzowany proces lub system, który zwykle nie ma bezpośrednio uruchomionego przez człowieka.
- Tożsamość zarządzana to specjalny typ jednostki usługi zaprojektowany w sytuacjach, w których człowiek nie jest zaangażowany w proces uwierzytelniania.
Jednostki usługi
Jednostka usługi jest typem konta. Może on zalogować się do identyfikatora Entra firmy Microsoft, ale nie ma człowieka do logowania się i interakcji z procesem uwierzytelniania. Jednostki usługi nie mają uwierzytelniania wieloskładnikowego ani podobnych zabezpieczeń, ponieważ wymagają one od osoby wykonania czegoś w celu potwierdzenia tożsamości.
W usłudze Microsoft Entra ID jednostka usługi jest identyfikowana przez identyfikator aplikacji i poświadczenia. Identyfikator aplikacji jest globalnie unikatowym identyfikatorem (GUID). W przypadku potoków poświadczenie jest zwykle silnym hasłem nazywanym kluczem. Alternatywnie możesz użyć certyfikatu jako poświadczenia.
Tożsamości zarządzane
W przeciwieństwie do innych typów jednostek usługi tożsamość zarządzana nie wymaga znajomości ani utrzymywania poświadczeń. Tożsamość zarządzana jest skojarzona z zasobem platformy Azure. Platforma Azure automatycznie zarządza poświadczeniami. Gdy zasób musi uzyskać dostęp do czegoś, platforma Azure automatycznie zaloguje się przy użyciu poświadczeń.
Tożsamości zarządzane są dostępne dla zasobów hostowanych na platformie Azure, takich jak maszyny wirtualne i aplikacje usługi App Service. Są one doskonałym sposobem na uwierzytelnienie zasobów platformy Azure w sytuacjach, takich jak automatyzacja zarządzania platformą Azure, nawiązywanie połączenia z bazami danych i odczytywanie tajnych danych z usługi Azure Key Vault. W innych scenariuszach można również używać tożsamości zarządzanych z usługą Azure Arc.
Podczas pracy z potokami zwykle nie można używać tożsamości zarządzanych. Dzieje się tak, ponieważ tożsamości zarządzane wymagają posiadania zasobów platformy Azure i zarządzania nimi, które uruchamiają wdrożenia. Podczas pracy z usługą Azure Pipelines zwykle korzystasz z udostępnionej infrastruktury udostępnianej przez firmę Microsoft.
Uwaga
Istnieją pewne sytuacje, w których potoki mogą używać tożsamości zarządzanych. W usłudze Azure Pipelines możesz utworzyć własnego agenta do uruchamiania skryptów i kodu potoku przy użyciu własnej maszyny wirtualnej opartej na platformie Azure. Ponieważ jesteś właścicielem maszyny wirtualnej, możesz przypisać jej tożsamość zarządzaną i użyć jej z potoku.
Jednak w większości przypadków potoki są uruchamiane przy użyciu hostowanego agenta, który jest serwerem zarządzanym przez firmę Microsoft. Hostowani agenci nie są obecnie zgodni z tożsamościami zarządzanymi.
Napiwek
W innych częściach rozwiązania, jeśli masz wybór między użyciem tożsamości zarządzanej lub użyciem normalnej jednostki usługi, najlepiej jest przejść z tożsamością zarządzaną. Są one łatwiejsze do pracy i są zwykle bezpieczniejsze.
Dlaczego nie możesz po prostu używać konta użytkownika?
Możesz się zastanawiać, dlaczego musisz utworzyć ten zupełnie nowy typ obiektu tylko w celu uwierzytelnienia potoku, gdy masz konta użytkowników, które działają doskonale.
Konta użytkowników nie są przeznaczone do użytku nienadzorowanego. Proces uwierzytelniania konta użytkownika często sprawdza, czy użytkownik jest jednostką, która próbuje się zalogować. Coraz częściej organizacje korzystają z dodatkowych kontroli zabezpieczeń podczas uwierzytelniania. Te testy obejmują uwierzytelnianie wieloskładnikowe, kontrole CAPTCHA oraz sprawdzanie urządzenia i sieci używanej przez użytkownika w celu zweryfikowania zasadności żądania logowania.
Potoki są przeznaczone do uruchamiania wdrożeń nawet wtedy, gdy nikt ich aktywnie nie uruchamia. W rzeczywistości większość zalet potoków wynika z faktu, że są one całkowicie zautomatyzowane i nie wymagają interakcji człowieka. Jeśli przechowujesz nazwę użytkownika i hasło w potoku i spróbujesz użyć ich do zalogowania się, prawdopodobnie nie będą działać. Nawet jeśli wydają się działać, mogą łatwo przerwać w przyszłości, jeśli identyfikator Entra firmy Microsoft lub administrator organizacji doda więcej kontroli zabezpieczeń do procesu uwierzytelniania użytkownika.
Ostrzeżenie
Jest to również zły pomysł, aby zapisać nazwę użytkownika i hasło w dowolnym miejscu, ponieważ ktoś inny może uzyskać do nich dostęp, a następnie użyć ich do personifikacji.
Z tych powodów wbudowane zadania potoku, które współdziałają z platformą Azure, nie umożliwiają podania poświadczeń konta użytkownika. Wymagają one użycia jednostki usługi.
Jak działają jednostki usługi?
Podczas pracy z jednostkami usługi lub narzędziami, takimi jak witryna Azure Portal lub interfejs API programu Microsoft Graph, może być wyświetlanych kilka różnych terminów. Chociaż nie trzeba rozumieć tych terminów tylko w celu używania jednostek usługi w potoku, warto wiedzieć trochę o pojęciach.
Jednostki usługi to funkcja identyfikatora Entra firmy Microsoft. Microsoft Entra ID to globalna usługa tożsamości. Wiele firm korzysta z identyfikatora Microsoft Entra ID, a każda firma jest nazywana dzierżawą.
Microsoft Entra ID ma pojęcie aplikacji, która reprezentuje system, kawałek oprogramowania, procesu lub innego agenta nieludzkiego. Potok wdrażania można traktować jako aplikację.
W usłudze Microsoft Entra ID aplikacje mogą wykonywać wiele czynności wykraczających poza zakres wdrożeń uwierzytelniania i potoków. Podczas tworzenia aplikacji i informujesz o niej identyfikator entra firmy Microsoft, tworzysz obiekt o nazwie rejestracja aplikacji. Rejestracja aplikacji reprezentuje aplikację w identyfikatorze Entra firmy Microsoft.
Jednostki usług i aplikacje są ściśle połączone. Za każdym razem, gdy rejestracja aplikacji jest dodawana do dzierżawy firmy Microsoft Entra, w tej dzierżawie firmy Microsoft jest tworzony obiekt jednostki usługi. Gdy spojrzysz na jednostkę usługi w witrynie Azure Portal, zobaczysz wiele innych funkcji i konfiguracji, które mogą nie wydawać się istotne. W dużej mierze wynika to z faktu, że jednostki usługi są połączone z aplikacjami.
Podczas tworzenia jednostki usługi większość używanych narzędzi tworzy również rejestrację aplikacji w tym samym czasie. Możesz więc nie zauważyć, że istnieją dwa różne obiekty.
Jeden typ jednostki usługi nie jest skojarzony z rejestracją aplikacji: tożsamością zarządzaną. Jak wspomniano wcześniej, platforma Azure zarządza konfiguracją i poświadczeniami tożsamości zarządzanej.
Uwaga
Jednostka usługi jest czasami nazywana aplikacją dla przedsiębiorstw. Niektóre narzędzia używają jednej nazwy i innych narzędzi. Możesz również zobaczyć jednostki usługi nazywane aplikacjami zarządzanymi w katalogu lokalnym, ale nie są to takie same elementy jak tożsamości zarządzane.
Podsumowując, podczas tworzenia jednostki usługi należy najpierw utworzyć rejestrację aplikacji, a następnie utworzyć jednostkę usługi dla tej rejestracji aplikacji do użycia. Większość narzędzi, z którymi pracujesz, zrobi to za Ciebie, więc nawet nie wiesz o tym. Podczas pracy z potokami wdrażania nie można używać wszystkich funkcji aplikacji firmy Microsoft Entra. Mimo to, ponieważ jednostki usługi są powiązane z aplikacjami, ta sama struktura obiektów Firmy Microsoft Entra ma zastosowanie.