Tożsamość zarządzana do uwierzytelniania bez haseł
Proszę przypisać maszynie wirtualnej lub usłudze App Service tożsamość zarządzaną przypisaną przez system, nadać jej dostęp RBAC do Key Vault i Blob Storage oraz usunąć wpisy tajne z kodu aplikacji.
Tożsamość zarządzana do uwierzytelniania bez haseł to bezpłatna lekcja Cloud & IT Cert Prep na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Cloud & IT Cert Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Problem z przechowywanymi poświadczeniami
Tradycyjnie aplikacje łączą się z usługami Azure, takimi jak Storage lub Key Vault, za pomocą connection strings lub API keys przechowywanych w plikach konfiguracyjnych albo zmiennych środowiskowych. Takie poświadczenia mogą zostać przypadkowo zatwierdzone w systemie kontroli wersji, ujawnione w dziennikach lub skradzione podczas włamania. Managed Identity eliminuje potrzebę przechowywania poświadczeń przez aplikacje — zamiast tego sam Azure wystawia i odnawia token w imieniu zasobu, a aplikacja po prostu prosi Azure o aktualny token w czasie działania.
Czym jest Managed Identity?
Managed Identity to automatycznie zarządzana jednostka usługi w Microsoft Entra ID, połączona z zasobem Azure (takim jak maszyna wirtualna, App Service lub Function App). Platforma Azure tworzy i utrzymuje poświadczenia tożsamości — regularnie je odnawiając — dzięki czemu kod nigdy nie obsługuje hasła ani sekretu. Aplikacje działające na zasobie wywołują punkt końcowy Azure Instance Metadata Service (IMDS) pod adresem http://169.254.169.254, aby uzyskać krótkotrwały token OAuth, który następnie przedstawiają usługom Azure.
# Get a token from IMDS (runs inside an Azure VM or App Service)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' \
-H 'Metadata: true'Tożsamość przypisana przez system a tożsamość przypisana przez użytkownika
Istnieją dwa typy managed identity: przypisana przez system jest powiązana z jednym zasobem Azure; jest tworzona po włączeniu jej na zasobie i automatycznie usuwana wraz z usunięciem zasobu. Przypisana przez użytkownika jest niezależną tożsamością Entra ID, którą tworzy się osobno, a następnie przypisuje do co najmniej jednego zasobu Azure. Tożsamości przypisane przez użytkownika są przydatne, gdy wiele usług (np. kilka Function Apps) musi współdzielić tę samą tożsamość i uprawnienia RBAC, ponieważ pozwalają uniknąć powielania przypisań ról.
# Enable system-assigned managed identity on an App Service
az webapp identity assign \
--resource-group myRG \
--name myWebApp
# Create and assign a user-assigned identity
az identity create --name mySharedIdentity --resource-group myRG
az webapp identity assign \
--resource-group myRG \
--name myWebApp \
--identities mySharedIdentityPrzyznawanie uprawnień RBAC
Po włączeniu managed identity należy przyznać jej uprawnienia RBAC do docelowego zasobu Azure. Aby na przykład zezwolić usłudze App Service na odczytywanie obiektów blob, należy przypisać rolę Storage Blob Data Reader managed identity usługi App Service na koncie magazynu. Przypisania RBAC są zgodne z zasadą najmniejszych uprawnień — należy przyznawać tylko minimalne uprawnienia wymagane do wykonania zadania. Nie należy przypisywać managed identity roli Owner ani Contributor, chyba że jest to absolutnie konieczne.
# Get the managed identity object ID
PRINCIPAL_ID=$(az webapp identity show \
--resource-group myRG --name myWebApp \
--query principalId --output tsv)
# Assign Storage Blob Data Reader role
az role assignment create \
--assignee $PRINCIPAL_ID \
--role 'Storage Blob Data Reader' \
--scope '/subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct'Używanie DefaultAzureCredential w kodzie
Azure SDK udostępnia klasę DefaultAzureCredential, która automatycznie wypróbowuje kolejno wiele metod uwierzytelniania: zmienne środowiskowe, workload identity, managed identity, Azure CLI, Visual Studio i inne. Gdy aplikacja działa na platformie Azure (App Service, maszyna wirtualna, Function App), DefaultAzureCredential automatycznie korzysta z managed identity bez żadnych zmian w kodzie. Lokalnie deweloperzy uwierzytelniają się za pośrednictwem swojej sesji Azure CLI. Ta jedna klasa poświadczeń działa we wszystkich środowiskach bez logiki warunkowej.
# Python example using DefaultAzureCredential
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
credential = DefaultAzureCredential()
client = BlobServiceClient(
account_url='https://mystorageacct.blob.core.windows.net',
credential=credential
)
blobs = client.get_container_client('mycontainer').list_blobs()
for blob in blobs:
print(blob.name)Managed Identity z Azure Key Vault
Typowym rozwiązaniem jest użycie managed identity w celu uzyskiwania dostępu do sekretów Azure Key Vault w czasie działania. Zamiast przechowywać hasło do bazy danych w ustawieniach aplikacji, należy zapisać je w Key Vault i nadać managed identity aplikacji rolę Key Vault Secrets User w tym magazynie. Podczas uruchamiania aplikacja pobiera sekret z Key Vault za pomocą DefaultAzureCredential. Dzięki temu rozwiązaniu sekrety nigdy nie są przechowywane w kodzie, plikach konfiguracyjnych ani zmiennych środowiskowych — znajdują się wyłącznie w Key Vault i są pobierane tymczasowo.
# Python: Read a Key Vault secret using managed identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
credential = DefaultAzureCredential()
client = SecretClient(
vault_url='https://mykeyvault.vault.azure.net/',
credential=credential
)
secret = client.get_secret('DatabasePassword')
print('Secret value retrieved successfully')Managed Identity na potrzeby dostępu do Azure SQL
Azure SQL Database obsługuje uwierzytelnianie Entra ID, co oznacza, że managed identity może uwierzytelniać się w SQL bez nazwy użytkownika i hasła. Aby je włączyć, należy ustawić administratora Entra ID na serwerze SQL, a następnie wykonać w docelowej bazie danych instrukcję CREATE USER dla nazwy wyświetlanej managed identity i nadać jej odpowiednią rolę w bazie danych. Aplikacja łączy się za pomocą DefaultAzureCredential z Azure SDK oraz tokenu dostępu ograniczonego do zakresu https://database.windows.net/, całkowicie bez użycia hasła.
-- In Azure SQL: create a user for the managed identity
CREATE USER [myWebApp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [myWebApp];
ALTER ROLE db_datawriter ADD MEMBER [myWebApp];Managed Identity dla obciążeń AKS
W usłudze Azure Kubernetes Service poszczególne pody mogą uzyskiwać tokeny managed identity za pomocą Workload Identity (następcy AAD Pod Identity). Należy utworzyć managed identity przypisaną przez użytkownika, sfederować ją z wystawcą OIDC usługi AKS, dodać adnotację do konta usługi Kubernetes, a następnie Azure Workload Identity webhook wstrzyknie wymagane zmienne środowiskowe, aby DefaultAzureCredential poda mogło uzyskać token. Rozwiązanie to rozszerza uwierzytelnianie bez haseł na mikrousługi uruchamiane w kontenerach, bez przechowywania sekretów w obiektach Kubernetes Secrets.
# Create federated identity credential for AKS workload identity
az identity federated-credential create \
--name myFederatedCredential \
--identity-name mySharedIdentity \
--resource-group myRG \
--issuer $(az aks show --resource-group myRG --name myAKS --query 'oidcIssuerProfile.issuerUrl' -o tsv) \
--subject 'system:serviceaccount:default:myapp-sa' \
--audiences 'api://AzureADTokenExchange'Audytowanie dostępu Managed Identity
Mimo że poświadczenia managed identity są niewidoczne dla deweloperów, wszystkie zdarzenia wystawiania tokenów i dostępu do zasobów są rejestrowane. Dzienniki logowania Entra ID rejestrują każde żądanie tokenu wysłane przez managed identity, w tym zasób, do którego uzyskiwany jest dostęp, czas oraz informację o powodzeniu żądania. Dzienniki aktywności Azure Storage i dzienniki inspekcji Key Vault rejestrują konkretne operacje wykonane przy użyciu tokenu. Dzienniki te są niezbędne podczas audytów bezpieczeństwa i badania incydentów związanych z managed identity.
# Query Entra ID sign-in logs for a managed identity
az monitor activity-log list \
--resource-group myRG \
--caller myWebApp \
--start-time 2024-06-01 \
--output tableMigracja z connection strings
Jeśli aplikacja obecnie korzysta z connection strings lub API keys, należy przeprowadzić migrację do managed identity w trzech krokach: Krok 1 — włączyć managed identity na zasobie obliczeniowym. Krok 2 — przypisać tej tożsamości odpowiednie role RBAC w każdej docelowej usłudze. Krok 3 — zaktualizować kod aplikacji tak, aby zamiast connection string używał DefaultAzureCredential. Po zweryfikowaniu migracji należy usunąć connection string z konfiguracji App Service i Key Vault. W nowoczesnych aplikacjach korzystających z Azure SDK migrację tę można zazwyczaj przeprowadzić przy minimalnych zmianach w kodzie.
Podsumowanie korzyści w zakresie bezpieczeństwa
Managed Identity zapewnia cztery kluczowe korzyści w zakresie bezpieczeństwa w porównaniu z uwierzytelnianiem opartym na poświadczeniach: brak przechowywania poświadczeń — nie ma niczego, co można ukraść lub przypadkowo zatwierdzić w systemie kontroli wersji; automatyczne odnawianie — Azure odnawia bazowe certyfikaty bez przestojów; uprawnienia o określonym zakresie — tożsamości otrzymują tylko wymagane role RBAC, zgodnie z zasadą najmniejszych uprawnień; pełny ślad audytowy — wszystkie próby dostępu są rejestrowane w Entra ID i dziennikach inspekcji używanej usługi. W przypadku każdej nowej integracji z usługą Azure managed identity powinna być domyślnym rozwiązaniem uwierzytelniania.
Szybkie sprawdzenie
Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.
Podsumowanie lekcji
W tej lekcji poznali Państwo: tożsamość zarządzaną, która eliminuje przechowywane dane uwierzytelniające, nadając zasobom platformy Azure automatycznie zarządzaną tożsamość Entra ID; DefaultAzureCredential z pakietu Azure SDK, który przejrzyście używa tożsamości zarządzanej na platformie Azure oraz poświadczeń dewelopera lokalnie; a także przypisania ról RBAC w usługach docelowych, które określają, do czego tożsamość ma dostęp. W następnej części omówimy Azure Service Bus, służący do rozdzielania komunikacji między komponentami aplikacji.
Często zadawane pytania
Czy lekcja „Tożsamość zarządzana do uwierzytelniania bez haseł” jest bezpłatna?
Tak — pełny tekst „Tożsamość zarządzana do uwierzytelniania bez haseł” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Cloud & IT Cert Prep, przejdź na CoddyKit PRO. Kurs Cloud & IT Cert Prep zawiera 4 lekcji w sumie.
Co nauczysz się w „Tożsamość zarządzana do uwierzytelniania bez haseł”?
Proszę przypisać maszynie wirtualnej lub usłudze App Service tożsamość zarządzaną przypisaną przez system, nadać jej dostęp RBAC do Key Vault i Blob Storage oraz usunąć wpisy tajne z kodu aplikacji. Ćwiczysz Cloud & IT Cert Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.
Czy potrzebuję doświadczenia, aby zacząć Cloud & IT Cert Prep?
Nie wymagamy żadnego doświadczenia. Cloud & IT Cert Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.
Ile czasu zajmuje lekcja „Tożsamość zarządzana do uwierzytelniania bez haseł”?
Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.
Czy mogę pisać i uruchamiać kod w tej lekcji Cloud & IT Cert Prep?
Tak. Każda lekcja Cloud & IT Cert Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.
Wszystkie lekcje w tym kursie
- Tożsamość zarządzana do uwierzytelniania bez haseł
- Azure Service Bus do komunikacji rozdzielonej
- Azure Container Apps
- Kompletny przepływ pracy dewelopera