Azure Fundamentals · पाठ

पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान

किसी VM या App Service को सिस्टम-असाइन की गई प्रबंधित पहचान दें, Key Vault और Blob Storage तक RBAC पहुँच प्रदान करें और अपने अनुप्रयोग कोड से गुप्त जानकारियाँ हटाएँ।

पाठ 1, कुल 4 में से13 चरण

पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान, CoddyKit पर Azure Fundamentals का एक निःशुल्क पाठ है। यह 4 में से 1वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Azure Fundamentals सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

संग्रहीत क्रेडेंशियल की समस्या

परंपरागत रूप से, एप्लिकेशन Storage या Key Vault जैसी Azure सेवाओं से कनेक्शन स्ट्रिंग या API कुंजियों का उपयोग करके जुड़ते हैं, जिन्हें कॉन्फ़िगरेशन फ़ाइलों या पर्यावरण चर में संग्रहीत किया जाता है। ये क्रेडेंशियल गलती से source control में commit हो सकते हैं, लॉग में उजागर हो सकते हैं या किसी सुरक्षा-भंग में चोरी हो सकते हैं। Managed Identity एप्लिकेशन के लिए क्रेडेंशियल संग्रहीत करने की आवश्यकता पूरी तरह समाप्त करती है — इसके बजाय Azure स्वयं संसाधन की ओर से टोकन जारी और उसका नवीनीकरण करता है, और एप्लिकेशन रनटाइम पर Azure से वर्तमान टोकन माँगता है।

Managed Identity क्या है

Managed Identity Microsoft Entra ID में स्वचालित रूप से प्रबंधित सेवा प्रिंसिपल है, जो किसी Azure संसाधन, जैसे VM, App Service या Function App, से जुड़ा होता है। Azure प्लेटफ़ॉर्म उस पहचान के क्रेडेंशियल बनाता और बनाए रखता है — तथा नियमित रूप से उनका नवीनीकरण करता है — इसलिए आपका कोड कभी पासवर्ड या secret को संभालता नहीं है। संसाधन पर चलने वाले एप्लिकेशन Azure Instance Metadata Service (IMDS) endpoint को http://169.254.169.254 पर कॉल करके अल्पकालिक OAuth टोकन प्राप्त करते हैं, जिसे वे फिर 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'

System-assigned बनाम User-assigned

Managed Identity दो प्रकार की होती है: System-assigned किसी एक Azure संसाधन से जुड़ी होती है; इसे संसाधन पर Enable करने पर बनाया जाता है और संसाधन हटाए जाने पर अपने-आप हटा दिया जाता है। User-assigned एक स्वतंत्र Entra ID पहचान होती है, जिसे आप अलग से बनाकर एक या अधिक Azure संसाधनों से जोड़ते हैं। User-assigned पहचान तब उपयोगी होती हैं, जब कई सेवाओं, जैसे कई Function Apps, को समान पहचान और RBAC अनुमतियाँ साझा करनी हों और भूमिका असाइनमेंट दोहराने से बचना हो।

# 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 mySharedIdentity

RBAC अनुमतियाँ प्रदान करना

Managed Identity Enable करने के बाद, आपको लक्षित Azure संसाधन पर उसे RBAC अनुमतियाँ देनी होंगी। उदाहरण के लिए, किसी App Service को blobs पढ़ने की अनुमति देने के लिए, storage account पर App Service की managed identity को Storage Blob Data Reader भूमिका असाइन करें। RBAC असाइनमेंट न्यूनतम विशेषाधिकार के सिद्धांत का पालन करते हैं — केवल आवश्यक न्यूनतम अनुमतियाँ दें। जब तक बिल्कुल आवश्यक न हो, किसी managed identity को Owner या Contributor कभी असाइन न करें।

# 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'

कोड में DefaultAzureCredential का उपयोग

Azure SDK एक DefaultAzureCredential class प्रदान करता है, जो क्रम से कई प्रमाणीकरण विधियों को स्वतः आज़माती है: पर्यावरण चर, workload identity, managed identity, Azure CLI, Visual Studio और अन्य। जब आपका एप्लिकेशन Azure (App Service, VM, Function App) पर चलता है, तो DefaultAzureCredential बिना किसी कोड परिवर्तन के managed identity का स्वतः उपयोग करता है। स्थानीय रूप से, डेवलपर अपने Azure CLI session के माध्यम से प्रमाणीकरण करते हैं। यह एकल credential class सशर्त तर्क के बिना सभी परिवेशों में काम करती है।

# 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)

Azure Key Vault के साथ Managed Identity

एक सामान्य तरीका रनटाइम पर Azure Key Vault secrets तक पहुँचने के लिए managed identity का उपयोग करना है। एप्लिकेशन settings में database password संग्रहीत करने के बजाय, उसे Key Vault में रखें और ऐप की managed identity को उस vault पर Key Vault Secrets User भूमिका दें। स्टार्टअप के समय, एप्लिकेशन DefaultAzureCredential का उपयोग करके Key Vault से secret प्राप्त करता है। यह तरीका सुनिश्चित करता है कि secrets कभी कोड, कॉन्फ़िगरेशन फ़ाइलों या पर्यावरण चर में संग्रहीत न हों — वे केवल Key Vault में मौजूद रहते हैं और अस्थायी रूप से प्राप्त किए जाते हैं।

# 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')

Azure SQL तक पहुँच के लिए Managed Identity

Azure SQL Database Entra ID प्रमाणीकरण का समर्थन करता है, जिसका अर्थ है कि managed identity उपयोगकर्ता नाम/पासवर्ड के बिना SQL से प्रमाणीकरण कर सकती है। इसे Enable करने के लिए: SQL server पर Entra ID admin सेट करें, फिर managed identity के display name के लिए लक्षित database में CREATE USER statement चलाएँ और उसे उपयुक्त database भूमिका दें। एप्लिकेशन Azure SDK के DefaultAzureCredential और https://database.windows.net/ तक सीमित access token का उपयोग करके जुड़ता है — पूरी तरह पासवर्ड-रहित।

-- 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];

AKS कार्यभार के लिए Managed Identity

Azure Kubernetes Service में, अलग-अलग pods Workload Identity (AAD Pod Identity का उत्तराधिकारी) का उपयोग करके managed identity tokens प्राप्त कर सकते हैं। आप user-assigned managed identity बनाते हैं, उसे AKS OIDC issuer के साथ federate करते हैं, Kubernetes service account में annotation जोड़ते हैं, और Azure Workload Identity webhook आवश्यक environment variables inject करता है, ताकि pod का DefaultAzureCredential token प्राप्त कर सके। इससे Kubernetes Secrets objects में secrets संग्रहीत किए बिना containerised microservices तक पासवर्ड-रहित प्रमाणीकरण का विस्तार होता है।

# 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'

Managed Identity की पहुँच का ऑडिट

भले ही managed identity credentials डेवलपरों को दिखाई नहीं देते, फिर भी सभी token issuance और resource access events लॉग किए जाते हैं। Entra ID Sign-in logs managed identity द्वारा किए गए प्रत्येक token request को रिकॉर्ड करते हैं, जिसमें accessed resource, समय और request सफल हुई या नहीं, यह शामिल होता है। Azure Storage activity logs और Key Vault audit logs token का उपयोग करके किए गए विशिष्ट operations रिकॉर्ड करते हैं। Managed identities से जुड़े security audits और incident investigations के लिए ये logs आवश्यक हैं।

# 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 table

Connection Strings से स्थानांतरण

यदि आपका एप्लिकेशन वर्तमान में connection strings या API keys का उपयोग करता है, तो तीन चरणों में managed identity पर स्थानांतरित करें: Step 1 — compute resource पर managed identity Enable करें। Step 2 — प्रत्येक target service पर identity को उपयुक्त RBAC roles असाइन करें। Step 3 — connection string के बजाय DefaultAzureCredential का उपयोग करने के लिए एप्लिकेशन कोड अपडेट करें। स्थानांतरण सत्यापित हो जाने के बाद App Service configuration और Key Vault से connection string हटा दें। आधुनिक Azure SDK applications में यह स्थानांतरण आमतौर पर न्यूनतम code changes के साथ पूरा किया जा सकता है।

सुरक्षा लाभों का सारांश

Managed Identity क्रेडेंशियल-आधारित प्रमाणीकरण की तुलना में चार प्रमुख सुरक्षा लाभ प्रदान करती है: क्रेडेंशियल का कोई भंडारण नहीं — चोरी करने या गलती से commit करने के लिए कुछ नहीं। स्वचालित नवीनीकरण — Azure बिना downtime के अंतर्निहित certificates का नवीनीकरण करता है। सीमित अनुमतियाँ — identities को न्यूनतम विशेषाधिकार के सिद्धांत के अनुसार केवल आवश्यक RBAC roles दिए जाते हैं। पूर्ण ऑडिट ट्रेल — सभी access attempts Entra ID और accessed service के audit logs में दर्ज किए जाते हैं। किसी भी नई Azure service integration के लिए managed identity डिफ़ॉल्ट authentication approach होनी चाहिए।

त्वरित जाँच

इस पाठ में Microsoft Azure Fundamentals (AZ-900) की अवधारणाओं के बारे में अपनी समझ जाँचें।

पाठ का पुनरावलोकन

इस पाठ में आपने सीखा: प्रबंधित पहचान स्वचालित रूप से प्रबंधित Entra ID पहचान देकर संग्रहीत प्रमाण-पत्रों की आवश्यकता समाप्त करती है, DefaultAzureCredential में मौजूद Azure SDK Azure में पारदर्शी रूप से प्रबंधित पहचान और स्थानीय रूप से डेवलपर प्रमाण-पत्रों का उपयोग करता है, और लक्षित सेवाओं पर RBAC भूमिका असाइनमेंट यह नियंत्रित करते हैं कि पहचान किन संसाधनों तक पहुँच सकती है। अगले पाठ में हम एप्लिकेशन के घटकों के बीच अलग-अलग संदेश-व्यवस्था के लिए Azure Service Bus का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Azure Fundamentals सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
30
पाठ
120

अक्सर पूछे जाने वाले प्रश्न

क्या “पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान” पाठ निःशुल्क है?

हाँ—“पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Azure Fundamentals पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान” में मैं क्या सीखूँगा?

किसी VM या App Service को सिस्टम-असाइन की गई प्रबंधित पहचान दें, Key Vault और Blob Storage तक RBAC पहुँच प्रदान करें और अपने अनुप्रयोग कोड से गुप्त जानकारियाँ हटाएँ। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Azure Fundamentals का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Azure Fundamentals शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Azure Fundamentals शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 1वाँ पाठ है।

“पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Azure Fundamentals पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Azure Fundamentals पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. पासवर्ड-रहित प्रमाणीकरण के लिए प्रबंधित पहचान
  2. अलग किए गए संदेशों के लिए Azure Service Bus
  3. Azure Container Apps
  4. डेवलपर का आरंभ से अंत तक कार्यप्रवाह
← Azure Fundamentals पर वापस जाएँ