Zrozum zasady działania 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 rurociąg 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 utworzyłeś szablon Bicep, aby wdrożyć stronę internetową swojej firmy zabawkowej. Szablon Bicep deklaruje zasoby, które obejmują plan usługi Azure App Service, aplikację i wystąpienie usługi Application Insights.
Podczas wdrażania szablonu usługa Resource Manager sprawdza, czy zasoby istnieją. Jeśli tak nie jest, Resource Manager tworzy je. 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 Insights.
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 Twoja tożsamość ma niezbędne uprawnienia do wykonywania tego, co określa Twój szablon Bicep.
Po przejściu do potoku należy posłużyć się innym rodzajem tożsamości, ponieważ potok samodzielnie uruchamia wdrożenia, bez potrzeby 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.
- Zarządzana tożsamość jest specjalnym typem podmiotu zabezpieczeń zaprojektowanym do sytuacji, w których człowiek nie jest zaangażowany w proces uwierzytelniania.
Jednostki usługi
Jednostka usługi jest typem konta. Można się zalogować do usługi Microsoft Entra ID, ale nie ma użytkownika do interakcji z procesem uwierzytelniania. Podmioty usługowe nie mają uwierzytelniania wieloskładnikowego ani podobnych zabezpieczeń, ponieważ wymagają one od osoby podjęcia działania w celu potwierdzenia swojej tożsamości.
W Microsoft Entra ID główny element usługi jest identyfikowany przez identyfikator aplikacji oraz poświadczenie. 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.
Zazwyczaj, gdy pracuje się z potokami, nie można używać tożsamości zarządzanych. Dzieje się tak, ponieważ tożsamości zarządzane wymagają, abyś posiadał i zarządzał zasobami platformy Azure, które są niezbędne do uruchamiania Twoich wdrożeń. Podczas pracy z usługą Azure Pipelines zwykle korzystasz z udostępnionej infrastruktury udostępnianej przez firmę Microsoft.
Notatka
Istnieją pewne sytuacje, w których potoki mogą używać tożsamości zarządzanych. W usłudze Azure Pipelines możesz utworzyć agenta działającego na własnym sprzęcie do uruchamiania skryptów i kodu potoku, korzystając z 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żywać z poziomu potoku.
Jednak najczęściej uruchamiasz potoki przy użyciu hostowanego agenta, który jest serwerem zarządzanym przez firmę Microsoft. Agenci hostowani 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ą łatwiejsze w obsłudze i 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.
Linie są zaprojektowane do uruchamiania wdrożeń nawet wtedy, gdy nikt ich aktywnie nie nadzoruje. W rzeczywistości większość zalet rurociągów wynika z faktu, że są one całkowicie zautomatyzowane i nie wymagają interakcji z ludźmi. Jeśli przechowujesz nazwę użytkownika i hasło w systemie potokowym i spróbujesz za ich pomocą się zalogować, prawdopodobnie nie będą działać. Nawet jeśli wydają się działać, mogą łatwo przestać działać w przyszłości, jeśli Microsoft Entra ID lub administrator Twojej organizacji wdroży 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 pozwalają na podanie poświadczeń konta użytkownika. Wymagają one użycia jednostki usługi.
Jak działają główne zasady 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.
Principały usługi to funkcja Microsoft Entra ID. Microsoft Entra ID to globalna usługa tożsamości. Wiele firm korzysta z Microsoft Entra ID, a każda firma jest nazywana dzierżawcą .
Microsoft Entra ID ma pojęcie aplikacji , która reprezentuje system, fragment oprogramowania, proces lub innego agenta niebędącego człowiekiem. Potok wdrażania można traktować jako aplikację.
W Microsoft Entra ID aplikacje mogą wykonywać wiele czynności wykraczających poza zakres uwierzytelniania i wdrożeń potoków. Podczas tworzenia aplikacji i informowania o niej Microsoft Entra ID, 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 zostanie dodana do dzierżawy firmy Microsoft Entra, w tej dzierżawie firmy Microsoft zostanie utworzona jednostka 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 obiektu głównego usługi, większość narzędzi, których używasz, tworzy również rejestrację aplikacji jednocześnie. Możesz więc nie zauważyć, że istnieją dwa różne obiekty.
Jeden typ jednostki usługi nie jest skojarzony z rejestracją aplikacji: jest to tożsamość zarządzana. Jak wspomniano wcześniej, platforma Azure zarządza konfiguracją i poświadczeniami tożsamości zarządzanej.
Notatka
Jednostka usługi jest czasami nazywana aplikacją dla przedsiębiorstw. Niektóre narzędzia używają jednej nazwy, a inne używają drugiej. Możesz również zobaczyć jednostki usługi o nazwie aplikacje zarządzane w katalogu lokalnym, ale nie są one takie same 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.