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

AWS और Google Cloud दोनों एक ही समस्या को एक ही तरीके से हल करते हैं: एक पॉड क्लाउड API को स्वयं के रूप में प्रमाणित करता है, एक अल्पकालिक टोकन और बिना किसी संग्रहीत रहस्य के, अपने Kubernetes ServiceAccount को एक फेडरेटेड क्लाउड पहचान में बदलकर। AWS पर यह सुविधा IRSA (IAM Roles for Service Accounts) है; Google Cloud पर यह Workload Identity Federation for GKE है (जिसे 2024 में "Workload Identity" से नया नाम दिया गया)। मूल रूप से, दोनों एक ही OIDC फेडरेशन ट्रिक हैं - लेकिन GKE बहुत अधिक आंतरिक कार्यप्रणाली को छिपाता है, और यह बदल देता है कि आप इसे कैसे कॉन्फ़िगर करते हैं, डीबग करते हैं और इसके बारे में सोचते हैं।

संक्षेप में, यदि आप केवल एक पैराग्राफ पढ़ते हैं: क्लस्टर प्रत्येक पॉड के ServiceAccount के लिए एक अल्पकालिक टोकन पर हस्ताक्षर करता है, और क्लाउड उस टोकन को एक पहचान तक सीमित वास्तविक क्रेडेंशियल के लिए एक्सचेंज करता है। AWS पर आप प्रति क्लस्टर एक IAM OIDC प्रदाता पंजीकृत करते हैं, एक IAM भूमिका बनाते हैं, और इसे एक ट्रस्ट पॉलिसी के साथ नियंत्रित करते हैं; पॉड के अंदर का SDK AssumeRoleWithWebIdentity को कॉल करता है। GKE पर आप कुछ भी पंजीकृत नहीं करते हैं - प्रत्येक प्रोजेक्ट में एक स्थायी, Google-प्रबंधित वर्कलोड आइडेंटिटी पूल होता है जिसका नाम PROJECT_ID.svc.id.goog होता है, प्रत्येक ServiceAccount स्वचालित रूप से इसमें एक प्रिंसिपल होता है, और एक नोड-स्थानीय मेटाडेटा सर्वर टोकन एक्सचेंज करता है ताकि आपका ऐप Application Default Credentials का उपयोग ऐसे करे जैसे वह एक सामान्य VM पर हो। तीन चीजें इतनी अलग हैं कि आपको परेशान कर सकती हैं: GKE को दो सक्षमता टॉगल (क्लस्टर और नोड पूल) की आवश्यकता होती है, GKE एक Kubernetes ServiceAccount को बिना किसी क्लाउड पहचान ऑब्जेक्ट के क्लाउड अनुमतियाँ दे सकता है, और - हमेशा की तरह - आपकी कंटेनर इमेज को खींचना आपकी वर्कलोड पहचान से अलग पहचान है।

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

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

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

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

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

1. क्लस्टर एक OIDC जारीकर्ता है। यह एक डिस्कवरी दस्तावेज़ और एक JWKS एंडपॉइंट को सार्वजनिक कुंजियों के साथ उजागर करता है जिनके साथ यह ServiceAccount टोकन पर हस्ताक्षर करता है। वह जारीकर्ता ट्रस्ट एंकर है।
2. क्लाउड उस जारीकर्ता पर एक विशिष्ट ServiceAccount पहचान के लिए भरोसा करता है। AWS प्रति भूमिका ट्रस्ट व्यक्त करता है; GCP इसे प्रति प्रोजेक्ट एक बार, स्थायी रूप से व्यक्त करता है, और Google इसे आपके लिए प्रबंधित करता है।
3. वर्कलोड प्रोजेक्टेड टोकन को क्लाउड क्रेडेंशियल के लिए एक्सचेंज करता है और एक एकल क्लाउड पहचान के लिए अल्पकालिक क्रेडेंशियल प्राप्त करता है।

बाकी सब नामकरण है - और चरण 2 का कितना हिस्सा आपको स्वयं बनाना है। यहीं पर दोनों क्लाउड सबसे अधिक भिन्न होते हैं।

एक-से-एक मैप

• Kubernetes पक्ष। AWS पर आप ServiceAccount को eks.amazonaws.com/role-arn: <role arn> के साथ एनोटेट करते हैं। GKE पर, आधुनिक प्रत्यक्ष मॉडल में, आप ServiceAccount पर कुछ भी एनोटेट नहीं करते हैं - आप बस इसे एक IAM प्रिंसिपल के रूप में संदर्भित करते हैं। (पुराना प्रतिरूपण मॉडल एक एनोटेशन का उपयोग करता है; नीचे और देखें।)
• "OIDC प्रदाता।" AWS पर यह EKS क्लस्टर का OIDC जारीकर्ता है, जिसे आप IAM में एक OIDC पहचान प्रदाता के रूप में एक बार पंजीकृत करते हैं - प्रति क्लस्टर। GKE पर यह प्रोजेक्ट का वर्कलोड आइडेंटिटी पूल PROJECT_ID.svc.id.goog है, जो स्वचालित रूप से बनाया गया है और Google द्वारा प्रबंधित किया जाता है; आप इसे कभी पंजीकृत नहीं करते हैं, और प्रोजेक्ट में प्रत्येक क्लस्टर में प्रत्येक ServiceAccount पहले से ही इसके अंदर एक प्रिंसिपल है।
• पहचान। AWS: एक IAM भूमिका। GKE प्रत्यक्ष मॉडल: कोई समर्पित पहचान ऑब्जेक्ट नहीं - Kubernetes ServiceAccount स्वयं प्रिंसिपल है। GKE प्रतिरूपण मॉडल: एक Google सेवा खाता जिसे KSA प्रतिरूपित करता है।
• ट्रस्ट नियम। AWS: IAM भूमिका की ट्रस्ट पॉलिसी sub = system:serviceaccount:<ns>:<sa> और aud = sts.amazonaws.com को पिन करती है। GKE प्रत्यक्ष: कोई अलग ट्रस्ट दस्तावेज़ नहीं है - आप सीधे एक प्रिंसिपल पहचानकर्ता को एक भूमिका प्रदान करते हैं जो नेमस्पेस और ServiceAccount को एन्कोड करता है। GKE प्रतिरूपण: आप Google सेवा खाते पर KSA को roles/iam.workloadIdentityUser भूमिका प्रदान करते हैं।
• अनुमतियाँ। AWS: भूमिका से जुड़ी एक IAM पॉलिसी। GKE: लक्ष्य संसाधन (या प्रोजेक्ट) पर IAM अनुमति-पॉलिसी भूमिका बाइंडिंग - roles/storage.objectViewer, roles/secretmanager.secretAccessor, और इसी तरह। यह गहरा विभाजन है: AWS पहचान से एक पॉलिसी जोड़ता है; GCP संसाधन के दायरे में एक भूमिका प्रदान करता है।
• एक्सचेंज। AWS: पॉड के अंदर का SDK प्रोजेक्टेड टोकन के साथ sts:AssumeRoleWithWebIdentity को कॉल करता है। GKE: नोड का मेटाडेटा सर्वर एक्सचेंज को पारदर्शी रूप से करता है और आपका ऐप Application Default Credentials का उपयोग बिना किसी एक्सचेंज कोड के करता है।

इस पोस्ट का बाकी हिस्सा प्रत्येक क्लाउड को एंड-टू-एंड बताता है, फिर उन अंतरों पर ध्यान केंद्रित करता है जो वास्तव में लोगों को परेशान करते हैं।

वॉक-थ्रू: AWS EKS IRSA, एंड-टू-एंड

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

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

2. IAM भूमिका और उसकी ट्रस्ट पॉलिसी। ट्रस्ट पॉलिसी भूमिका को एक 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 पॉलिसी जो भूमिका से जुड़ी होती है, वह ऐप को जो चाहिए वह प्रदान करती है (एक बकेट पर s3:GetObject, और इसी तरह)।

4. 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 को इंजेक्ट करता है और एक प्रोजेक्टेड टोकन (ऑडियंस sts.amazonaws.com, स्वचालित रूप से घुमाया गया) माउंट करता है।

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

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

वॉक-थ्रू: GKE Workload Identity Federation, एंड-टू-एंड

वही ट्रस्ट फ्लो, बनाने के लिए बहुत कम:

1. दो सक्षमता टॉगल। क्लस्टर पर वर्कलोड आइडेंटिटी पूल और नोड पूल पर मेटाडेटा सर्वर सक्षम करें:

gcloud container clusters update <cluster> --workload-pool=<project-id>.svc.id.goog
gcloud container node-pools update <pool> --cluster=<cluster> --workload-metadata=GKE_METADATA

दोनों आवश्यक हैं। क्लस्टर फ्लैग क्लस्टर को प्रोजेक्ट के पूल में ऑप्ट करता है; नोड-पूल फ्लैग GKE मेटाडेटा सर्वर (प्रत्येक नोड पर एक DaemonSet) को तैनात करता है जो क्रेडेंशियल अनुरोधों को इंटरसेप्ट करेगा। GKE_METADATA के बिना नोड पूल पर एक पॉड को नोड की पहचान मिलती है, अपनी नहीं - एक मौन, अत्यधिक व्यापक फॉलबैक।

2. पूल पहले से मौजूद है। <project-id>.svc.id.goog प्रोजेक्ट के लिए स्वचालित रूप से बनाया जाता है; आप कभी भी OIDC प्रदाता पंजीकृत नहीं करते हैं, और हिट करने के लिए कोई प्रति-खाता प्रदाता सीमा नहीं है। प्रोजेक्ट के क्लस्टर में प्रत्येक ServiceAccount पहले से ही एक प्रिंसिपल है।

3a. प्रत्यक्ष पहुंच (आधुनिक डिफ़ॉल्ट)। सीधे ServiceAccount को एक भूमिका प्रदान करें, जिसे एक IAM प्रिंसिपल के रूप में संबोधित किया गया है। कोई Google सेवा खाता नहीं, कोई एनोटेशन नहीं:

gcloud storage buckets add-iam-policy-binding gs://<bucket> \
  --role=roles/storage.objectViewer \
  --member="principal://iam.googleapis.com/projects/<project-number>/locations/global/workloadIdentityPools/<project-id>.svc.id.goog/subject/ns/apps/sa/checkout"

प्रिंसिपल पथ ns/apps/sa/checkout को एन्कोड करता है - नेमस्पेस और ServiceAccount ट्रस्ट नियम हैं; लिखने के लिए कोई अलग ट्रस्ट दस्तावेज़ नहीं है।

3b. प्रतिरूपण (पुराना मॉडल, अभी भी कुछ सेवाओं के लिए आवश्यक)। एक Google सेवा खाता बनाएं, KSA को इसे प्रतिरूपित करने दें, और KSA को एनोटेट करें:

gcloud iam service-accounts add-iam-policy-binding checkout@<project-id>.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:<project-id>.svc.id.goog[apps/checkout]"

apiVersion: v1
kind: ServiceAccount
metadata:
  name: checkout
  namespace: apps
  annotations:
    iam.gke.io/gcp-service-account: checkout@<project-id>.iam.gserviceaccount.com

यहां Google सेवा खाता अनुमतियाँ रखता है (सामान्य भूमिका बाइंडिंग के माध्यम से), और KSA उन्हें उधार लेता है।

4. एक्सचेंज। जब आपका ऐप क्रेडेंशियल मांगता है, तो GKE मेटाडेटा सर्वर http://metadata.google.internal के अनुरोध को इंटरसेप्ट करता है, उस पॉड के लिए Kubernetes API से एक ServiceAccount JWT प्राप्त करता है, इसे Security Token Service के माध्यम से एक अल्पकालिक फेडरेटेड एक्सेस टोकन (डिफ़ॉल्ट 1 घंटा, समाप्ति से पहले सक्रिय रूप से ताज़ा किया गया) के लिए एक्सचेंज करता है, और इसे वापस करता है। आपका ऐप Application Default Credentials और मानक Google Cloud क्लाइंट लाइब्रेरी का उपयोग करता है - यह ठीक वैसे ही व्यवहार करता है जैसे वह एक GCE VM पर चल रहा हो। कोई वेबहुक env vars को इंजेक्ट नहीं कर रहा है, कोई AZURE_*-शैली के वैरिएबल नहीं हैं, और आपके कोड में कोई एक्सचेंज कॉल नहीं है: एक Cloud Storage रीड Python में बस storage.Client() है।

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

वह मान जो दोनों क्लाउड पर ठीक-ठीक मेल खाना चाहिए, वह ServiceAccount पहचान है:

• AWS भूमिका की ट्रस्ट पॉलिसी में टोकन विषय system:serviceaccount:<namespace>:<serviceaccount> को पिन करता है।
• GKE प्रत्यक्ष प्रिंसिपल पथ .../subject/ns/<namespace>/sa/<serviceaccount> में वही युग्मन एन्कोड करता है।
• GKE प्रतिरूपण इसे सदस्य serviceAccount:<project-id>.svc.id.goog[<namespace>/<serviceaccount>] में एन्कोड करता है।

किसी भी क्लाउड पर सबसे आम "यह किसी के रूप में प्रमाणित नहीं होता है" विफलता यहां एक बेमेल है: चार्ट एक अलग नेमस्पेस में तैनात किया गया, ServiceAccount को ऐप नाम के बजाय रिलीज़ नाम मिला, या पॉड default ServiceAccount पर वापस आ गया। जब फेडरेशन चुपचाप विफल हो जाता है, तो पहले नेमस्पेस और ServiceAccount नाम की जांच करें।

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

1. GKE आपके लिए "OIDC प्रदाता" पंजीकृत करता है - एक बार, प्रति प्रोजेक्ट, हमेशा के लिए। EKS पर आप प्रति क्लस्टर एक IAM OIDC प्रदाता पंजीकृत करते हैं, और फ्लीट स्केल पर आप प्रति AWS खाते में 100 OIDC प्रदाताओं की सॉफ्ट लिमिट को हिट कर सकते हैं और इसे हल करने के लिए काम करना पड़ता है। GKE पर प्रति प्रोजेक्ट ठीक एक पूल (PROJECT_ID.svc.id.goog) होता है, जिसे Google द्वारा बनाया और प्रबंधित किया जाता है, जो प्रोजेक्ट में प्रत्येक क्लस्टर द्वारा साझा किया जाता है। पंजीकृत करने के लिए कुछ भी नहीं, कैप करने के लिए कुछ भी नहीं। दूसरा पहलू: ट्रस्ट डिफ़ॉल्ट रूप से प्रोजेक्ट-व्यापी है, इसलिए आप IAM बाइंडिंग (आप किस नेमस्पेस और ServiceAccount को अनुमति देते हैं) के साथ स्कोप करते हैं, न कि प्रदाताओं को विभाजित करके।

2. GKE नोड-स्थानीय मेटाडेटा सर्वर पर टोकन का आदान-प्रदान करता है, न कि इन-पॉड SDK कॉल के साथ। IRSA पॉड को म्यूटेट करता है (एक वेबहुक env vars और एक प्रोजेक्टेड टोकन इंजेक्ट करता है) और SDK STS को कॉल करता है। GKE नोड पर metadata.google.internal को इंटरसेप्ट करता है और पारदर्शी रूप से क्रेडेंशियल वापस देता है, इसलिए ऐप Application Default Credentials का उपयोग ऐसे करता है जैसे वह एक सामान्य VM पर हो। दो परिणाम: आपके ऐप को कोई क्लाउड-विशिष्ट क्रेडेंशियल कोड की आवश्यकता नहीं होती है, और नोड पूल में मेटाडेटा सर्वर सक्षम (GKE_METADATA) होना चाहिए अन्यथा पॉड चुपचाप अपनी पहचान के बजाय नोड की पहचान प्राप्त करता है।

3. GKE एक ServiceAccount को बिना किसी क्लाउड पहचान ऑब्जेक्ट के क्लाउड अनुमतियाँ दे सकता है। IRSA में हमेशा एक IAM भूमिका होती है। GKE के प्रत्यक्ष मॉडल में क्लाउड साइड पर भूमिका बाइंडिंग को छोड़कर कुछ भी बनाने की आवश्यकता नहीं होती है - Kubernetes ServiceAccount ही प्रिंसिपल है (principal://.../subject/ns/NS/sa/SA)। पुराना प्रतिरूपण मॉडल एक Google सेवा खाता और iam.gke.io/gcp-service-account एनोटेशन पेश करता है, और आपको अभी भी उन मुट्ठी भर सेवाओं के लिए इसकी आवश्यकता है जो सीधे एक फेडरेटेड प्रिंसिपल को स्वीकार नहीं करती हैं - लेकिन पहले प्रत्यक्ष बाइंडिंग के लिए पहुंचें।

4. GKE को दो टॉगल की आवश्यकता होती है, जैसे Azure करता है। क्लस्टर (--workload-pool) प्लस नोड पूल (--workload-metadata=GKE_METADATA)। नोड-पूल आधे को मिस करने पर कोई विफलता नहीं होती है, बस गलत (नोड) पहचान मिलती है। IRSA प्रोजेक्शन को EKS में ही समेट लेता है, इसलिए कोई समान दूसरा स्विच नहीं है।

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

6. अनुमतियाँ अलग तरह से संलग्न होती हैं। AWS भूमिका से एक IAM पॉलिसी जोड़ता है - अनुमति पहचान के साथ यात्रा करती है। GCP लक्ष्य संसाधन के दायरे (या प्रोजेक्ट) में एक IAM भूमिका बाइंडिंग प्रदान करता है - अनुदान उस चीज़ पर रहता है जिसे एक्सेस किया जा रहा है, पहचान पर नहीं। वही अंतिम स्थिति, इसे ऑडिट करने के लिए अलग जगह: AWS पर भूमिका की संलग्न नीतियों को पढ़ें; GCP पर संसाधन की IAM पॉलिसी को सूचीबद्ध करें (या एक प्रिंसिपल क्या पहुंच सकता है इसके लिए Policy Analyzer का उपयोग करें)।

ऐप कोड क्या करता है

दोनों क्लाउड "कोई रहस्य नहीं, कोई क्रेडेंशियल कोड नहीं" पर समाप्त होते हैं, लेकिन वे वहां अलग तरह से पहुंचते हैं:

• AWS: वेबहुक AWS_ROLE_ARN और AWS_WEB_IDENTITY_TOKEN_FILE सेट करता है; SDK की डिफ़ॉल्ट चेन AssumeRoleWithWebIdentity को कॉल करती है। आपका कोड: boto3.client("s3")।
• GKE: पॉड में कुछ भी इंजेक्ट नहीं किया जाता है; SDK की Application Default Credentials चेन नोड मेटाडेटा सर्वर को हिट करती है, जो एक्सचेंज करता है। आपका कोड: storage.Client()।

दोनों मामलों में क्रेडेंशियल अल्पकालिक होते हैं और पारदर्शी रूप से ताज़ा किए जाते हैं। घुमाने के लिए कुछ भी नहीं है, स्टोर करने के लिए कुछ भी नहीं है, और लीक करने के लिए कुछ भी नहीं है।

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

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

1. क्लस्टर/प्रोजेक्ट फेडरेशन चालू है? EKS: IAM OIDC प्रदाता पंजीकृत है। GKE: क्लस्टर में --workload-pool और नोड पूल में GKE_METADATA है। GKE पर, एक लापता नोड-पूल टॉगल क्लासिक साइलेंट विफलता है - पॉड को नोड पहचान मिलती है, अपनी नहीं।
2. सही ServiceAccount? पॉड वास्तव में उस ServiceAccount का उपयोग करता है जिसके बारे में आप सोचते हैं (न कि default)। अंदर exec करें और जांचें।
3. पहचान मेल खाती है? ट्रस्ट नियम की वास्तविक नेमस्पेस और ServiceAccount से तुलना करें: AWS पर system:serviceaccount:<ns>:<sa>, GKE पर .../subject/ns/<ns>/sa/<sa> (या [ns/sa])। यह दोनों पर सबसे लगातार विफलता है।
4. एक्सचेंज काम कर रहा है? EKS: पॉड में AWS_WEB_IDENTITY_TOKEN_FILE है। GKE: पॉड से curl -H "Metadata-Flavor: Google" metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email अपेक्षित पहचान लौटाता है।
5. अनुमतियाँ? पहचान हल होने के बाद ही: भूमिका पर IAM पॉलिसी (AWS) या लक्ष्य संसाधन पर भूमिका बाइंडिंग (GCP)। यहां एक खाली परिणाम एक प्राधिकरण विफलता है, प्रमाणीकरण नहीं - जो आपको बताता है कि फेडरेशन स्वयं काम कर रहा है।

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

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

AWS पक्ष पर:

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

Google Cloud पक्ष पर:

• Google Cloud Associate Cloud Engineer - GKE, IAM, सेवा खाते, और भूमिका बाइंडिंग।
• Google Cloud Professional Cloud Security Engineer - वर्कलोड पहचान, IAM गहराई, सेवा-खाता सुरक्षा, और न्यूनतम विशेषाधिकार।

Kubernetes पक्ष पर:

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

निचला रेखा

IRSA और GKE Workload Identity Federation एक ही विचार हैं जो अलग-अलग मात्रा में आंतरिक कार्यप्रणाली पहनते हैं: क्लस्टर एक ServiceAccount के लिए एक अल्पकालिक OIDC टोकन पर हस्ताक्षर करता है, और क्लाउड इसे एक एकल पहचान तक सीमित क्रेडेंशियल के लिए एक्सचेंज करता है। AWS आपको ट्रस्ट को स्वयं इकट्ठा करने के लिए कहता है - प्रति क्लस्टर एक OIDC प्रदाता, एक IAM भूमिका, एक ट्रस्ट पॉलिसी, एक प्रोजेक्टेड टोकन जिसे SDK एक्सचेंज करता है। GKE आपको एक प्रबंधित, प्रोजेक्ट-व्यापी पूल देता है, आपको बिना किसी क्लाउड पहचान के सीधे Kubernetes ServiceAccount से एक भूमिका बांधने देता है, और नोड मेटाडेटा सर्वर पर एक्सचेंज करता है ताकि आपका ऐप कभी क्रेडेंशियल न देखे। ट्रस्ट त्रिकोण को एक बार सीखें और अनुवाद यांत्रिक है: भूमिका प्रिंसिपल बाइंडिंग (या एक सेवा खाता जिसे आप प्रतिरूपित करते हैं) बन जाती है, ट्रस्ट पॉलिसी एक IAM सदस्य स्ट्रिंग बन जाती है, संलग्न पॉलिसी संसाधन पर एक भूमिका बाइंडिंग बन जाती है, और AssumeRoleWithWebIdentity एक अदृश्य मेटाडेटा-सर्वर एक्सचेंज बन जाता है। तीन चीजों को ध्यान में रखें - GKE के दो टॉगल, इसका नो-आइडेंटिटी-ऑब्जेक्ट डायरेक्ट मॉडल, और यह तथ्य कि इमेज पुल पूरी तरह से एक अलग पहचान है - और जो इनकार पहले यादृच्छिक लगते थे वे एक सुसंगत, जानबूझकर डिजाइन के रूप में पढ़ने लगते हैं।