Cloud workload identity federation के लिए security checklist
Long-lived CI/CD cloud keys को workload identity federation से बदलें; trust claims, short-lived credentials, protected environments और deployment roles सीमित रखें।
इस मार्गदर्शिका में
Workload identity federation क्या है?
Workload identity federation से बाहरी workload—जैसे CI/CD job—अपनी identity cloud provider के सामने साबित करके temporary access ले सकता है। इससे repository secrets में long-lived cloud key रखने की जरूरत घट सकती है, लेकिन broad trust policy untrusted workflow को वही access दे सकती है। Issuer, audience और identity claims को साथ सुरक्षित करें, फिर बने role को deployment के जरूरी permissions ही दें।
Cloud access चाहने वाले workloads और उनका उद्देश्य दर्ज करें
Repositories, CI platforms, deployment environments, cloud roles, target resources और human owners की सूची बनाएँ। Build, test और production deploy identities अलग रखें। पुराने access keys हटाएँ और पहचानें कि क्या intended federated trust से गुजरे बिना वही role लिया जा सकता है।
Trust को सही issuer, audience और workload claims तक सीमित करें
Token issuer और audience validate करें, फिर subject या mapped claims को trusted organization, repository, branch, tag, protected environment या reusable workflow तक सीमित करें। Shared identity provider के हर repository को स्वीकार न करें। Google Cloud GitHub जैसे multi-tenant providers के लिए attribute conditions की सलाह देता है; अपने provider में समकक्ष claim conditions लगाएँ।
सीमित deployment उद्देश्य वाला short-lived role दें
Federated identity को target environment और resources के लिए जरूरी actions तक scoped role दें। Deployment के अनुरूप session duration रखें और production को preview या test से अलग करें। Federation stored cloud credential हटाती है; इससे workflow या deployment artifact अपने-आप trustworthy नहीं हो जाता।
| Workflow और environment | Issuer, audience और claims | Cloud role और permissions | Approval और runner controls | Test और review date |
|---|---|---|---|---|
| Test deployment | ||||
| Production release | ||||
| External reusable workflow |
GitHub Actions OIDC को सुरक्षित कैसे configure करें?
Token permission केवल deploy करने वाली job को दें
जहाँ व्यावहारिक हो id-token: write को सबसे छोटी job scope पर सेट करें और बाकी workflow permissions न्यूनतम रखें। GitHub कहता है कि यह permission job को OIDC token माँगने देती है; cloud resources पर write access नहीं देती। Token की claims स्वीकार करने वाली cloud trust policy और बाद के role permissions तय करते हैं कि job क्या कर सकती है।
Trust policy को protected branches और environments से मिलाएँ
Provider claim conditions से deployment को reviewed branches, tags या protected environments तक सीमित करें। Production release में second-person check चाहिए तो environment approval rules लगाएँ। Pull-request workflows, reusable workflows और self-hosted runners भी review करें, क्योंकि trusted job में चलने वाला code उसी job का token माँग सकता है।
Repository या identity बदले तो exact subject format फिर जाँचें
OIDC claim formats और provider mappings बदल सकते हैं। GitHub 15 जुलाई 2026 के बाद बने या transfer किए repository, या इस format को अपनाने वाले repository के immutable subject formats बताता है। Trust बदलने से पहले अपने repository के actual token claims verify करें और deployment चलाने के लिए access को wildcard से broad न करें।
Federated cloud access को operate और review कैसे करें?
Token माँग सकने वाले workflow code और actions बचाएँ
Deployment workflow changes पर review अनिवार्य करें, जहाँ उचित हो third-party actions को reviewed immutable versions पर pin करें, reusable workflows सुरक्षित रखें और production environment approval सीमित करें। Self-hosted runner access सीमित करें और untrusted pull-request code को ऐसे runner पर न चलाएँ जिसके पास sensitive network या identity access है।
Role assumption log करें और अप्रत्याशित subjects पर alert करें
Cloud identity events को सुरक्षित audit destination पर भेजें और provider record करे तो federated subject या source identity रखें। Unexpected repository, branch, environment या समय से role इस्तेमाल होने पर alert करें; denied claims fail closed हों, यह test करें। Repository transfer, rename, workflow reuse या cloud account change के बाद trust conditions review करें।
Trust policy को कमजोर किए बिना recovery path रखें
Federated provider या role configuration बिगड़ने पर उसे कौन restore कर सकता है, लिखें। Incident में wildcard claim या permanent access key जोड़ने के बजाय सीमित, logged और review होने वाला break-glass रास्ता रखें। Recovery के बाद temporary credentials revoke करें और emergency grants हटाएँ।
Workload identity federation FAQs
क्या workload identity federation सभी secrets खत्म कर देती है?
नहीं। यह federated exchange के लिए long-lived cloud key हटा सकती है, पर application को database password, signing key या third-party token अभी चाहिए हो सकता है। उन्हें स्वीकृत secrets service में रखें और access सही workload तक सीमित करें।
क्या id-token: write से GitHub workflow cloud resources बदल सकती है?
नहीं। यह permission job को GitHub OIDC token माँगने देती है। Cloud provider token तभी देता है जब trust policy claims स्वीकार करे; फिर role policy resource permissions तय करती है। दोनों को सीमित रखें।
क्या repository का हर workflow production role ले सकता है?
जहाँ केवल protected deployment workflow को production चाहिए, वहाँ केवल repository नाम पर आधारित broad trust से बचें। Provider के supported branch, environment, workflow या stable claims की शर्त लगाएँ और पुष्टि करें कि untrusted pull-request jobs वे शर्तें पूरी नहीं कर सकते।
क्या federated credentials को rotate करना पड़ता है?
Exchanged short-lived credentials expire होते हैं, इसलिए stored cloud key की rotation जरूरत घटती है। फिर भी provider trust, signing keys और issuer configuration, role permissions, workflow ownership तथा workload के अन्य long-lived secrets की समीक्षा जरूरी है।
संबंधित व्यावहारिक मार्गदर्शिकाएँ
संबंधित मुद्दों की मार्गदर्शिकाएँ
स्रोत और प्रकाशन रिकॉर्ड
Draft prepared 27 September 2026; engineering, security and editorial review pending · स्रोत जाँचे गए .