Podcast #2 Azure Managed Identity

W drugim odcinku mojego podcastu opowiem Ci o tym czym jest Managed Identity w Azure.

Treści i linki wymienione w podcaście

Czym jest Managed Identity? Dokumentacja Microsoft: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview

Serwisy na których można włączyć Managed Identity:
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities

Serwisy, do których można uzyskać dostęp za pomocą Azure Active Directory, czyli między innymi Managed Identity: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/services-support-managed-identities#azure-services-that-support-azure-ad-authentication

Tutoriale jak używać Managed Identity

• Używanie Managed Identity na VM: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-ua-arm
• Managed Identity dostęp do KeyVault: https://docs.microsoft.com/en-us/azure/key-vault/general/managed-identity

Kursy związane z Managed Identity:

• https://www.pluralsight.com/courses/microsoft-azure-resources-managed-identities-implementing
• https://www.pluralsight.com/courses/microsoft-azure-active-directory-managing-identities

Zapraszam Cię do subskrypcji mojego podcastu:

Transkrypcja

Jeśli pomyślimy o chmurze, musimy myśleć o jej zabezpieczeniach. Bardzo często w systemach czy aplikacjach w chmurze wykorzystujemy dekompozycje na wiele różnych kawałków systemu. Wynika to z charakterystyki samej chmury. Mamy wyspecjalizowane usługi dostarczane przez dostawcę chmury. Przykładem takiego serwisu jest usługa przechowywania plików (Azure Blob Storage, czy AWS S3), czy przechowywanie poufnych danych takich jak hasła, czy klucze dostępowe). Mamy również procesy, które działają w innym modelu niż ciągły. Nie wymagają więc hostowania na maszynach wirtualnych, czy App Service. Możemy wykorzystać rozwiązania serverless.

Przez wykorzystanie takiej liczby serwisów budowane rozwiązanie jest tańsze, czy mniej złożone. Ale przy takiej dekompozycji pomiędzy tymi wszystkimi komponentami następuje komunikacja. A wiadomo, że przesyłanie, czy dostęp do danych, szczególnie wrażliwych musi być odpowiednio zabezpieczony.

Co to jest managed identity?
Managed Identity, nazywało się kiedyś MSI Managed Service Identity. Może rozbiję ten termin na dwie części. Najpierw zajmijmy się tą drugą: Identity, czy Service Identity w starej nazwie. Identity, czyli tożsamość. Tożsamość aplikacji w Azure reprezentowana jest przez tak zwane Service Principal. Żeby uprościć ten koncept pozwolę sobie porównać service principala do użytkownika. Użytkownik jest przypisany do osoby, natomiast service principal to taki użytkownik dla aplikacji. Service principal swój identyfikator Application Id lub inaczej Client Id, czyli login w odniesieniu do użytkownika, oraz hasło, które dla service principal nazywa się client secret lub client certificate.

Najpierw omówmy sobie działanie dostępów do serwisów w Azure.
Mamy dwie aplikacje: aplikacja numer jeden która chce uzyskać dostęp do aplikacji, lub zasobu numer dwa.
Aplikacja numer jeden udaje się do Azure Active Directory, prosząc o token poświadczający jej tożsamość. Token ten dodawany jest do zapytania wysyłanego do aplikacji numer dwa. Aplikacja numer dwa strzela do Azure Active Directory w celu weryfikacji poprawności tokenu, który przesłała aplikacja numer jeden. Jeżeli token jest poprawny I aplikacja jeden ma odpowiednią rolę aplikacja dwa wysyła odpowiedź aplikacji jeden.

W flow, które omówiłem przed chwilą nie powiedziałem o jednej rzeczy, Są nią dane uwierzytelniające aplikację numer jeden podczas uzyskiwania tokenu z Azure Active Directory. Gdzie one są przechowywane? Najprościej byłoby zapisac je w App Settingsach. Jednak nie sądzę, żebyś trzymał swoje hasła niezabezpieczone w notatniku. Dobrym pomysłem jest trzymanie danych dostępowych w bezpiecznym miejscu. Takim miejscem w przypadku Azure jest Key Vault. Jednak dalej Application Id oraz client secret (czyli login I hasło dla service principala) musimy trzymać w App Settings. Więc problem pozostaje

Więc teraz wracamy do pytania sprzed chwili: co to jest managed identity?
Drugą część nazwy wyjaśniłem już przed chwilą. Zostało pierwsze słowo nazwy, czyli Managed, które oznacza zarządzany. Managed Identity jest zarządzany przez Azure Active Directory. Jest on bezpośrednio związany z serwisem dla którego został włączony. Po włączeniu tej funkcji, Azure Active Directory tworzy service principala przywiązanego bezpośrednio do danej usługi. W momencie usuwania serwisu, service principal przywiązany do niej za pomocą Managed Identity jest również usuwany.

Natomiast najważniejszą kwestią w kontekście Managed Identity jest fakt, że nie potrzebuje ona żadnego hasła, czyli client secret lub client certificate. Wynika to z faktu, że service principal utworzony dzięki managed identity jest przywiązany nierozerwalnie do danej usługi. Również tylko dana usługa ma dostęp do danego service principala. Więc nikt inny nie może wygenerować tokenu za jego pomocą.

Dzięki managed identity nie trzeba już korzystać z kluczy dostępowych do Key Vault, Azure Storage, czy connection string do Azure SQL. Mając aplikację działającą na usłudze z włączonym Managed Identity możemy uzyskiwać dostęp do innych usług jak I również naszych aplikacji zabezpieczonych za pomocą Azure Active Directory bez potrzeby używania żadnych jawnych haseł.

Użycie Managed Identity zamiast innych metod dostępu do usług Azure wymaga od programisty przerobienia kodu. Jak wygląda implementacja systemu, który używa Managed Identity przy dostępie do usług Azure możesz zobaczyć w projekcie AAD-Access, który stworzyłem. Link do niego znajdziesz w opisie odcinka.

Pytanie jak uzyskiwać dostęp do serwisów I testować połączenia do serwisów ze środowiska lokalnego? Do tego można użyć Azure CLI, lub Visual Studio. Token, który zapisuje Azure CLI lub Visual Studio przy logowaniu na konto użytkownika jest odczytywany przez aplikację używającej Managed Identity. Użytkownik, który chce uzyskać dostęp do danego serwisu musi mieć przypisaną w niej odpowiednią rolę. Link do kodu w C#, który realizuje pobieranie tokenu z Azure Active Directory znajduje się w notatkach do tego odcinka.

Ostatnią kwestią, która chcę poruszyć jest to do jakie usługi wspierają użycie Managed Identity oraz do jakich usług Azure możemy uzyskiwać dostęp za pomocą Managed Identity. Na czas nagrywania tego odcinka podcastu Managed Identity jest dostępne dla usług: App Service, Functions, Virtual Machines I VM Scale Sets, Data Factory, API Management. Link do pełnej listy możesz znaleźć w opisie odcinka.

Również w opisie odcinka znajdziesz link do listy usług do których dostęp można uzyskiwać za pomocą Azure Active Directory, czyli między innymi za pomocą Service Principala przypisanego do serwisu za pomocą Managed Identity.

W tym odcinku skupiłem sie na Managed Identity Service Assigned. Jest również drugi rodzaj Managed Identity, czyli user Assigned. Część rzeczy, które powiedziałem w tym podcaście jest wspólna dla obydwu typów ale nie wszystkie.

Jeżeli chcesz wiedzieć więcej o Managed Identity w notatkach do odcinka zamieszczę linki do dokumentacji, kursów i artykułów o tej tematyce.