क्लाउड पहचान के रूप में Kubernetes पॉड: EKS IRSA बनाम AKS Workload Identity

AWS और Azure दोनों एक ही समस्या को एक ही तरीके से हल करते हैं: एक पॉड क्लाउड API को स्वयं के रूप में प्रमाणित करता है, एक अल्पकालिक टोकन और बिना किसी संग्रहीत रहस्य के, अपने Kubernetes ServiceAccount को एक फेडरेटेड क्लाउड पहचान में बदलकर। AWS पर यह सुविधा IRSA (IAM Roles for Service Accounts) है; Azure पर यह Microsoft Entra Workload Identity (अप्रचलित aad-pod-identity का उत्तराधिकारी) है। अंदरूनी तौर पर दोनों एक ही OIDC फेडरेशन ट्रिक हैं, और चलने वाले पुर्जे लगभग एक-से-एक संरेखित होते हैं।

संक्षिप्त संस्करण, यदि आप केवल एक पैराग्राफ पढ़ते हैं: क्लस्टर एक OpenID Connect जारीकर्ता बन जाता है जो प्रत्येक पॉड के ServiceAccount के लिए एक टोकन पर हस्ताक्षर करता है; क्लाउड का पहचान प्रदाता उस जारीकर्ता पर भरोसा करता है और टोकन को एक पहचान तक सीमित वास्तविक क्लाउड क्रेडेंशियल के लिए एक्सचेंज करता है। AWS पहचान को एक IAM role कहता है और इसे एक ट्रस्ट पॉलिसी के साथ नियंत्रित करता है; Azure इसे एक user-assigned managed identity कहता है और इसे एक फेडरेटेड पहचान क्रेडेंशियल के साथ नियंत्रित करता है। system:serviceaccount:<namespace>:<name> विषय स्ट्रिंग दोनों पर मुख्य आधार है। तीन चीजें इतनी अलग हैं कि आपको परेशान कर सकती हैं: Azure "OIDC प्रदाता" को दो अलग-अलग क्लस्टर टॉगल में विभाजित करता है जो दोनों डिफ़ॉल्ट रूप से बंद होते हैं, Azure अतिरिक्त रूप से पॉड पर एक लेबल की आवश्यकता होती है, और आपके कंटेनर इमेज को खींचना दोनों क्लाउड पर आपकी वर्कलोड पहचान से एक अलग पहचान है।

दोनों द्वारा हल की गई समस्या

फेडरेशन से पहले, एक पॉड को क्लाउड अनुमतियाँ देने का मतलब बुरे विकल्प थे: एक स्थिर एक्सेस कुंजी को इमेज या Secret में डालना (लीक, रोटेशन का दर्द), या पूरे नोड को अनुमति देना ताकि उस पर हर पॉड इसे विरासत में प्राप्त करे (कोई अलगाव नहीं, अत्यधिक ओवर-स्कोपेड)। AWS-साइड के स्टॉपगैप kube2iam और kiam जैसे नोड-IMDS इंटरसेप्टर थे; Azure-साइड वाला aad-pod-identity था। वे सभी नोड की पहचान को प्रॉक्सी करते थे और जटिल तथा रेस-प्रोन थे।

फेडरेशन इसे क्रिप्टोग्राफिक ट्रस्ट से बदल देता है। kubelet एक हस्ताक्षरित, अल्पकालिक OIDC टोकन को पॉड में प्रोजेक्ट करता है, जो पॉड के ServiceAccount तक सीमित होता है। क्लाउड IdP क्लस्टर की प्रकाशित सार्वजनिक कुंजियों के विरुद्ध उस टोकन के हस्ताक्षर को सत्यापित करता है और, यदि टोकन का जारीकर्ता, विषय और दर्शक आपके द्वारा कॉन्फ़िगर किए गए ट्रस्ट नियम से मेल खाते हैं, तो ठीक एक क्लाउड पहचान के लिए क्रेडेंशियल वापस करता है। कहीं भी कोई रहस्य संग्रहीत नहीं होता है; प्रोजेक्टेड टोकन स्वतः घूमता है (डिफ़ॉल्ट जीवनकाल लगभग एक घंटा) और क्लस्टर के बाहर बेकार है।

साझा तंत्र: OIDC फेडरेशन

प्रत्येक वर्कलोड-पहचान सेटअप, किसी भी क्लाउड पर, एक ही ट्रस्ट त्रिकोण है:

1. क्लस्टर एक OIDC जारीकर्ता है। यह <issuer-url>/.well-known/openid-configuration पर एक डिस्कवरी दस्तावेज़ और सार्वजनिक कुंजियों के साथ एक JWKS एंडपॉइंट को उजागर करता है जिसके साथ यह ServiceAccount टोकन पर हस्ताक्षर करता है। वह जारीकर्ता URL ट्रस्ट एंकर है।
2. क्लाउड IdP उस जारीकर्ता पर भरोसा करता है एक विशिष्ट (subject, audience) जोड़ी के लिए। विषय यह पहचानता है कि कौन सा ServiceAccount, और दर्शक यह पहचानता है कि टोकन किसके लिए है।
3. वर्कलोड प्रोजेक्टेड टोकन को क्लाउड क्रेडेंशियल के लिए एक्सचेंज करता है। SDK kubelet द्वारा प्रोजेक्ट की गई टोकन फ़ाइल को पढ़ता है, इसे क्लाउड के टोकन एंडपॉइंट पर प्रस्तुत करता है, और एक एकल क्लाउड पहचान के लिए अल्पकालिक क्रेडेंशियल प्राप्त करता है।

बाकी सब नामकरण है। यहाँ नक्शा है, पंक्ति दर पंक्ति चला गया।

एक-से-एक मैप

• Kubernetes पक्ष। AWS पर आप ServiceAccount को eks.amazonaws.com/role-arn: <role arn> के साथ एनोटेट करते हैं। Azure पर आप इसे azure.workload.identity/client-id: <managed identity client id> के साथ एनोटेट करते हैं और पॉड को azure.workload.identity/use: "true" के साथ लेबल करते हैं। दोनों पॉड को एक क्लाउड पहचान पर इंगित करते हैं; Azure को अतिरिक्त पॉड लेबल की आवश्यकता होती है (नीचे इस पर और अधिक)।
• "OIDC प्रदाता।" AWS पर यह EKS क्लस्टर का OIDC जारीकर्ता है जो IAM में एक बार OIDC पहचान प्रदाता के रूप में पंजीकृत होता है। Azure पर यह दो क्लस्टर सेटिंग्स हैं: OIDC जारीकर्ता (oidcIssuerProfile.enabled) जो जारीकर्ता URL और हस्ताक्षर कुंजियों को प्रकाशित करता है, और वर्कलोड-पहचान ऐड-ऑन (securityProfile.workloadIdentity.enabled), एक म्यूटेटिंग एडमिशन वेबहुक। दोनों चालू होने चाहिए।
• पहचान। AWS: एक IAM role। Azure: एक user-assigned managed identity (UAMI)। यह वह ऑब्जेक्ट है जो पॉड बन जाता है।
• ट्रस्ट नियम। AWS: IAM role की ट्रस्ट पॉलिसी OIDC प्रदाता को फेडरेट करती है और sub = system:serviceaccount:<ns>:<sa> और aud = sts.amazonaws.com को पिन करती है। Azure: UAMI पर एक फेडरेटेड पहचान क्रेडेंशियल जिसमें issuer = <cluster OIDC issuer url>, subject = system:serviceaccount:<ns>:<sa>, और audience = api://AzureADTokenExchange होता है। वही तीन फ़ील्ड, अलग-अलग स्थान।
• अनुमतियाँ। AWS: भूमिका से जुड़ी एक IAM policy (इस S3 बकेट को पढ़ें, इस ECR रेपो से खींचें)। Azure: लक्ष्य संसाधनों पर RBAC role assignments (Key Vault Secrets User, Storage Blob Data Reader, AcrPull, ...)। यह गहरा दार्शनिक विभाजन है - AWS पहचान से एक नीति जोड़ता है; Azure संसाधन के दायरे में एक भूमिका प्रदान करता है।
• एक्सचेंज। AWS: SDK प्रोजेक्टेड टोकन के साथ sts:AssumeRoleWithWebIdentity को कॉल करता है। Azure: SDK DefaultAzureCredential / WorkloadIdentityCredential के माध्यम से एक Entra टोकन एक्सचेंज करता है, प्रोजेक्टेड टोकन को एक क्लाइंट असर्शन के रूप में प्रस्तुत करता है। दोनों अल्पकालिक क्रेडेंशियल प्रदान करते हैं, दोनों को आपके कोड में शून्य रहस्य सामग्री की आवश्यकता होती है।

इस पोस्ट का शेष भाग प्रत्येक क्लाउड को अंत तक चलता है, फिर उन अंतरों पर ध्यान केंद्रित करता है जो वास्तव में लोगों को परेशान करते हैं।

वॉक-थ्रू: AWS EKS IRSA, अंत तक

टुकड़े, जिस क्रम में विश्वास प्रवाहित होता है:

1. क्लस्टर OIDC जारीकर्ता। प्रत्येक EKS क्लस्टर में एक होता है, जैसे https://oidc.eks.<region>.amazonaws.com/id/<hash> URL पर। आप इसे IAM में एक OIDC पहचान प्रदाता के रूप में एक बार पंजीकृत करते हैं ताकि IAM इसके द्वारा हस्ताक्षरित टोकन पर भरोसा करेगा।

2. IAM role और इसकी ट्रस्ट पॉलिसी। ट्रस्ट पॉलिसी वह है जो भूमिका को एक विशिष्ट ServiceAccount द्वारा ग्रहण करने योग्य बनाती है और कुछ भी नहीं:

{
  "Effect": "Allow",
  "Principal": { "Federated": "arn:aws:iam::<account>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/<hash>" },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "oidc.eks.<region>.amazonaws.com/id/<hash>:sub": "system:serviceaccount:apps:checkout",
      "oidc.eks.<region>.amazonaws.com/id/<hash>:aud": "sts.amazonaws.com"
    }
  }
}

दोनों :sub और :aud को पिन करें। केवल जारीकर्ता को पिन करने से क्लस्टर में कोई भी ServiceAccount भूमिका ग्रहण कर पाएगा

• एक क्लासिक ओवर-ट्रस्ट बग।

3. IAM policy। भूमिका से जुड़ी एक सामान्य पहचान-आधारित नीति वह प्रदान करती है जिसकी ऐप को वास्तव में आवश्यकता होती है (s3:GetObject एक बकेट पर, ecr:GetDownloadUrlForLayer, और इसी तरह)।

4. ServiceAccount। एक एनोटेशन के साथ एक सादा ServiceAccount:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: checkout
  namespace: apps
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<account>:role/checkout

5. प्रोजेक्शन। EKS क्लस्टर में निर्मित Pod Identity Webhook के साथ आता है। जब एक पॉड एक एनोटेट किए गए ServiceAccount का उपयोग करता है, तो वेबहुक इसे म्यूटेट करता है: यह AWS_ROLE_ARN और AWS_WEB_IDENTITY_TOKEN_FILE env vars को इंजेक्ट करता है और एक प्रोजेक्टेड टोकन वॉल्यूम (दर्शक sts.amazonaws.com, स्वतः-घूमने वाला) माउंट करता है। आप पॉड को लेबल नहीं करते हैं; SA एनोटेशन पर्याप्त है।

6. एक्सचेंज। AWS SDK की डिफ़ॉल्ट क्रेडेंशियल चेन AWS_WEB_IDENTITY_TOKEN_FILE को नोटिस करती है, टोकन के साथ sts:AssumeRoleWithWebIdentity को कॉल करती है, और लौटाए गए अल्पकालिक क्रेडेंशियल को कैश करती है। आपका कोड केवल boto3.client("s3") है - कोई क्रेडेंशियल हैंडलिंग बिल्कुल नहीं।

नया विकल्प: EKS Pod Identity (2023) प्रति-क्लस्टर IAM OIDC प्रदाता और प्रति-भूमिका ट्रस्ट पॉलिसी के बजाय एक ऑन-क्लस्टर एजेंट और एक एसोसिएशन API के माध्यम से वही काम करता है। बड़े पैमाने पर इसे संचालित करना आसान है लेकिन यह AWS-विशिष्ट प्लंबिंग है; ऊपर दिया गया OIDC-फेडरेशन मॉडल वह है जो Azure से साफ-साफ मैप करता है, इसलिए क्रॉस-क्लाउड तुलना के लिए इसे अपने दिमाग में रखना चाहिए।

वॉक-थ्रू: Azure AKS Workload Identity, अंत तक

वही ट्रस्ट फ्लो, Azure संज्ञाएँ:

1. दो क्लस्टर टॉगल। OIDC जारीकर्ता (oidcIssuerProfile.enabled = true) को चालू करें, जो https://<region>.oic.prod-aks.azure.com/<tenant>/<guid>/ जैसे जारीकर्ता URL को प्रकाशित करता है, और वर्कलोड-पहचान ऐड-ऑन (securityProfile.workloadIdentity.enabled = true) को चालू करें, जो म्यूटेटिंग वेबहुक स्थापित करता है। दोनों एक नए क्लस्टर पर डिफ़ॉल्ट रूप से बंद होते हैं, और क्लस्टर का oidcIssuerUrl तब तक शून्य होता है जब तक पहला सक्षम नहीं हो जाता। उन्हें सक्षम करना एक इन-प्लेस अपडेट है, न कि फिर से बनाना।

2. प्रबंधित पहचान। एक user-assigned managed identity बनाएँ। (फेडरेटेड क्रेडेंशियल केवल user-assigned पहचानों से जुड़ते हैं, न कि system-assigned वालों से।) इसका client id वह है जिसे ServiceAccount संदर्भित करेगा।

3. फेडरेटेड पहचान क्रेडेंशियल। यह ट्रस्ट नियम है, UAMI पर एक चाइल्ड ऑब्जेक्ट:

issuer:   https://<region>.oic.prod-aks.azure.com/<tenant>/<guid>/
subject:  system:serviceaccount:apps:checkout
audience: api://AzureADTokenExchange

AWS के समान विषय व्याकरण और एक अलग निश्चित दर्शक पर ध्यान दें।

4. RBAC। UAMI के प्रिंसिपल को लक्ष्य संसाधनों पर आवश्यक भूमिकाएँ प्रदान करें: एक वॉल्ट पर Key Vault Secrets User, एक स्टोरेज अकाउंट पर Storage Blob Data Reader, एक रजिस्ट्री पर AcrPull यदि ऐप स्वयं रजिस्ट्री डेटा प्लेन को कॉल करता है। पहचान पर कोई नीति दस्तावेज़ नहीं है; एक्सेस प्रत्येक संसाधन के दायरे में भूमिका असाइनमेंट है।

5. ServiceAccount और पॉड लेबल। ServiceAccount क्लाइंट-आईडी एनोटेशन रखता है, और - यह वह हिस्सा है जिसे AWS के लोग भूल जाते हैं - पॉड को भी लेबल किया जाना चाहिए:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: checkout
  namespace: apps
  annotations:
    azure.workload.identity/client-id: <uami-client-id>
---
# in the Deployment's pod template:
metadata:
  labels:
    azure.workload.identity/use: "true"   # required on the POD, not just the SA
spec:
  serviceAccountName: checkout

6. प्रोजेक्शन। ऐड-ऑन का वेबहुक केवल उन पॉड को म्यूटेट करता है जिनमें azure.workload.identity/use: "true" लेबल होता है। जब यह सक्रिय होता है, तो यह AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, और AZURE_AUTHORITY_HOST को इंजेक्ट करता है, और api://AzureADTokenExchange दर्शक के साथ एक टोकन प्रोजेक्ट करता है।

7. एक्सचेंज। DefaultAzureCredential() (या स्पष्ट WorkloadIdentityCredential) उन env vars को पढ़ता है, प्रोजेक्टेड टोकन को Entra ID को एक क्लाइंट असर्शन के रूप में प्रस्तुत करता है, और लक्ष्य संसाधन के लिए एक एक्सेस टोकन वापस प्राप्त करता है। एक Key Vault रीड Python में azure.identity.DefaultAzureCredential() प्लस SecretClient है, या TypeScript में new DefaultAzureCredential() प्लस @azure/keyvault-secrets है - और फिर से, कोड में कहीं भी कोई रहस्य नहीं है।

विषय स्ट्रिंग मुख्य आधार है (दोनों क्लाउड पर)

एकल मान जो दोनों क्लाउड पर बिल्कुल मेल खाना चाहिए, वह टोकन विषय है:

system:serviceaccount:<namespace>:<serviceaccount-name>

kubelet पॉड के वास्तविक namespace और ServiceAccount के आधार पर इसे टोकन में स्टैंप करता है। ट्रस्ट नियम (AWS पर IAM ट्रस्ट पॉलिसी, Azure पर फेडरेटेड क्रेडेंशियल) उस स्ट्रिंग को पिन करता है जिसे वह स्वीकार करेगा। यदि ऐप apps namespace में ServiceAccount checkout के तहत चलता है, तो ट्रस्ट नियम को system:serviceaccount:apps:checkout कहना चाहिए - अक्षर-दर-अक्षर। सबसे आम "यह किसी के रूप में प्रमाणित नहीं होता है" विफलता यहाँ एक बेमेल है: चार्ट एक अलग namespace में तैनात किया गया, ServiceAccount को ऐप नाम के बजाय रिलीज़ नाम मिला, या किसी ने default ServiceAccount मान लिया। जब फेडरेशन चुपचाप विफल हो जाता है, तो पहले विषय की जाँच करें।

दर्शक दूसरा पिन किया गया फ़ील्ड है, और यह प्रति क्लाउड एक निश्चित स्थिरांक है: AWS पर sts.amazonaws.com, Azure पर api://AzureADTokenExchange। आप इसे शायद ही कभी बदलते हैं, लेकिन ट्रस्ट नियम और प्रोजेक्टेड टोकन को इस पर सहमत होना चाहिए।

चार अंतर जो वास्तव में आपको परेशान करेंगे

1. Azure "OIDC प्रदाता" को दो टॉगल में विभाजित करता है, और दोनों डिफ़ॉल्ट रूप से बंद होते हैं। EKS पर पॉड-पहचान वेबहुक क्लस्टर में निर्मित होता है और एकमात्र एक-बार का कदम IAM में OIDC प्रदाता को पंजीकृत करना है। AKS पर आपको OIDC जारीकर्ता और वर्कलोड-पहचान ऐड-ऑन को अलग से सक्षम करना होगा; ऐड-ऑन को भूल जाने पर जारीकर्ता अभी भी टोकन प्रकाशित करता है लेकिन कुछ भी उन्हें पॉड में प्रोजेक्ट नहीं करता है, इसलिए ऐप को कोई AZURE_* env vars नहीं दिखते हैं और DefaultAzureCredential चुपचाप अगले क्रेडेंशियल स्रोत पर चला जाता है। दोनों को सक्षम करें, और याद रखें कि जारीकर्ता URL मौजूद होने तक फेडरेटेड क्रेडेंशियल नहीं बनाया जा सकता है।

2. Azure को पॉड पर एक लेबल की आवश्यकता होती है, न कि केवल ServiceAccount पर एक एनोटेशन की। AKS वेबहुक पॉड पर azure.workload.identity/use: "true" लेबल से कुंजी लेता है (केवल ServiceAccount एनोटेशन पर्याप्त नहीं है)। IRSA का वेबहुक ServiceAccount एनोटेशन से कुंजी लेता है और उसे किसी पॉड लेबल की आवश्यकता नहीं होती है। यह Azure-साइड की सबसे आम गलती है: ServiceAccount सही दिखता है, लेकिन पॉड टेम्पलेट लेबल भूल गया, इसलिए कोई टोकन प्रोजेक्ट नहीं किया जाता है।

3. इमेज खींचना वर्कलोड पहचान से एक अलग पहचान है - दोनों क्लाउड पर। इमेज पुल नोड/kubelet पहचान का काम है: AKS पर kubelet पहचान AcrPull रखती है; EKS पर नोड समूह की इंस्टेंस भूमिका AmazonEC2ContainerRegistryReadOnly रखती है (या आप पुल सीक्रेट्स का उपयोग करते हैं)। वर्कलोड पहचान की आवश्यकता केवल तभी होती है जब ऐप कोड एक क्लाउड API को कॉल करता है (एक रहस्य पढ़ें, एक बकेट सूचीबद्ध करें, रजिस्ट्री के डेटा प्लेन को कॉल करें)। एक शुद्ध HTTP सेवा जो कभी क्लाउड SDK से बात नहीं करती है, उसे किसी भी वर्कलोड पहचान की आवश्यकता नहीं होती है - और इसके विपरीत, एक वर्कलोड पहचान AcrPull प्रदान करने से इमेज पुल के लिए कुछ भी नहीं होता है, क्योंकि पुल ऐप (और इसके फेडरेटेड टोकन) के चलने से पहले होता है।

4. अनुमतियाँ अलग तरह से संलग्न होती हैं। AWS भूमिका से एक IAM policy जोड़ता है - अनुमति पहचान के साथ यात्रा करती है। Azure लक्ष्य संसाधन के दायरे में RBAC role assignments प्रदान करता है - अनुदान एक्सेस की जा रही चीज़ पर रहता है, पहचान पर नहीं। वही अंतिम स्थिति (यह पॉड उस वॉल्ट को पढ़ सकता है), लेकिन आप इसे ऑडिट करने के लिए अलग-अलग जगहों पर देखते हैं: AWS पर, भूमिका की संलग्न नीतियों को पढ़ें; Azure पर, संसाधन पर भूमिका असाइनमेंट (या पहचान के असाइनमेंट विभिन्न स्कोपों में) सूचीबद्ध करें। यह दोनों क्लाउड के बीच व्यापक IAM-बनाम-RBAC अंतर को दर्शाता है।

इंजेक्टेड वातावरण कैसा दिखता है

दोनों वेबहुक SDK को env vars और एक प्रोजेक्टेड फ़ाइल के माध्यम से वह सब कुछ सौंपते हैं जिसकी उसे आवश्यकता होती है, ताकि ऐप कोड किसी रहस्य और किसी क्लाउड-विशिष्ट क्रेडेंशियल लॉजिक को संदर्भित न करे:

• AWS: AWS_ROLE_ARN, AWS_WEB_IDENTITY_TOKEN_FILE, AWS_REGION। डिफ़ॉल्ट क्रेडेंशियल चेन आपके लिए AssumeRoleWithWebIdentity को कॉल करती है।
• Azure: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE, AZURE_AUTHORITY_HOST। DefaultAzureCredential आपके लिए Entra एक्सचेंज करता है।

दोनों मामलों में प्रोजेक्टेड टोकन फ़ाइल अल्पकालिक होती है और kubelet द्वारा स्वतः घूमती है; SDK इसे फिर से पढ़ता है और क्लाउड क्रेडेंशियल को पारदर्शी रूप से ताज़ा करता है। घुमाने के लिए कुछ भी नहीं है, स्टोर करने के लिए कुछ भी नहीं है, और लीक करने के लिए कुछ भी नहीं है।

एक डिबगिंग चेकलिस्ट जो दोनों क्लाउड पर काम करती है

जब एक पॉड "प्रमाणीकृत नहीं कर सकता," तो ट्रस्ट चेन को क्रम में चलें:

1. क्लस्टर जारीकर्ता चालू है? पुष्टि करें कि OIDC जारीकर्ता URL मौजूद है (AKS: दोनों टॉगल सही; EKS: IAM OIDC प्रदाता पंजीकृत है)। कोई जारीकर्ता नहीं, कोई ट्रस्ट एंकर नहीं।
2. प्रोजेक्शन हो रहा है? पॉड में exec करें और टोकन फ़ाइल और env vars (AWS_WEB_IDENTITY_TOKEN_FILE / AZURE_FEDERATED_TOKEN_FILE) की जाँच करें। Azure पर गुम होने का आमतौर पर मतलब है कि पॉड लेबल अनुपस्थित है या ऐड-ऑन बंद है।
3. विषय मेल खाता है? ट्रस्ट नियम के विषय की तुलना system:serviceaccount:<actual-namespace>:<actual-sa> से करें। यह सबसे लगातार विफलता है।
4. दर्शक मेल खाता है? sts.amazonaws.com / api://AzureADTokenExchange, दोनों पक्षों पर सहमत।
5. अनुमतियाँ? पहचान हल होने के बाद ही: भूमिका पर IAM policy, या लक्ष्य संसाधन पर RBAC role assignment। यहाँ एक खाली परिणाम एक प्राधिकरण विफलता है, प्रमाणीकरण विफलता नहीं - एक उपयोगी अंतर, क्योंकि यह आपको बताता है कि फेडरेशन स्वयं काम कर रहा है।

कौन से सर्टिफिकेशन इसे ड्रिल करते हैं

वर्कलोड पहचान वहीं बैठती है जहाँ Kubernetes, क्लाउड IAM, और OIDC फेडरेशन मिलते हैं, इसलिए यह तीन परीक्षा ट्रैकों में दिखाई देती है। यदि आपके पास पहले से ही एक क्लाउड का क्रेडेंशियल है, तो दूसरे क्लाउड पर वही अवधारणा एक छोटी छलांग है।

AWS पक्ष पर:

• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM roles, EKS, और पहचानों को क्लाउड अनुमतियाँ कैसे मिलती हैं।
• AWS Certified Security - Specialty (SCS-C03) - IAM trust policies, OIDC फेडरेशन, और न्यूनतम-विशेषाधिकार स्कोपिंग (ठीक IRSA ट्रस्ट चेन)।

Azure पक्ष पर:

• Microsoft Azure Administrator Associate (AZ-104) - AKS, managed identities, और RBAC role assignments।
• Microsoft Azure Security Engineer Associate (AZ-500) - Entra ID, managed identities, फेडरेटेड क्रेडेंशियल, और RBAC गहराई।

Kubernetes पक्ष पर:

• CNCF Certified Kubernetes Administrator (CKA) - ServiceAccounts, प्रोजेक्टेड टोकन, और पॉड स्पेक्स।
• CNCF Certified Kubernetes Security Specialist (CKS) - ServiceAccount टोकन सुरक्षा, न्यूनतम विशेषाधिकार, और स्थिर-रहस्य एक्सपोजर को कम करना।

निचला रेखा

IRSA और AKS Workload Identity अलग-अलग शब्दावली पहने हुए एक ही विचार हैं: क्लस्टर एक ServiceAccount के लिए एक अल्पकालिक OIDC टोकन पर हस्ताक्षर करता है, क्लाउड IdP एक (subject, audience) के लिए उस जारीकर्ता पर भरोसा करता है, और पॉड टोकन को एक एकल क्लाउड पहचान तक सीमित क्रेडेंशियल के लिए एक्सचेंज करता है - AWS पर एक IAM role, Azure पर एक managed identity। एक बार ट्रस्ट त्रिकोण सीख लें और अनुवाद यांत्रिक है: role managed identity बन जाता है, trust policy federated credential बन जाता है, attached policy RBAC assignment बन जाता है, AssumeRoleWithWebIdentity एक Entra टोकन एक्सचेंज बन जाता है। तीन बातों को ध्यान में रखें - Azure के दो क्लस्टर टॉगल, Azure का आवश्यक पॉड लेबल, और यह तथ्य कि इमेज पुल पूरी तरह से एक अलग पहचान है - और वे अस्वीकृतियाँ जो पहले यादृच्छिक लगती थीं, एक सुसंगत, जानबूझकर डिज़ाइन के रूप में पढ़ना शुरू कर देती हैं।