# क्रेडेंशियल जीवनचक्र और निष्पादन के मालिक अलग रखें

सीक्रेट मैनेजर को तय करना चाहिए कि कौन सा क्रेडेंशियल मौजूद है, वह कब समाप्त होगा और उसे कैसे बंद किया जाएगा। डेस्कटॉप गेटवे को तय करना चाहिए कि यह प्रोसेस अभी यह कार्रवाई कर सकता है या नहीं, प्रोसेस को क्रेडेंशियल दिए बिना कार्रवाई पूरी करनी चाहिए और जो हुआ उसे दर्ज करना चाहिए। इन दोनों कामों को जोड़ना आसान लगता है, जब तक पहला रोटेशन, निरस्तीकरण या सुरक्षा मामला यह न पूछे कि असल जिम्मेदारी किस कंपोनेंट की थी।

सीमा इस बात से तय होती है कि इस्तेमाल के समय क्रेडेंशियल किसके पास है, इससे नहीं कि वह रखा कहां गया है। HashiCorp Vault या 1Password पर आधारित वर्कफ़्लो जीवनचक्र का अधिकारी बना रह सकता है और गेटवे निष्पादन नियंत्रित कर सकता है, लेकिन हैंडऑफ़ में जीवनचक्र की स्थिति और पहचान साथ जानी चाहिए और गेटवे ऐसा कैश नहीं बनना चाहिए जिसका हिसाब न हो। अगर गेटवे कोई मान कॉपी करता है, उसकी लीज़ भूल जाता है और उसका इस्तेमाल करता रहता है, तो आर्किटेक्चर के चित्र में दो बॉक्स हैं, पर सिस्टम में दो सीक्रेट मैनेजर हैं।

जब स्वचालित एजेंट उत्पादन API या SSH लक्ष्यों तक पहुंच सकते हों, तब यह व्यवस्था थोड़ी अतिरिक्त जोड़ाई के लायक है। एजेंटों को सीमित कार्रवाइयां और इंसानी नियंत्रण चाहिए। उन्हें क्रेडेंशियल पढ़ने का एक और रास्ता नहीं चाहिए।

## सीमा प्रमाणित कार्रवाई से ठीक पहले आती है

जीवनचक्र सिस्टम क्रेडेंशियल बनाता, रोटेट करता, समाप्त करता और निरस्त करता है। निष्पादन गेटवे हर प्रमाणित कार्रवाई को जारी करने की जिम्मेदारी लेता है। यही वाक्य आर्किटेक्चर की जांच है। हर फ़ील्ड, कैश, दोबारा कोशिश और लॉग प्रविष्टि के लिए एक पक्ष जवाब दे सके।

जीवनचक्र का स्वामित्व किसी एन्क्रिप्टेड स्ट्रिंग को रखने भर से बड़ा है। डायनेमिक डेटाबेस खाते में यह खाता बनाने वाली भूमिका, लीज़ ID, TTL, नवीनीकरण नियम और खाते को मिटाने या बंद करने वाली कार्रवाई तक जाता है। स्थिर API टोकन में यह अपस्ट्रीम जारीकर्ता, मौजूदा जनरेशन, सक्रिय होने का समय, कोई ओवरलैप अवधि और पुराने जनरेशन के काम न करने के सबूत तक जाता है। पासवर्ड मैनेजर आधिकारिक रिकॉर्ड रख सकता है, लेकिन टोकन स्वीकार होगा या नहीं, यह रिमोट API ही तय करता है।

निष्पादन की जिम्मेदारी तब शुरू होती है जब कॉलर किसी परिणाम की मांग करता है, जैसे `GET /billing/invoices`, `POST /deployments` या किसी नामित होस्ट पर SSH कमांड। गेटवे कॉलर की पहचान जांचता है, स्थानीय मंजूरी की स्थिति देखता है, अधिकृत क्रेडेंशियल हल करता है, उसे बाहर जाने वाले प्रोटोकॉल में डालता है और केवल परिणाम लौटाता है। उसे एजेंट को सामान्य `read secret` कार्रवाई नहीं देनी चाहिए। ऐसा करना निष्पादन को फिर से सीक्रेट वितरण बना देगा।

इसलिए साफ़ इंटरफ़ेस में कार्रवाई और क्रेडेंशियल रेफ़रेंस का नाम होना चाहिए, क्रेडेंशियल मान का नहीं। उसमें अपेक्षित जीवनचक्र जनरेशन भी होना चाहिए ताकि देर से आया अनुरोध चुपचाप रोटेशन सीमा पार न करे। काम का अनुरोध एनवेलप ऐसा दिखता है:

```json
{
  "action_id": "01J...",
  "credential_ref": "vault:database/creds/agent-readonly",
  "expected_generation": "lease:database/creds/agent-readonly/2f6a...",
  "purpose": "read migration status",
  "target": "db-admin.internal",
  "caller": {
    "session_id": "sess_7f2...",
    "process_authority": "signed:TEAMID.example.agent"
  }
}
```

गेटवे अंदर का मान पा सकता है, क्योंकि किसी कंपोनेंट को Authorization हेडर या SSH हैंडशेक में बाइट डालनी ही होंगी। शर्त यह है कि वह मान भरोसेमंद निष्पादन पथ के भीतर मिले, एजेंट को दिखने वाले आर्ग्युमेंट, एनवायरनमेंट वेरिएबल, फ़ाइल, टूल परिणाम और त्रुटि संदेश से बाहर रहे, फिर दर्ज कैश नियम के अनुसार मिटा दिया जाए। एजेंट के लिए सीक्रेट-रहित होने का अर्थ यह नहीं कि कोई कंपोनेंट कभी प्लेनटेक्स्ट नहीं संभालता।

## जीवनचक्र अधिकारी को क्रेडेंशियल बनाने और हटाने दें

जब Vault का सीक्रेट इंजन लक्ष्य सिस्टम में क्रेडेंशियल बना और निरस्त कर सके, तब Vault को जीवनचक्र का मालिक बनाएं। स्थिर क्रेडेंशियल के लिए 1Password पर आधारित वर्कफ़्लो को तभी मालिक बनाएं जब वह जारीकर्ता को भी अपडेट करे, नया जनरेशन दर्ज करे और पुराने को बंद करे। केवल सबसे नया मान रखना इन्वेंटरी प्रबंधन है, रोटेशन नहीं।

HashiCorp का Vault लीज़ दस्तावेज़ इस अनुबंध को बहुत साफ़ करता है। हर डायनेमिक सीक्रेट के साथ अवधि और नवीनीकरण की अनुमति वाली लीज़ होती है। Vault उस अवधि तक मान्य होने का वादा करता है, लेकिन अवधि खत्म होने के बाद उपभोक्ता यह नहीं मान सकता कि क्रेडेंशियल काम करेगा। लीज़ निरस्त करने पर सीक्रेट तुरंत अमान्य होता है और उसका नवीनीकरण रुकता है। समर्थित इंजनों में Vault नीचे की सफ़ाई भी करता है, जैसे बनाया गया क्लाउड क्रेडेंशियल या डेटाबेस यूज़र मिटाना।

इस व्यवहार के कारण समर्थित डायनेमिक क्रेडेंशियल के लिए Vault स्पष्ट मालिक है। गेटवे को लीज़ मांगनी या लेनी चाहिए, लौटाया गया TTL देखना चाहिए और लीज़ समाप्त होने से पहले इस्तेमाल रोकना चाहिए। उसे कभी अधिक लंबी स्थानीय अवधि नहीं बनानी चाहिए। HashiCorp यह चेतावनी भी देता है कि मांगी गई नवीनीकरण अवधि केवल सुझाव है और क्लाइंट को नवीनीकरण उत्तर जांचना होगा। जो गेटवे एक घंटा मांगकर मान लेता है कि उसे पूरा घंटा मिल गया, वह जीवनचक्र का स्वामित्व पहले ही तोड़ चुका है।

Vault का KV इंजन अलग है। Vault दस्तावेज़ कहता है कि KV लीज़ जारी नहीं करता, भले उत्तर में लीज़ अवधि दिखे। API टोकन को KV में रखने से वह डायनेमिक नहीं हो जाता और पुराना KV वर्ज़न मिटाने से जारीकर्ता के यहां टोकन आवश्यक रूप से निरस्त नहीं होता। रोटेशन वर्कफ़्लो को प्रदाता को कॉल करना, नए क्रेडेंशियल की जांच करना, आधिकारिक रिकॉर्ड बदलना और पुराना टोकन बंद करना होगा।

यही सीमा 1Password पर भी लागू होती है। उसके CLI दस्तावेज़ में सीक्रेट रेफ़रेंस और `op run`, `op read`, `op inject` जैसे कमांड बताए गए हैं। ये तरीके रनटाइम पर रखा हुआ सीक्रेट लाते हैं। ये अपने आप किसी सामान्य तृतीय-पक्ष API कुंजी को उसके जारीकर्ता पर रोटेट नहीं करते। टीम 1Password को आधिकारिक रिकॉर्ड बना सकती है, पर उसके आसपास की ऑटोमेशन को रिमोट अपडेट और पुराना मान हटाने की पूरी प्रक्रिया संभालनी होगी।

विक्रेता की श्रेणी देखकर जीवनचक्र का मालिक न चुनें। यह देखें कि जारीकर्ता पर वास्तविक नियंत्रण किसका है और जनरेशन का बदलाव साफ़ दिखता है या नहीं।

## सुरक्षित हैंडऑफ़ में रेफ़रेंस और लीज़ दोनों जाते हैं

गेटवे को ऐसा रेफ़रेंस चाहिए जिसे वह हल कर सके, वैधता की सीमा चाहिए और निरस्तीकरण का रास्ता चाहिए। केवल रेफ़रेंस देने से नाम तय होता है, समय खो जाता है। केवल समाप्ति समय देने से वह अधिकारी खो जाता है जो सच में निरस्त कर सकता है। केवल सीक्रेट मान देने से दोनों खो जाते हैं।

Vault डायनेमिक सीक्रेट में स्वाभाविक जनरेशन पहचान लीज़ ID है। `vault read database/creds/my-role` के उत्तर में `lease_id`, `lease_duration`, `lease_renewable`, `username` और `password` आते हैं। गेटवे को क्रेडेंशियल बाइट और इस मेटाडेटा को एक ही ऑब्जेक्ट में बांधना होगा। पासवर्ड को एक कैश और लीज़ को दूसरे कैश में रखने से दोनों अलग समय पर बदल सकते हैं।

1Password के स्थिर रिकॉर्ड के लिए रोटेशन वर्कफ़्लो में न बदलने वाला जनरेशन निशान बनाएं। यह चुने हुए इंटीग्रेशन से मिला आइटम वर्ज़न ID या रेफ़रेंस के पास रखा रोटेशन इवेंट ID हो सकता है। `prod-api-key` जैसे बदलने वाले आइटम नाम को जनरेशन न मानें। नाम गेटवे को बताता है कि कहां हल करना है, यह साबित नहीं करता कि उसे कौन सा मान मिला।

हैंडऑफ़ अनुबंध में ये गुण होने चाहिए:

- `credential_ref` सीक्रेट सामग्री के बिना स्रोत की पहचान करता है।
- `generation` उपयोग योग्य क्रेडेंशियल बदलने पर बदलता है।
- `not_after` उपलब्ध होने पर गेटवे को पक्का स्थानीय अंतिम समय देता है।
- `revocation_ref` घटना संभालने वाले टूल को बताता है कि क्या निरस्त या बंद करना है।
- `issued_for` क्रेडेंशियल को तय भूमिका, लक्ष्य और एनवायरनमेंट से बांधता है।

गेटवे के उत्तर में गैर-संवेदनशील हिस्से वापस आने चाहिए ताकि कॉलर और ऑडिट पाइपलाइन सीक्रेट जाने बिना परिणाम को जोड़ सकें:

```json
{
  "action_id": "01J...",
  "status": 200,
  "credential_ref": "vault:database/creds/agent-readonly",
  "generation": "lease:database/creds/agent-readonly/2f6a...",
  "executed_at": "2026-07-27T14:03:12Z",
  "result_digest": "sha256:9b0..."
}
```

यह अनुबंध एक असुविधाजनक सच भी दिखाता है: डेस्कटॉप गेटवे को जीवनचक्र सिस्टम से पाने के लिए अपनी मशीन पहचान चाहिए। इस शुरुआती क्रेडेंशियल का भी जीवनचक्र होता है। Vault टोकन की पॉलिसी सीमित हो और उसका अपना TTL या नवीनीकरण व्यवहार हो। 1Password सर्विस अकाउंट टोकन केवल जरूरी वॉल्ट तक पहुंच सके। शुरुआती टोकन को स्थानीय सेटिंग फ़ाइल में छिपाना मूल समस्या को केवल एक स्तर नीचे भेजता है।

## समाप्ति को कैश और दोबारा कोशिश पर जीतना होगा

हैंडऑफ़ के बाद समाप्ति तभी बचती है जब हर निष्पादन पथ मौजूदा समय की तुलना जीवनचक्र अधिकारी से मिली सीमा से करे। बचा हुआ समय रेफ़रेंस हल करने, मंजूरी, कनेक्शन, निष्पादन और घड़ी के छोटे अंतर के लिए पर्याप्त न हो तो गेटवे नया काम अस्वीकार करे।

मान लें Vault दस मिनट के लिए डेटाबेस क्रेडेंशियल देता है। एजेंट नौवें मिनट में एक्सपोर्ट शुरू करता है, यूज़र मंजूरी कार्ड पढ़ने में चालीस सेकंड लगाता है और नेटवर्क टाइमआउट के बाद गेटवे दो बार कोशिश करता है। जिस कैश ने केवल क्रेडेंशियल लेते समय TTL देखा, वह आखिरी कोशिश समाप्ति के बाद शुरू कर सकता है। लक्ष्य प्रमाणीकरण त्रुटि लौटाएगा, पर ऑडिट उसे नेटवर्क खराबी या यूज़र के मना करने के रूप में दर्ज कर सकता है।

आधिकारिक मेटाडेटा से उपयोग की अंतिम सीमा एक बार तय करें:

```text
usable_until = min(authority_not_after, fetched_at + local_cache_cap)
latest_start = usable_until - approval_budget - connect_budget - clock_margin
```

ये बजट संचालन के विकल्प हैं, क्रेडेंशियल की उम्र बढ़ाने वाले नियम नहीं। अगर `now`, `latest_start` से बाद है, तो नया जनरेशन लें और मंजूर कार्रवाई में बड़ा बदलाव हो तो नई मंजूरी दिखाएं। स्थानीय कतार में रुके अनुरोध को बचाने के लिए Vault लीज़ का नवीनीकरण न करें। नवीनीकरण जीवनचक्र का फैसला है और जोखिम की अवधि बढ़ा सकता है।

दोबारा कोशिश पर भी यही अनुशासन लागू होता है। क्रेडेंशियल तभी दोबारा उपयोग हो सकता है जब जनरेशन मेल खाता हो, उपयोग की सीमा बची हो और रिमोट कार्रवाई सुरक्षित रूप से दोहराई जा सके। HTTP idempotency और क्रेडेंशियल वैधता अलग जांच हैं। टोकन का वैध होना दोहराए गए `POST` को सुरक्षित नहीं बनाता।

जिन स्थिर क्रेडेंशियल की जारीकर्ता से मिली समाप्ति नहीं है, उनके पुराने प्रतिरूप कम रखने के लिए स्थानीय कैश सीमा लगाएं, पर उसे समाप्ति नहीं, कैश नीति कहें। जीवनचक्र वर्कफ़्लो को रोटेशन के बाद जनरेशन सूचना या जबरन दोबारा समाधान चाहिए। इसके बिना गेटवे ओवरलैप अवधि में पुराने लेकिन मान्य टोकन का उपयोग करता रहेगा और बंद करने की जांच सफल दिखेगी, जब तक प्रदाता आखिरकार उसे रोक न दे।

## निरस्तीकरण शुरू से अंत तक एक घटना है

निरस्तीकरण तभी काम करता है जब जीवनचक्र अधिकारी जारीकर्ता पर क्रेडेंशियल बंद करे और गेटवे कैश किए गए जनरेशन का आगे कोई उपयोग रोक दे। एक तरफ सफ़ाई अधूरी है।

Vault ऑपरेटर को ठोस तरीका देता है। `vault lease revoke` एक लीज़ को अमान्य करता है और प्रीफ़िक्स निरस्तीकरण किसी पथ के नीचे की लीज़ बंद कर सकता है। HashiCorp के कमांड दस्तावेज़ में सामान्य निरस्तीकरण और जबरन हटाने का अंतर भी है। जबरन हटाने पर Vault लीज़ भूल सकता है, भले सीक्रेट इंजन उसे लक्ष्य पर निरस्त न कर पाया हो। तब Vault और लक्ष्य का हिसाब अलग हो जाता है। ऐसी चेतावनी को सफल सफ़ाई का संदेश नहीं, सुरक्षा घटना मानें।

जीवनचक्र सिस्टम निरस्तीकरण संकेत भेज सकता हो तो डेस्कटॉप गेटवे उसे ले, लेकिन मौजूदा स्थिति खींचकर जांचने की रक्षा भी रखे। संवेदनशील उपयोग से पहले वह जनरेशन फिर जांच सकता है या रेफ़रेंस दोबारा हल कर सकता है। छोटी Vault लीज़ में कड़ा TTL और छोटा कैश पर्याप्त हो सकता है। स्थिर API टोकन में रोटेशन समन्वयक कटओवर के साथ गेटवे कैश हटाए और पुराने टोकन को किसी हानिरहित एंडपॉइंट पर सीधे जांचे।

पहले से चल रही कार्रवाइयों के लिए साफ़ नियम चाहिए। निरस्तीकरण उन कामों को रोक सकता है जो शुरू नहीं हुए। वह रिमोट API द्वारा स्वीकार अनुरोध, कमिट हो चुका डेटाबेस ट्रांज़ैक्शन या shell को दिया SSH कमांड वापस नहीं ले सकता। गेटवे को कार्रवाई की स्थिति `authorized`, `dispatched`, `acknowledged` या `unknown` लिखनी चाहिए, यह दावा नहीं करना चाहिए कि निरस्तीकरण ने असर मिटा दिया।

नियंत्रित परीक्षण साधन में पुराना जनरेशन रखकर पूरा पथ जांचें:

1. गेटवे से हानिरहित रीड चलाएं और जनरेशन दर्ज करें।
2. लीज़ निरस्त करें या स्थिर क्रेडेंशियल रोटेट करके जारीकर्ता पर पुराना मान बंद करें।
3. गर्म कैश वाले गेटवे से वही कार्रवाई दोबारा चलाएं।
4. परीक्षण साधन से बंद क्रेडेंशियल का सीधा उपयोग करें।
5. दोनों विफलताएं पक्की करें और उन्हें जीवनचक्र तथा निष्पादन रिकॉर्ड से जोड़ें।

अगर तीसरा चरण सफल है, तो गेटवे ने निरस्तीकरण अनदेखा किया। अगर चौथा सफल है, तो जीवनचक्र वर्कफ़्लो ने जारीकर्ता पर क्रेडेंशियल बंद नहीं किया। अगर दोनों विफल हों लेकिन रिकॉर्ड एक ही जनरेशन न बता सकें, तो घटना जांचने वाले अब भी साबित नहीं कर पाएंगे कि क्या हुआ।

## जवाबदेही को जारीकर्ता और कॉलर दोनों की पहचान चाहिए

जीवनचक्र लॉग बताते हैं कि क्रेडेंशियल किसने बनाया, नवीनीकृत, रोटेट या निरस्त किया। गेटवे लॉग बताते हैं कि किस स्थानीय प्रोसेस ने कौन सी कार्रवाई मांगी, किसने मंजूरी दी, किस लक्ष्य ने उसे पाया और क्या परिणाम लौटा। कोई एक लॉग दूसरे का विकल्प नहीं है।

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

इसलिए गेटवे को स्थिर सेशन पहचान और भरोसेमंद प्रोसेस पहचान चाहिए। अकेला PID कमजोर है, क्योंकि ऑपरेटिंग सिस्टम PID दोबारा इस्तेमाल करते हैं और प्रोसेस बच्चे शुरू कर सकते हैं। प्लेटफ़ॉर्म से उपलब्ध executable पहचान, मौजूद होने पर उसकी साइनिंग अथॉरिटी, पैरेंट प्रोसेस, सेशन शुरू और समाप्त होने का समय और अनुमान न लगाया जा सकने वाला सेशन ID दर्ज करें। हर कार्रवाई रिकॉर्ड को उसी सेशन से बांधें।

जोड़ने वाला फ़ील्ड क्रेडेंशियल जनरेशन है। Vault लीज़ ID या स्थिर रोटेशन इवेंट ID को जीवनचक्र रिकॉर्ड और गेटवे कार्रवाई रिकॉर्ड दोनों में रखें। API रिमोट अनुरोध ID दे तो वह भी रखें। किसी घटना में जांचकर्ता इस कड़ी पर चल सकें:

```text
agent session -> gateway action -> credential generation -> issuer event -> remote request
```

इन लॉग में सीक्रेट मान, Authorization हेडर, निजी कुंजी या हल किए गए एनवायरनमेंट ब्लॉक न रखें। लॉग बनने के बाद जानकारी छिपाना भरोसेमंद नहीं है, क्योंकि exception, debug dump और tracing exporter पहले कॉपी कर सकते हैं। सुरक्षित फ़ील्ड की अनुमति सूची से संरचित रिकॉर्ड बनाएं।

जब सभी कार्रवाइयां लंबे समय तक चलने वाला एक सर्विस अकाउंट साझा करती हैं और कोई गेटवे रिकॉर्ड नहीं बचता, तब भी जवाबदेही विफल होती है। रोटेशन खाते का जीवन छोटा करता है, कॉलर की पहचान नहीं करता। इसके उलट, गेटवे लीज़ या वर्ज़न छोड़ दे तो बेहतरीन प्रोसेस लॉग भी साबित नहीं कर सकते कि लक्ष्य तक कौन सा जनरेशन पहुंचा। दोनों पहलू बचाएं।

## एनवायरनमेंट इंजेक्शन सीमा पार कर देता है

जो वर्कफ़्लो एजेंट के एनवायरनमेंट में सीक्रेट डालता है, वह एजेंट को उसका कब्जा देता है। तब डेस्कटॉप गेटवे हर इस्तेमाल नियंत्रित नहीं करता। 1Password CLI के तरीकों में यह अंतर खास है, क्योंकि आसानी से सीक्रेट लाना निष्पादन नियंत्रण जैसा दिख सकता है।

1Password दस्तावेज़ कहता है कि `op run` एक सबप्रोसेस शुरू करता है और सीक्रेट उस प्रोसेस को एनवायरनमेंट वेरिएबल के रूप में देता है। इससे कमिट की गई `.env` फ़ाइल में प्लेनटेक्स्ट रखने से बच सकते हैं, लेकिन चाइल्ड प्रोसेस वेरिएबल पढ़, प्रिंट, दूसरे प्रोसेस को दे या बिना मंजूरी वाले अनुरोध में इस्तेमाल कर सकता है। `op inject` रेफ़रेंस को कॉन्फ़िगरेशन स्ट्रीम में हल करता है और `op read` हल किया मान कॉलर को देता है। इनमें से कोई रास्ता उस गेटवे के बराबर नहीं है जो सीक्रेट एजेंट से बाहर रखता है।

इंसान द्वारा चलाए जाने वाले और व्यापक SDK व्यवहार मांगने वाले स्क्रिप्ट में एनवायरनमेंट इंजेक्शन स्वीकार्य हो सकता है। ऐसे स्वचालित एजेंट में, जिसके नेटवर्क और SSH कार्यों को हर उपयोग पर नियंत्रण चाहिए, यह सीमा तोड़ देता है। सीमित retrieval पहचान गेटवे को दें और एजेंट को कार्रवाई के आकार वाले टूल दें।

शुरुआती क्रेडेंशियल पर फिर भी ध्यान चाहिए। 1Password कम से कम अधिकार के लिए सर्विस अकाउंट सुझाता है और पहुंच को खास वॉल्ट तक सीमित करने देता है। इससे गेटवे क्या ला सकता है, उसका दायरा छोटा होता है। सीक्रेट मिलने के बाद गेटवे क्या कर सकता है, यह सीमित नहीं होता, इसलिए कार्रवाई की सतह, मंजूरी और बाहर जाने वाले लक्ष्य की जांच जरूरी रहती है।

एक लोकप्रिय जुगाड़ से बचें: wrapper में सीक्रेट हल करें, क्रेडेंशियल को पैरामीटर बनाकर गेटवे को दें और वादा करें कि गेटवे उसे छिपा देगा। एजेंट या wrapper के पास मान पहले ही आ चुका है, shell history और process inspection उसे दिखा सकते हैं और गेटवे साबित नहीं कर सकता कि दूसरा उपयोग नहीं हुआ। सीमा के पार रेफ़रेंस भेजें और निष्पादन करने वाले कंपोनेंट के अंदर हल करें।

## मंजूरी रोटेशन से स्वतंत्र है

अभी रोटेट हुआ क्रेडेंशियल भी गलत कार्रवाई अधिकृत कर सकता है और ध्यान से मंजूर कार्रवाई पुराने क्रेडेंशियल का उपयोग कर सकती है। रोटेशन और मंजूरी अलग जोखिम घटाते हैं, इसलिए कोई एक चुपचाप दूसरे का स्थान न ले।

जीवनचक्र अधिकारी पूछता है, "क्या यह क्रेडेंशियल जनरेशन मान्य है?" गेटवे पूछता है, "क्या यह कॉलर अभी यह परिणाम ला सकता है?" रिमोट सेवा पूछती है, "क्या इस प्रमाणित पहचान को अनुमति है?" तीनों उत्तर दिखने चाहिए। हरा मंजूरी कार्ड तब तक क्रेडेंशियल के नया होने का संकेत न दे जब तक गेटवे ने जांच न की हो। मौजूदा लीज़ विनाशकारी कॉल की इंसानी मंजूरी न टाले।

मंजूरी दोबारा उपयोग करने का दायरा तय होना चाहिए। गेटवे एजेंट सेशन मंजूर करे तो उसे प्रोसेस सेशन से बांधे और प्रोसेस समाप्त होने या यूज़र के निरस्त करने पर खत्म करे। किसी क्रेडेंशियल पर हर कॉल में मंजूरी लगी हो तो रोटेशन के बाद नया जनरेशन भी वही शर्त रखे। नया मान संवेदनशील क्रेडेंशियल को कमजोर डिफ़ॉल्ट पर वापस न करे।

मंजूरी के पाठ में कार्रवाई, लक्ष्य और कॉलर हों, सीक्रेट नहीं। "साइन किए प्रोसेस X को उत्पादन पर `POST /deployments` चलाने दें" व्यक्ति को निर्णय लायक जानकारी देता है। "API key prod-3 का उपयोग मंजूर करें" इंसान को इन्वेंटरी नाम से इरादा समझने को मजबूर करता है और अस्पष्ट संकेत मंजूर करने की आदत डालता है।

Sallyport macOS पर HTTP API और SSH कार्रवाइयों के लिए निष्पादन वाला हिस्सा लागू करता है: एजेंट उसके MCP shim से जुड़ते हैं, क्रेडेंशियल उसके एन्क्रिप्टेड इन-प्रोसेस वॉल्ट में रहते हैं और ऐप कार्रवाई करता है। उसके निश्चित नियंत्रण बंद वॉल्ट, प्रोसेस सेशन मंजूरी और हर उपयोग पर वैकल्पिक मंजूरी को अलग रखते हैं। जब कोई दूसरा सिस्टम क्रेडेंशियल बनाता या रोटेट करता है, तब भी बाहरी जीवनचक्र मालिक जरूरी है।

## दोहरा रोटेशन दो दिखावटी अधिकारी बनाता है

जीवनचक्र सिस्टम और गेटवे को एक ही क्रेडेंशियल स्वतंत्र रूप से रोटेट न करने दें। टीमें कभी इसे कई परतों की सुरक्षा कहती हैं, लेकिन दो लेखक अस्पष्ट जनरेशन, अविश्वसनीय rollback और निरस्तीकरण की दौड़ बनाते हैं।

मान लें कोई स्थिर प्रदाता दो API कुंजियां एक साथ सक्रिय रहने देता है। 1Password वर्कफ़्लो कुंजी B बनाता, जांचता और आधिकारिक आइटम अपडेट करता है, जबकि छोटी कटओवर अवधि के लिए कुंजी A सक्रिय रहती है। उसी समय गेटवे का स्थानीय scheduler कुंजी C बनाता है, क्योंकि उसकी A की कॉपी तय उम्र तक पहुंच गई। कुछ प्रोसेस B हल करते हैं, गर्म कैश में A है और गेटवे C इस्तेमाल करने लगता है। A को बंद करना लगभग कुछ साबित नहीं करता, क्योंकि किसी को नहीं पता कि B या C में किसे बचना चाहिए।

एक समन्वयक को रोटेशन state machine का मालिक होना चाहिए। Vault डायनेमिक सीक्रेट में Vault role और lease के माध्यम से यह काम पहले से करता है। गेटवे लीज़ लेता है और रिमोट खाता रोटेट नहीं करता। 1Password से चलने वाले स्थिर रिकॉर्ड में रोटेशन काम प्रदाता और रखे आइटम को मिलाकर बदल सकता है। गेटवे जनरेशन बदलाव देखता और कैश हटाता है। गेटवे का स्थानीय encryption रखी कॉपी बचाता है, लेकिन storage को दोबारा encrypt करना जारीकर्ता क्रेडेंशियल रोटेशन नहीं है।

ठीक स्थिर रोटेशन में एक `rotated` flag के बजाय स्पष्ट स्थितियां होती हैं:

```text
prepared -> activated -> distributed -> old_disabled -> verified
                |             |
                +-> rollback <-+
```

`prepared` का अर्थ है जारीकर्ता ने उम्मीदवार जनरेशन बनाया। `activated` बताता है कि उससे हानिरहित प्रमाणित अनुरोध सफल हुआ। `distributed` बताता है कि आधिकारिक रेफ़रेंस उम्मीदवार पर हल होता है और गेटवे ने नया जनरेशन स्वीकार किया। `old_disabled` में जारीकर्ता पुराना जनरेशन अस्वीकार करता है। `verified` में गर्म कैश वाला गेटवे और सीधा परीक्षण साधन दोनों पुराने मान से विफल होते हैं। rollback तभी उपलब्ध रहे जब पुराना जनरेशन जानबूझकर सक्रिय हो।

गेटवे को स्थिति बदलाव में रेफ़रेंस और जनरेशन ID मिलने चाहिए, दोनों सीक्रेट मान कभी नहीं। invalidation event में `credential_ref`, `old_generation`, `new_generation` और `effective_at` हो सकते हैं। मिलने पर गेटवे पुरानी कैश प्रविष्टि हटाए, उससे बंधे कतार के काम रद्द करे और अगली मंजूर कार्रवाई पर फिर हल करे। event न पहुंचे तो भी कैश सीमा और जनरेशन जांच को आखिर आधिकारिक मान तक पहुंचना होगा।

Rollback पर भी उतनी सख्ती चाहिए। प्रदाता कुंजी A बंद कर चुका हो तो 1Password आइटम को A पर वापस करना काम नहीं करेगा। पुराने display name से नया मान जारी करना भी पुराना जनरेशन बहाल नहीं करता। समन्वयक केवल वही बनाए या फिर सक्रिय करे जो प्रदाता समर्थन करता है, नया जनरेशन ID दे और वितरण तथा जांच के सामान्य चरण फिर चलाए।

स्वामित्व रिकॉर्ड इतना छोटा रखें कि घटना के समय पढ़ा जा सके। हर क्रेडेंशियल रेफ़रेंस के लिए एक रोटेशन समन्वयक, एक जारीकर्ता, एक गेटवे कैश नीति, एक निरस्तीकरण कमांड और emergency retirement शुरू करने के अधिकार वाला व्यक्ति या सेवा लिखें। अगर दो पंक्तियां अगला जनरेशन बनाने का दावा करें तो रुकें। यह redundancy नहीं, सीक्रेट सामग्री के साथ दौड़ है।

## हर बॉक्स के बजाय जोड़ की जांच करें

Vault की जांच और गेटवे की जांच दोनों सफल होने से उनका हैंडऑफ़ साबित नहीं होता। सीमा पर पुराना कैश, ओवरलैप जनरेशन, देर की मंजूरी, विफल निरस्तीकरण, प्रोसेस restart और गायब join field जांचें।

एक अस्थायी लक्ष्य पहचान लेकर उत्पादन से पहले यह acceptance matrix चलाएं:

| स्थिति | गेटवे का अपेक्षित निर्णय | जरूरी सबूत |
| --- | --- | --- |
| मौजूदा जनरेशन, पर्याप्त TTL | निष्पादित करें | सेशन, कार्रवाई, जनरेशन, रिमोट अनुरोध |
| मौजूदा जनरेशन, बहुत छोटा TTL | फिर हल करें या मना करें | मिला TTL और स्थानीय समय निर्णय |
| रिकॉर्ड रोटेट, पुराना कैश गर्म | पुराना जनरेशन अस्वीकार करें | कैश invalidation और जारीकर्ता का इनकार |
| Vault लीज़ निरस्त | पुरानी लीज़ दोहराए बिना मना करें | निरस्तीकरण रिकॉर्ड और लक्ष्य auth विफलता |
| इंतजार में मंजूरी समाप्त | मना करें या नई मंजूरी मांगें | मंजूरी समय सीमा और कोई dispatch event नहीं |
| मंजूरी के बाद गेटवे restart | तय सेशन निर्णय फिर मांगें | नई सेशन पहचान और पुराने सेशन का अंत |
| जारीकर्ता निरस्तीकरण विफल | घटना दर्ज करें, सबूत रखें | प्रदाता त्रुटि और अनसुलझा जनरेशन |
| लक्ष्य बंद टोकन स्वीकार करे | जीवनचक्र जांच विफल मानें | सीधी जांच का परिणाम और rollback निर्णय |

मैट्रिक्स उन्हीं रास्तों पर चलाएं जिन्हें एजेंट उपयोग करेंगे। संकेत पर `401` लौटाने वाला mock यह नहीं बता सकता कि असली डेटाबेस plugin ने यूज़र हटाया, प्रदाता ओवरलैप कुंजियां स्वीकार करता है या क्रेडेंशियल निरस्तीकरण के बाद SSH connection जीवित है।

साफ़ pass criteria रखें। `not_after` के बाद कोई कार्रवाई शुरू न हो। निरस्त या बंद जनरेशन गर्म कैश से भी विफल हो। हर निष्पादन रिकॉर्ड बिना सीक्रेट सामग्री के एक जीवनचक्र जनरेशन से जुड़े। जारीकर्ता निरस्तीकरण विफल हो तो सफल retirement का दावा न हो। मंजूरी रिकॉर्ड प्रोसेस सेशन पहचाने और configured control के अनुसार समाप्त हो।

सीमा तब उपयोगी है जब खराबी अपने हिस्से में रुके। Vault या 1Password रोटेशन वर्कफ़्लो एजेंट को सीक्रेट मान सिखाए बिना क्रेडेंशियल बदल सके। गेटवे जारीकर्ता बने बिना मंजूरी व्यवहार बदल सके। घटना संभालने वाले जनरेशन निरस्त कर सकें, सेशन रोक सकें और देख सकें कि कौन से रिमोट परिणाम पहले हो चुके होंगे। अगर जोड़ की जांच इन तीन कामों को स्वतंत्र रूप से साबित नहीं करती, तो दूसरा सीक्रेट backend जोड़ने से पहले अनुबंध ठीक करें।