Self-hosted secrets manager: सही विकल्प कैसे चुनें

Self-hosted secrets manager और password manager के बीच का अंतर

एक self-hosted secrets manager प्रक्रियाओं (processes) को क्रेडेंशियल्स प्रदान करता है। एक password manager लोगों को क्रेडेंशियल्स प्रदान करता है। बाकी सब कुछ इसी एक अंतर से उत्पन्न होता है। एक password manager को वह इंसान अनलॉक करता है जो वहां मौजूद है और ध्यान दे रहा है। एक secrets manager को आपके application को रात के 03:00 बजे डेटाबेस पासवर्ड देना होता है जब कोई भी जाग नहीं रहा होता है।

इनके विफल होने के तरीके (failure modes) इस तरह से अलग हैं जो मायने रखते हैं। एक locked password manager केवल एक असुविधा है: आप फिर से master password टाइप करते हैं। एक sealed secrets manager एक outage है: हर वह service जो sealed रहने के दौरान restart होती है, वह बिना क्रेडेंशियल्स के शुरू होती है और बंद ही रहती है। Vaultwarden को अपने स्वयं के password manager के रूप में चलाना मानवीय समस्या को अच्छी तरह से हल करता है। यह मशीन की समस्या को हल नहीं करता है, और इसे कभी इसके लिए बनाया भी नहीं गया था। यदि आप इसके साथ-साथ किसी एक को चलाते हैं, तो इसके admin token और backup file को सुरक्षित करना vault contents की तुलना में अधिक महत्वपूर्ण है, क्योंकि client पहले से ही vault contents को encrypt करता है, और Vaultwarden पर एक hardening pass इन दोनों को कवर करता है।

एक सर्वर के लिए व्यावहारिक विकल्प दो समूहों में आते हैं। OpenBao और Infisical सेवाएं (services) हैं: एक API, एक डेटाबेस, TLS (transport layer security), एक login step, और एक ऐसी प्रक्रिया जिसे अब आपको जीवित रखना होगा। age के साथ SOPS, systemd credentials और Docker secrets फाइलें हैं: जो rest पर encrypted रहती हैं, पहले से चल रही किसी चीज़ द्वारा decrypt की जाती हैं, और इसमें मॉनिटर करने के लिए कुछ भी अतिरिक्त नहीं होता है।

यहाँ स्पष्ट उत्तर दिया गया है। एक ऐसे सर्वर के लिए जिस पर एक या दो लोग हैं, फाइल-आधारित विकल्प आमतौर पर सही होते हैं। एक OpenBao जिसे कोई भी ठीक से unseal नहीं करता है और कोई भी rotate नहीं करता है, वह mode 600 वाली env फाइल से भी बदतर है, क्योंकि यह एक अतिरिक्त moving part और एक ऐसा backup जोड़ता है जिसे आप गलत तरीके से manage करेंगे, और यह आपको ऐसी कोई rotation नहीं देता है जिसे आप पहले से ही मैन्युअल रूप से नहीं कर रहे थे।

क्या 600 मोड वाली env फाइल पर्याप्त है?

अक्सर, हाँ। यह जिस खतरे से बचाव करती है, वह है सर्वर पर मौजूद किसी अन्य यूजर द्वारा आपके डेटाबेस पासवर्ड को पढ़ लेना। Unix फाइल अनुमतियाँ (permissions) ऐसा करती हैं, और वे नेटवर्क चालू होने से पहले ही प्रभावी हो जाती हैं।

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

इसे दोनों तरफ से जाँचें:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

पहला कमांड फाइल को प्रिंट करता है। दूसरा कमांड cat: /etc/myapp/env: Permission denied प्रिंट करता है, क्योंकि nobody, myapp ग्रुप में नहीं है और फाइल में कोई वर्ल्ड-रीडेबल बिट्स नहीं हैं। यही पूरा सुरक्षा मॉडल है, और यह वास्तविक है।

लीक तब होता है जब इसके बाद की प्रक्रिया होती है। EnvironmentFile= वाली एक systemd यूनिट उन मानों (values) को प्रोसेस एनवायरनमेंट में कॉपी कर देती है, और प्रोसेस एनवायरनमेंट पठनीय (readable) होता है।

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp

sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

यह आपके सीक्रेट्स को प्लेनटेक्स्ट में प्रिंट करता है, क्योंकि /proc/<pid>/environ को root और उस यूजर द्वारा पढ़ा जा सकता है जिसके तहत प्रोसेस चल रही है। एक क्रैश रिपोर्टर जो रिपोर्ट के साथ एनवायरनमेंट को अटैच करता है, वह भी यही देखता है। उसी अकाउंट के तहत चलने वाला कोई भी टूल भी ऐसा ही करता है, इसीलिए AI एजेंट्स से सीक्रेट्स को दूर रखना एनवायरनमेंट से उन्हें हटाने से शुरू होता है। फाइल को एक समर्पित कम-विशेषाधिकार वाले सर्विस यूजर के साथ जोड़ें ताकि "वह यूजर जिसके तहत प्रोसेस चल रही है" वह root न हो।

age के साथ SOPS: एन्क्रिप्टेड सीक्रेट्स जिन्हें आप git में कमिट कर सकते हैं

SOPS (secrets operations) YAML या JSON फ़ाइल में वैल्यूज को एन्क्रिप्ट करता है और कीज़ (keys) को क्लियरटेक्स्ट में छोड़ देता है। age एक छोटा एन्क्रिप्शन टूल है जो आपको एक की-पेयर देता है और इसके लिए किसी की-सर्वर की आवश्यकता नहीं होती। साथ मिलकर, ये आपको अपने कोड के साथ secrets.enc.yaml कमिट करने की सुविधा देते हैं, और git diff अभी भी आपको यह बताता है कि कौन सी सेटिंग बदली है, बिना यह बताए कि वह किस वैल्यू में बदली है।

age, Ubuntu 24.04 में पैकेज्ड है। SOPS नहीं है, इसलिए रिलीज पेज से .deb लें। अगस्त 2026 तक वर्जन 3.13.3 करंट था।

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

एक की-पेयर जनरेट करें। age-keygen प्राइवेट की को फ़ाइल में लिखता है और पब्लिक की को प्रिंट करता है, इसलिए आपको Public key: age1... से शुरू होने वाली एक लाइन दिखाई देगी।

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

पब्लिक की को रिपॉजिटरी के रूट में .sops.yaml में रखें, ताकि आपको कमांड लाइन पर रेसिपिएंट को याद रखने की आवश्यकता न पड़े।

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c

sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

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

रनटाइम पर, वैल्यूज को केवल एक प्रोसेस को दें और किसी और को नहीं:

sops exec-env secrets.enc.yaml './myapp'

sops exec-env मेमोरी में डिक्रिप्ट करता है और चाइल्ड प्रोसेस एनवायरनमेंट में वैल्यूज सेट करता है, इसलिए डिस्क पर कोई भी प्लेनटेक्स्ट नहीं लिखा जाता है। पिछले सेक्शन की एनवायरनमेंट संबंधी चेतावनी उस चाइल्ड प्रोसेस पर भी लागू होती है।

यहाँ दो चीजें लोगों को परेशान करती हैं। systemd के तहत Failed to get the data key required to decrypt the SOPS file एरर का मतलब लगभग हमेशा यह होता है कि SOPS ने गलत होम डायरेक्टरी में देखा है, क्योंकि एक यूनिट आपके HOME को इनहेरिट नहीं करती है। यूनिट में Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt के साथ पाथ को स्पष्ट रूप से सेट करें। इसके अलावा, .sops.yaml को एडिट करने से पहले से मौजूद कोई भी चीज़ फिर से एन्क्रिप्ट नहीं होती है: किसी सहकर्मी की पब्लिक की जोड़ने का असर केवल नई फ़ाइलों पर पड़ता है, इसलिए प्रत्येक मौजूदा फ़ाइल पर sops updatekeys secrets.enc.yaml चलाएं। यदि आपका कॉन्फ़िगरेशन पहले से ही Ansible के माध्यम से चलता है, तो Ansible Vault के साथ उन्हीं वैल्यूज को एन्क्रिप्ट करना दूसरे टूल के बिना उसी परिणाम तक पहुँचता है।

systemd credentials: secrets जो कभी environment तक नहीं पहुँचते

Ubuntu 24.04 में systemd 255 शामिल है, इसलिए इसके लिए किसी इंस्टॉलेशन की आवश्यकता नहीं है। systemd-creds होस्ट पर एक secret को encrypt करता है, और systemd उसे एक private directory में decrypt करता है जिसे केवल वही एक service पढ़ सकती है।

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred

[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

Service इस value को $CREDENTIALS_DIRECTORY द्वारा नामित directory के अंदर db_password नामक file से पढ़ती है। यह value environment में नहीं होती है, इसलिए /proc/<pid>/environ कुछ भी उपयोगी नहीं दिखाता है, और plaintext कभी भी root filesystem पर नहीं पहुँचता है।

किसी unit को इसकी ओर इंगित करने से पहले verify करें कि file decrypt हो रही है:

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

जानें कि किस key ने इसे encrypt किया है, क्योंकि यही तय करता है कि आपका backup किसी काम का है या नहीं। default --with-key=auto TPM2 (trusted platform module version 2) chip का उपयोग करता है जब वह मौजूद और उपयोग करने योग्य हो, अन्यथा यह host key का उपयोग करता है। अधिकांश VPS instances में TPM2 नहीं होता है।

systemd-analyze has-tpm2

no का अर्थ है कि host key का उपयोग किया गया था, और वह key /var/lib/systemd/credential.secret में रहती है, जिसे केवल root ही पढ़ सकता है। db_password.cred को उस file के बिना एक नए VPS पर restore करें और कुछ भी कभी decrypt नहीं होगा। credential.secret को उसी backup में copy करें, या plaintext को कहीं ऐसी जगह रखें जहाँ आप अभी भी पहुँच सकें।

Docker secrets: /run/secrets के अंतर्गत फाइलें

Compose होस्ट से एक फाइल पढ़ता है और उसे कंटेनर में /run/secrets/<name> पर माउंट करता है।

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt

docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

पहला कमांड secret को प्रिंट करता है। दूसरा केवल DB_PASSWORD_FILE=/run/secrets/db_password को प्रिंट करता है, जो कि मुख्य बात है: यह मान कभी भी कंटेनर environment में नहीं होता है, इसलिए यह docker inspect आउटपुट में दिखाई नहीं देता है। कई official images पहले से ही इस संरचना की अपेक्षा करती हैं, और Postgres image POSTGRES_PASSWORD_FILE को बिल्कुल इसी तरह पढ़ती है।

यह स्पष्ट रखें कि यह क्या है। Swarm mode के बाहर किसी भी स्तर पर कोई encryption नहीं होता है: ./db_password.txt होस्ट पर एक plaintext फाइल है, और इसकी एकमात्र सुरक्षा इसका mode और इसका owner है। दोनों को आप स्वयं सेट करें, क्योंकि Compose बिना किसी चेतावनी के world readable फाइल को भी खुशी-खुशी माउंट कर देगा। सादे env_file शॉर्टकट की तुलना में व्यापक tradeoffs Compose env फाइलों और secrets के लिए गाइड में दिए गए हैं।

OpenBao और Vault को चलाने की वास्तविक लागत

OpenBao, HashiCorp Vault का Linux Foundation फोर्क है। इसे 2023 में HashiCorp द्वारा Vault को Business Source License के तहत पुनः लाइसेंस करने के बाद शुरू किया गया था। OpenBao, MPL 2.0 (Mozilla Public License) के अंतर्गत आता है। अगस्त 2026 तक Release 2.6.2 वर्तमान संस्करण था। नीचे दी गई लगभग सभी बातें Vault पर भी लागू होती हैं, क्योंकि फोर्क ने समान कमांड इंटरफेस को बनाए रखा है।

docker pull docker.io/openbao/openbao

यदि आप चाहते हैं कि apt अपग्रेड को मैनेज करे, तो Debian और Ubuntu पैकेज OpenBao डाउनलोड पेज पर उपलब्ध हैं। सर्वर को एक ऐसी कॉन्फ़िगरेशन फ़ाइल की आवश्यकता होती है जिसमें एक listener और एक storage backend हो:

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

फिर इसे एक बार स्टार्ट करें:

bao operator init

डिफ़ॉल्ट रूप से, यह root key को 5 हिस्सों में विभाजित करता है और unseal करने के लिए उनमें से 3 की आवश्यकता होती है, जो -key-shares और -key-threshold फ्लैग्स हैं। यह इन हिस्सों और शुरुआती root token को केवल एक बार प्रिंट करता है और दोबारा कभी नहीं दिखाता।

अब वह हिस्सा जिसे अधिकांश तुलनाओं में छोड़ दिया जाता है। रीस्टार्ट किया गया सर्वर एक sealed सर्वर होता है। OpenBao root key को केवल मेमोरी में रखता है, इसलिए रीस्टार्ट के बाद यह तब तक अपने स्टोरेज को डिक्रिप्ट नहीं कर सकता जब तक कोई व्यक्ति आवश्यक संख्या में हिस्से (shares) प्रदान न करे। इसलिए, kernel अपडेट या out of memory के कारण होने वाली किल का परिणाम एक sealed सर्वर और उन एप्लिकेशन्स के रूप में निकलता है जो लॉग इन नहीं कर सकते।

एक व्यक्ति के VPS पर Shamir split किसी चीज की सुरक्षा नहीं करता, क्योंकि सभी पाँचों हिस्से एक ही व्यक्ति के एक ही पासवर्ड मैनेजर में होते हैं। Auto unseal की सुविधा key को किसी विश्वसनीय डिवाइस या सर्विस पर ले जाती है। बड़े क्लाउड पर इसका अर्थ एक मैनेज्ड की-सर्विस होता है, और आपके VPS पर इसका आमतौर पर अर्थ उस डिस्क पर रखी एक की-फ़ाइल है जिसे यह सुरक्षित करती है। यह सुरक्षा में वास्तविक कमी है, जिसे एक ऐसे सर्वर के लिए बदला जाता है जो रीबूट के बाद अपने आप वापस आ जाता है। इस समझौते को समझदारी से करें और लिख लें कि आपने कौन सा विकल्प चुना है।

Infisical: एक UI, एक डेटाबेस, और एक मास्टर की जो आपके पास रहती है

Infisical एक secrets प्लेटफॉर्म है जिसमें वेब इंटरफेस, प्रोजेक्ट्स, एनवायरनमेंट और प्रति-उपयोगकर्ता एक्सेस कंट्रोल की सुविधा है। इसे Compose के साथ self-host करना संक्षिप्त है:

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

उस अंतिम कमांड से पहले .env को एडिट करें। दो मान आपके अपने होने चाहिए, और उनमें से एक को बाद में कभी नहीं बदलना चाहिए:

openssl rand -hex 16
openssl rand -base64 32

पहला ENCRYPTION_KEY है, जो 16 बाइट की एक hex स्ट्रिंग है। यह वह की (key) है जिससे आपके secrets PostgreSQL के अंदर एन्क्रिप्ट होते हैं, इसलिए इसे खोने का मतलब है कि आपका सटीक डेटाबेस बैकअप केवल ciphertext का ढेर बनकर रह जाएगा, और इसे चलते हुए इंस्टेंस पर बदलने से मौजूदा secrets डिक्रिप्ट होना बंद हो जाएंगे। दूसरा AUTH_SECRET है, जो सेशन के लिए उपयोग की जाने वाली 32 बाइट की base64 स्ट्रिंग है। SITE_URL वह पूर्ण URL होना चाहिए जिस पर आप वास्तव में एक्सेस करेंगे, जिसमें प्रोटोकॉल भी शामिल हो, अन्यथा लॉगिन रीडायरेक्ट काम नहीं करेगा।

Infisical तब OpenBao से बेहतर विकल्प है जब आपको वास्तव में लोगों की आवश्यकता हो: एक छोटी टीम के लिए वेब इंटरफेस और एनवायरनमेंट के बीच अलगाव, न कि ऐसे डेटाबेस क्रेडेंशियल्स जो अपने आप समाप्त हो जाते हैं। इसके लिए आपको PostgreSQL, Redis और एक TLS सर्टिफिकेट की आवश्यकता होती है, जिन्हें अब आपको स्वयं पैच और बैकअप करना होगा।

जब secrets service डाउन हो और आपका app restart हो तो क्या होता है

यह प्रश्न तय करता है कि क्या secrets service को एक ही box पर होना चाहिए। फाइलें नेटवर्क शुरू होने से पहले ही पढ़ी जा सकती हैं, लेकिन एक service नहीं।

Box को reboot करें, तो आपका application और OpenBao एक ही समय पर start होते हैं। Application अपने database password के लिए अनुरोध करता है, OpenBao अभी भी sealed है, अनुरोध विफल हो जाता है, और systemd application को एक loop में तब तक restart करता रहता है जब तक कि कोई व्यक्ति unseal shares को paste न कर दे। कुछ भी टूटा नहीं है, लेकिन कुछ भी चल भी नहीं रहा है।

इसे संभालने के दो ईमानदार तरीके हैं। Units को क्रमबद्ध करें और application को retry करने दें: After= secrets service, साथ ही Restart=on-failure और एक RestartSec= जो इतना लंबा हो कि आप API पर लगातार दबाव न डालें। या फिर boot के समय के बजाय deploy के समय secret प्राप्त करें: secret को mode 600 फाइल या systemd credential में render करें, ताकि चल रहा system API के बजाय एक फाइल पर निर्भर रहे।

Token की समाप्ति धीमी गति वाली घड़ी पर एक ही समस्या है। OpenBao tokens और leases की एक समय सीमा (time to live) होती है, इसलिए एक लंबे समय तक चलने वाली प्रक्रिया जो कभी renew नहीं होती, वह किसी भी deploy से असंबंधित समय पर access खो देती है। वह विफलता विशेष रूप से भ्रमित करने वाली होती है क्योंकि उस दिन कुछ भी नहीं बदला होता है।

स्टोर का बैकअप लेना

यहाँ दिए गए प्रत्येक विकल्प के लिए एक key आवश्यक है, और उस key के बिना बैकअप बेकार है। यह नोट कर लें कि आपकी key कहाँ स्थित है।

एक env file के लिए, वह file ही secret है, इसलिए बैकअप को encrypted होना चाहिए। SOPS के लिए, encrypted file को कहीं भी public स्थान पर रखा जा सकता है, लेकिन ~/.config/sops/age/keys.txt पर स्थित age private key वह वस्तु है जिसे आपको खोना नहीं चाहिए। systemd credentials के लिए, .cred files के साथ-साथ /var/lib/systemd/credential.secret का भी बैकअप लें। Infisical के लिए, PostgreSQL का dump लें और ENCRYPTION_KEY को उससे अलग किसी स्थान पर सुरक्षित रखें।

raft storage के साथ OpenBao अपना snapshot स्वयं लेता है:

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

snapshot में आपका encrypted storage होता है, इसलिए इसे एक नए सर्वर पर restore करने के लिए भी bao operator init से unseal shares की आवश्यकता होती है। यदि आप snapshots को object storage पर copy करने का nightly job चलाते हैं, लेकिन shares को कहीं भी सुरक्षित नहीं रखते हैं, तो यह किसी भी काम का बैकअप नहीं है। उस पर निर्भर होने से पहले एक throwaway VPS पर restore प्रक्रिया का परीक्षण करें।

Audit logging: कौन से secret को किसने पढ़ा

Files आपको कोई audit trail नहीं देती हैं। mode और owner केवल यह बताते हैं कि secret को कौन पढ़ सकता था। वे कभी यह नहीं बताते कि किसने पढ़ा। path पर watch के साथ auditd इसका सबसे करीबी विकल्प है, और यह केवल यह रिपोर्ट करता है कि file खोली गई थी, न कि कौन सी value का उपयोग किया गया।

OpenBao स्पष्ट रूप से enable किए गए audit device पर हर request को log करता है:

bao audit enable file file_path=/var/log/openbao_audit.log

उस log के बारे में दो तथ्य यह बदलते हैं कि आप server को कैसे चलाते हैं। requests और responses में अधिकांश strings को HMAC-SHA256 और एक salt के साथ hash किया जाता है, इसलिए आप log में मौजूद plaintext के बिना भी किसी ज्ञात value का log से मिलान कर सकते हैं। Integers और booleans को clear text में लिखा जाता है, इसलिए numeric secret को उस hashing से कोई सुरक्षा नहीं मिलती।

इसके बाद operational trap यह है: जब कोई enabled audit device उन्हें record नहीं कर पाता, तो OpenBao requests का जवाब नहीं देगा, और यदि कोई device blocking तरीके से fail होता है, तो requests तब तक hang रहेंगी जब तक कोई उसे ठीक नहीं कर देता। /var/log पर disk का भर जाना आपके secrets API को design के अनुसार down कर देता है। audit log को पहले दिन ही अपनी अलग space दें और logrotate rule सेट करें, न कि पहली outage के बाद।

आपको कौन सा self-hosted secrets manager चलाना चाहिए?

मशीनों की संख्या और लोगों की संख्या गिनें, फिर चुनाव करें।

1. एक मशीन, एक व्यक्ति: root के स्वामित्व वाली और service user द्वारा पढ़ी जाने वाली mode 600 env file का उपयोग करें। जब आप process environment से value प्राप्त करना चाहते हैं, तो systemd credentials जोड़ें।
2. एक मशीन, दो से पांच लोग, configuration पहले से ही git में है: age के साथ SOPS का उपयोग करें। प्रत्येक व्यक्ति को एक key pair मिलता है, और .sops.yaml उन सभी public keys की सूची रखता है जिन्हें decrypt करने की अनुमति है।
3. कई मशीनें, एक configuration repository, ऐसे credentials की आवश्यकता नहीं जो expire होते हों: अभी भी age के साथ SOPS का उपयोग करें, जिसमें प्रति host एक recipient key हो, ताकि चोरी हुई host key केवल उसी host की files को decrypt कर सके।
4. कई मशीनें और कई टीमें जिन्हें वास्तव में lifetime वाले database credentials की आवश्यकता है, साथ ही एक audit trail जिसे कोई पढ़ता हो: OpenBao का उपयोग करें, और unsealing तथा restore drills के लिए operator के समय का प्रति माह एक घंटा बजट में रखें।

इन चारों के पीछे का नियम एक ही है। वह सबसे छोटा समाधान चलाएं जो आपकी उस आवश्यकता को पूरा करता हो जिसे आप स्पष्ट रूप से बता सकें, क्योंकि एक secrets manager जो down है, वह एक ऐसे secrets manager से अलग नहीं है जो खाली है।

FAQ

क्या एक सिंगल VPS के लिए self-hosted secrets manager का उपयोग करना सार्थक है?

आमतौर पर नहीं, यदि आपका मतलब OpenBao या Infisical जैसी सेवा से है। एक मशीन पर एक या दो उपयोगकर्ताओं के लिए, mode 600 वाली env file या systemd encrypted credential किसी अन्य स्थानीय उपयोगकर्ता के खिलाफ वही सुरक्षा प्रदान करते हैं। इसमें unseal करने का कोई चरण नहीं होता और न ही पैच करने के लिए कोई अतिरिक्त सेवा होती है। एक secrets service तब उपयोगी होती है जब आपके पास कई मशीनें और कई उपयोगकर्ता हों, या आपको ऐसे क्रेडेंशियल्स की आवश्यकता हो जो बिना किसी मानवीय हस्तक्षेप के एक्सपायर हो जाएं।

पासवर्ड मैनेजर और सीक्रेट्स मैनेजर में क्या अंतर है?

पासवर्ड मैनेजर उन क्रेडेंशियल्स को स्टोर करता है जिन्हें कोई व्यक्ति टाइप करता है, और जब वे मौजूद होते हैं तो वे इसे अनलॉक करते हैं। एक सीक्रेट्स मैनेजर प्रक्रियाओं (processes) को क्रेडेंशियल देता है, इसलिए इसे रात के 03:00 बजे भी काम करना होता है जब कोई उसे देख नहीं रहा होता। इसका परिणाम ही उन्हें अलग करता है: एक लॉक पासवर्ड मैनेजर आपसे मास्टर पासवर्ड दोबारा टाइप करने के लिए कहता है, और एक sealed सीक्रेट्स मैनेजर उन सभी सेवाओं को रोक देता है जो sealed अवस्था में restart होती हैं।

यदि reboot के बाद OpenBao sealed हो जाए तो मेरे ऐप्स का क्या होगा?

वे अपने सीक्रेट्स प्राप्त नहीं कर पाएंगे, इसलिए वे start होने में विफल हो जाएंगे, और systemd उन्हें तब तक लूप में restart करता रहेगा जब तक कोई unseal threshold प्रदान नहीं करता, जो डिफ़ॉल्ट रूप से 5 में से 3 shares है। OpenBao रूट की (root key) को केवल मेमोरी में रखता है, इसलिए हर restart इसे फिर से seal कर देता है। या तो auto unseal चालू करें, यह स्वीकार करते हुए कि एक सिंगल VPS पर unseal की (unseal key) उसी डिस्क पर समाप्त होती है जहाँ डेटा है, या deploy के समय सीक्रेट्स को एक फाइल में रेंडर करें ताकि बूटिंग कभी भी API पर निर्भर न रहे।

क्या मैं SOPS एन्क्रिप्टेड फाइलों को पब्लिक रिपॉजिटरी में कमिट कर सकता हूँ?

मान (values) एन्क्रिप्टेड होते हैं, इसलिए वे age private key के बिना किसी के लिए भी सुरक्षित हैं। कीज़ (keys) एन्क्रिप्टेड नहीं होती हैं: एक पाठक देख सकता है कि आपके पास STRIPE_SECRET_KEY और SMTP_PASSWORD हैं, और वे कितनी बार बदलते हैं। यह मेटाडेटा अधिकांश प्रोजेक्ट्स के लिए स्वीकार्य है और कुछ के लिए अस्वीकार्य। age private key को रिपॉजिटरी से बाहर रखें, और जब भी आप कोई recipient जोड़ें या हटाएं तो हर मौजूदा फाइल पर sops updatekeys चलाएं।