Ansible Vault का उपयोग करके Git में secrets कैसे encrypt

Ansible Vault क्या सुरक्षित करता है और क्या नहीं

Ansible Vault आपके playbook repository के अंदर secrets को encrypt करता है, इसलिए git में plaintext password के बजाय ciphertext स्टोर होता है। ansible-vault कमांड आपके द्वारा चुने गए password से उत्पन्न symmetric key का उपयोग करके या तो पूरी फ़ाइल को या फ़ाइल के अंदर एक एकल मान (value) को encrypt करती है। जब play चलता है, तो Ansible उस सामग्री को memory में decrypt कर देता है, इसलिए variable किसी अन्य variable की तरह ही व्यवहार करता है।

इस मॉडल की एक स्पष्ट सीमा है। Vault केवल repository में स्थिर (at rest) secret की सुरक्षा करता है और इसके अलावा कुछ नहीं। एक बार जब कोई task चलता है, तो वह मान memory में, rendered template में, module arguments में और run output में plaintext होता है, जब तक कि आप इसे रोक न दें। जो कोई भी playbook चला सकता है, उसके पास vault password होता है, इसलिए vault आपको टीम के बाहर के लोगों से गोपनीयता प्रदान करता है, न कि टीम के भीतर प्रति-व्यक्ति access control।

यदि आपने अभी तक playbook नहीं लिखा है, तो VPS के विरुद्ध पहला Ansible playbook से शुरुआत करें और जब उस playbook को password की आवश्यकता हो, तब वापस आएँ।

पूरी फाइल को एन्क्रिप्ट करें, या केवल एक स्ट्रिंग को?

ansible-vault encrypt एक फाइल को साइटेरटेक्स्ट (ciphertext) से बदल देता है। फाइल $ANSIBLE_VAULT से शुरू होने वाली हेडर लाइन के अंतर्गत base64 टेक्स्ट का एक ब्लॉक बन जाती है। इसका उपयोग तब करें जब फाइल में केवल सीक्रेट्स (secrets) हों।

ansible-vault encrypt_string एक वैल्यू को एन्क्रिप्ट करता है और एक YAML स्निपेट प्रिंट करता है जिसे आप सामान्य vars फाइल में पेस्ट कर सकते हैं। वेरिएबल का नाम पठनीय रहता है और केवल वैल्यू साइटेरटेक्स्ट होती है। इसका उपयोग तब करें जब सीक्रेट्स प्लेनटेक्स्ट सेटिंग्स के साथ मौजूद हों।

दैनिक कार्य में जो अंतर मायने रखता है, वह diff है। एक vault फाइल को हर बार सेव करने पर एक नए रैंडम साल्ट (salt) के साथ फिर से एन्क्रिप्ट किया जाता है, इसलिए साइटेरटेक्स्ट का हर बाइट बदल जाता है। git diff तब एक अपठनीय ब्लॉक को दूसरे अपठनीय ब्लॉक से बदला हुआ दिखाता है, जिसका अर्थ है कि एक समीक्षक यह नहीं बता सकता कि आपने एक पासवर्ड रोटेट किया है या पूरी फाइल को फिर से लिखा है। encrypt_string के साथ, प्रत्येक सीक्रेट एक प्लेनटेक्स्ट फाइल के अंदर अपना अलग ब्लॉक होता है, इसलिए diff यह स्पष्ट रूप से दिखाता है कि कौन सा वेरिएबल बदला है और बाकी फाइल को वैसा ही छोड़ देता है।

इनलाइन फॉर्म की एक कीमत है, और यह रोटेशन के समय सामने आती है: ansible-vault rekey इनलाइन ब्लॉक्स को नहीं छूता है। फाइल फॉर्म तब चुनें जब सीक्रेट लिस्ट लंबी हो और शायद ही कभी बदलती हो। इनलाइन फॉर्म तब चुनें जब फाइल में सीक्रेट्स और सामान्य वेरिएबल्स का मिश्रण हो और आप चाहते हों कि कोड रिव्यू का कोई अर्थ हो।

group_vars लेआउट जो दिखाता है कि क्या सुरक्षित है

Ansible group_vars/<group>.yml को लोड करता है, और यह group_vars/<group>/ डायरेक्टरी के अंदर की हर फाइल को भी लोड करता है। डायरेक्टरी वाला तरीका ही सबसे बेहतर है, क्योंकि यह एक ही ग्रुप को एक प्लेनटेक्स्ट फाइल और एक एन्क्रिप्टेड फाइल को साथ-साथ रखने की सुविधा देता है।

inventory/
  hosts.ini
group_vars/
  all/
    vars.yml
    vault.yml
  web/
    vars.yml
    vault.yml
host_vars/
  db01/
    vars.yml
    vault.yml
playbooks/
  site.yml

हर vault.yml एन्क्रिप्टेड है। हर vars.yml प्लेनटेक्स्ट है। कोई भी पाठक बिना कुछ खोले यह देख सकता है कि कौन से मान सुरक्षित हैं, क्योंकि फाइल का नाम ही यह बता देता है।

इस पैटर्न का दूसरा हिस्सा इनडायरेक्शन (indirection) है। एन्क्रिप्टेड फाइल के अंदर, हर वेरिएबल के आगे vault_ का उपसर्ग (prefix) लगाएँ।

vault_db_password: "a real password"
vault_grafana_admin_token: "a real token"

फिर उसके बगल वाली प्लेनटेक्स्ट फाइल से उन नामों का संदर्भ (reference) दें।

db_password: "{{ vault_db_password }}"
grafana_admin_token: "{{ vault_grafana_admin_token }}"

रोल्स और टेम्प्लेट db_password का उपयोग करते हैं और उन्हें कभी यह पता नहीं चलता कि मान कहाँ से आया है, जो प्लेबुक और रोल के बीच के विभाजन को साफ-सुथरा रखता है। प्लेनटेक्स्ट vars.yml एक खोजने योग्य इंडेक्स के रूप में भी काम करता है: grep -r vault_ group_vars/ उन सभी सीक्रेट्स की सूची देता है जिनकी रिपॉजिटरी को आवश्यकता है, बिना कुछ डिक्रिप्ट किए। इसकी कीमत प्रति सीक्रेट एक अतिरिक्त नाम है, और vault_ नाम में टाइपो होने पर वह रन टाइम पर सिंटैक्स एरर के बजाय एक अनडिफाइंड वेरिएबल के रूप में सामने आता है।

encrypt_string का उपयोग करके एक variable को encrypt करें

ansible-vault encrypt_string --vault-id prod@~/.ansible/vault-prod.txt \
  --stdin-name 'vault_db_password'

Secret टाइप करें, फिर Ctrl-D दबाएं। --stdin-name मान को standard input से पढ़ता है, जिससे यह आपकी shell history file में नहीं जाता है। दूसरा तरीका मान को command line पर रखता है, जहाँ shell इसे record कर लेती है:

ansible-vault encrypt_string --vault-id prod@~/.ansible/vault-prod.txt \
  'a real password' --name 'vault_db_password'

दोनों ही स्थितियों में command एक YAML block print करती है। इसे vars file में बिल्कुल वैसे ही paste करें जैसे यह print हुआ है, क्योंकि !vault tag के नीचे का indentation मान का ही हिस्सा होता है।

vault_db_password: !vault |
          $ANSIBLE_VAULT;1.2;AES256;prod
          6638643965323633646262656665306333616466396630323136393465356136396436383331
          3131303163306665326539353837343663313762616561306534373963383531613664393332

!vault tag YAML loader को बताता है कि scalar text के बजाय ciphertext है। Header में format version, cipher और वह vault ID label होता है जिसने इसे encrypt किया है। बिना vault ID के encrypt किया गया मान एक 1.1 header के साथ आता है जिसमें कोई label नहीं होता है। यह भी काम करता है, बस यह कम जानकारी देता है कि password कहाँ से आया था।

Vault password कहाँ रहता है?

रिपॉजिटरी के बाहर। यह एकमात्र नियम है जिसका कोई अपवाद नहीं है।

--ask-vault-pass हर रन पर एक बार प्रॉम्प्ट करता है और कुछ भी स्टोर नहीं करता है। यह लैपटॉप के लिए उपयुक्त है, और यह cron job या CI runner के लिए उपयुक्त नहीं है।

पासवर्ड फ़ाइल एक सादा टेक्स्ट फ़ाइल होती है जिसकी पहली पंक्ति में पासवर्ड होता है। इसे सख्त अनुमतियों (tight permissions) के साथ खाली बनाएँ, फिर इसे एडिटर में भरें, ताकि पासवर्ड कभी भी आपके शेल हिस्ट्री तक न पहुँचे:

mkdir -p ~/.ansible
install -m 600 /dev/null ~/.ansible/vault-prod.txt
$EDITOR ~/.ansible/vault-prod.txt

किसी भी कमांड को --vault-password-file के साथ इसकी ओर निर्देशित करें:

ansible-playbook -i inventory/hosts.ini playbooks/site.yml \
  --vault-password-file ~/.ansible/vault-prod.txt

हर कमांड पर उस फ्लैग को दोहराना भूलना आसान है, इसलिए इसे रिपॉजिटरी के रूट पर ansible.cfg में एक बार सेट करें।

[defaults]
inventory = inventory/hosts.ini
vault_password_file = ~/.ansible/vault-prod.txt

वही सेटिंग एनवायरनमेंट वेरिएबल ANSIBLE_VAULT_PASSWORD_FILE से पढ़ती है, जो कि वह तरीका है जिससे CI job सामान्यतः इसे प्रदान करती है। जॉब अपने क्रेडेंशियल स्टोर से पासवर्ड को एक अस्थायी निर्देशिका (temporary directory) में एक फ़ाइल में लिखती है, वेरिएबल को एक्सपोर्ट करती है, और रन समाप्त होने पर फ़ाइल को हटा देती है। फ़ाइल नाम पैटर्न को .gitignore में भी जोड़ें, क्योंकि ansible.cfg में पाथ कमिट किया गया है, और कभी न कभी कोई चेकआउट के अंदर वास्तविक फ़ाइल बना ही देगा।

यदि पासवर्ड फ़ाइल निष्पादन योग्य (executable) है, तो Ansible इसे चलाता है और फ़ाइल को टेक्स्ट के रूप में पढ़ने के बजाय उसके स्टैंडर्ड आउटपुट से पासवर्ड पढ़ता है। यही वह तरीका है जिससे आप डिस्क पर लिखे बिना सिस्टम कीरिंग या क्लाउड सीक्रेट मैनेजर से vault पासवर्ड प्राप्त करते हैं। --vault-id के माध्यम से उपयोग की जाने वाली स्क्रिप्ट की अतिरिक्त आवश्यकताएं होती हैं: इसका नाम -client या -client प्लस एक एक्सटेंशन पर समाप्त होना चाहिए, इसे निष्पादन योग्य होना चाहिए, इसे --vault-id विकल्प स्वीकार करना चाहिए, और इसे स्टैंडर्ड आउटपुट पर पासवर्ड प्रिंट करना चाहिए।

दो vault ID: staging और production

Vault ID एक लेबल है जो vault पासवर्ड के साथ जुड़ा होता है, जिसे label@source के रूप में लिखा जाता है। इसका स्रोत prompt है, जो एक पासवर्ड फ़ाइल का पाथ या क्लाइंट स्क्रिप्ट का पाथ होता है। लेबल की मदद से एक ही रिपॉजिटरी में कई पासवर्ड के तहत secrets रखे जा सकते हैं, ताकि staging पासवर्ड से production फ़ाइल न खुले।

ansible-vault encrypt --vault-id staging@~/.ansible/vault-staging.txt \
  group_vars/staging/vault.yml
ansible-vault encrypt --vault-id prod@~/.ansible/vault-prod.txt \
  group_vars/prod/vault.yml

एक रन के लिए आवश्यक प्रत्येक ID को पास करें:

ansible-playbook playbooks/site.yml \
  --vault-id staging@~/.ansible/vault-staging.txt \
  --vault-id prod@~/.ansible/vault-prod.txt

या उन्हें ansible.cfg में एक बार सूचीबद्ध करें:

[defaults]
vault_identity_list = staging@~/.ansible/vault-staging.txt, prod@~/.ansible/vault-prod.txt

एक व्यवहार लोगों को हैरान करता है। डिफ़ॉल्ट रूप से, लेबल केवल एक संकेत है, लॉक नहीं। Ansible फ़ाइल के विरुद्ध अपने पास मौजूद प्रत्येक secret को तब तक आज़माता है जब तक कि उनमें से कोई एक उसे डिक्रिप्ट न कर दे, इसलिए यदि production पासवर्ड सही कुंजी है, तो staging लेबल वाली फ़ाइल भी खुल जाएगी। [defaults] के अंतर्गत vault_id_match = True सेट करें, या पर्यावरण चर ANSIBLE_VAULT_ID_MATCH का उपयोग करें, और Ansible केवल उसी secret का उपयोग करेगा जिसका लेबल फ़ाइल हेडर से मेल खाता है। उस जाँच के लिए 1.2 हेडर की आवश्यकता होती है, इसलिए यह केवल उसी सामग्री पर लागू होता है जिसे पहली बार में vault ID के साथ एन्क्रिप्ट किया गया था।

एक से अधिक ID लोड होने पर, ansible-vault encrypt को यह पता नहीं होता कि किस पासवर्ड से एन्क्रिप्ट करना है। इसे --encrypt-vault-id prod के साथ नाम दें, या ansible.cfg में vault_encrypt_identity सेट करें ताकि रिपॉजिटरी का एक डिफ़ॉल्ट हो।

इसका लाभ deployment का दायरा है। staging को deploy करने वाली CI जॉब को केवल staging पासवर्ड दिया जाता है, इसलिए एक compromised runner production क्रेडेंशियल्स को नहीं पढ़ सकता। एक बार जब आप एक कंट्रोल मशीन से Linux सर्वरों के बेड़े पर plays चला रहे होते हैं, तो यह अलगाव एक छोटी घटना और बहुत बड़ी घटना के बीच का अंतर होता है।

जब कोई टीम छोड़कर जाए तो vault को rekey करें

Rekeying से vault का password बदल जाता है और content नए password के तहत फिर से encrypt हो जाता है। यह किसी भी पुरानी प्रक्रिया को undo नहीं करता है। जिस किसी के पास भी पुराना password था, वह अभी भी repository की अपनी रखी हुई copy को decrypt कर सकता है, जिसमें उस copy का हर पुराना commit भी शामिल है। इसलिए, जिस क्षण कोई व्यक्ति टीम छोड़ता है, vault password को असुरक्षित मान लें और इस क्रम में rotation करें:

1. Servers और third-party services पर वास्तविक credentials बदलें। यही वह चरण है जो वास्तव में access को revoke करता है।
2. ansible-vault edit का उपयोग करके नए values को vault files में डालें।
3. हर encrypted file को एक नए vault password पर rekey करें।
4. नए vault password को उन लोगों तक पहुँचाएँ जिन्हें इसकी आवश्यकता है, और यह काम repository से अलग किसी अन्य channel के माध्यम से करें।

ansible-vault rekey --vault-id prod@~/.ansible/vault-prod-old.txt \
  --new-vault-id prod@prompt \
  group_vars/prod/vault.yml host_vars/db01/vault.yml

rekey एक ही command में कई files को स्वीकार करता है, और --new-vault-id prod@prompt disk से password पढ़ने के बजाय एक बार नया password पूछता है। जब तक आपके पास इसे बदलने का कोई ठोस कारण न हो, label को समान रखें, क्योंकि command द्वारा rewrite की जाने वाली हर file के header में वही label लिखा जाता है।

यहीं पर inline form की लागत सामने आती है। ansible-vault rekey पूरी तरह से encrypted files पर काम करता है, इसलिए plaintext vars file के अंदर मौजूद !vault block को यह नहीं छूता है। पहले उन्हें ढूँढें, फिर नए password के तहत encrypt_string का उपयोग करके प्रत्येक को regenerate करें:

grep -rl '!vault' group_vars/ host_vars/

यही पूरा trade-off है। Inline blocks आपको readable diffs देते हैं और rotation के समय एक manual pass की लागत लेते हैं। पूरी तरह से encrypted files एक command के साथ rotate हो जाती हैं और review के दौरान आपको कोई उपयोगी जानकारी नहीं देती हैं।

आउटपुट में secret अभी भी क्यों दिखाई देता है

जब value को decrypt कर लिया जाता है, तो Vault का काम पूरा हो जाता है। Ansible किसी task का परिणाम रिपोर्ट करता है, और जो module अपने arguments को echo करता है, वह उस credential को रिपोर्ट में ले आता है। एक verbose run, template task पर --diff, arguments को dump करने वाला कोई failed task, या आउटपुट को फाइल में लिखने वाला callback plugin, इन सभी में plaintext मौजूद रहता है। फाइल को encrypt करने से इनमें से किसी पर भी कोई असर नहीं पड़ता।

no_log: true वह switch है जिसका उपयोग करना चाहिए। इसे किसी भी ऐसे task पर set करें जो credential प्राप्त करता है।

- name: Write the application environment file
  ansible.builtin.template:
    src: app.env.j2
    dest: /etc/myapp/app.env
    owner: myapp
    group: myapp
    mode: "0600"
  no_log: true

इसके बाद Ansible उस task के परिणाम को आउटपुट से छिपा लेता है, जिससे log में यह तो दर्ज होता है कि task चला था, लेकिन यह दर्ज नहीं होता कि उसने क्या handle किया। इसे विशेष रूप से loops पर set करें, क्योंकि एक loop हर item के लिए एक परिणाम रिपोर्ट करता है, और credential list पर चलने वाला loop पूरी list को ही रिपोर्ट कर देता है।

चार अन्य स्थान जहाँ से decrypted secret लीक हो सकता है, जिन्हें no_log कवर नहीं करता:

• Template से render की गई फाइल उन mode और owner को inherit कर लेती है जो आपने उसे दिए हैं। credential रखने वाली किसी भी चीज़ पर mode: "0600" और एक विशिष्ट owner set करें, अन्यथा secret target host पर सभी के लिए readable हो जाएगा।
• ansible.builtin.command या ansible.builtin.shell को पास किया गया secret, command चलते समय target host की process list में दिखाई देता है, जहाँ कोई भी local user उसे पढ़ सकता है। इसके बजाय इसे फाइल या environment variable के माध्यम से पास करें।
• Fact caching, एकत्रित किए गए facts को control machine की disk पर लिखती है, इसलिए secret रखने वाला registered variable ऐसी cache फाइल में जा सकता है जिसे कोई संवेदनशील नहीं मानता।
• वही secret आमतौर पर दूसरी जगह भी मौजूद रहता है, जैसे कि container द्वारा पढ़ी जाने वाली environment फाइल में। वहाँ के नियम अलग हैं, और Compose env फाइलों से credentials को बाहर रखना इस पहलू को कवर करता है।

no_log debugging को कठिन बना देता है, और इसका उद्देश्य यही है। जब कोई task ठीक से काम न करे, तो test host पर इसे अस्थायी रूप से हटा दें, और बदलाव को production में भेजने से पहले इसे वापस लगा दें।

Plaintext छोड़े बिना encrypted files को पढ़ें और edit करें

ansible-vault view group_vars/prod/vault.yml फाइल को decrypt करके pager में खोलता है और डिस्क पर कुछ भी नहीं लिखता है। ansible-vault edit फाइल को एक temporary file में decrypt करता है, आपके $EDITOR को खोलता है, और बंद करने पर उसे फिर से encrypt कर देता है। इन दोनों को ansible-vault decrypt से बेहतर मानें, क्योंकि वह working tree में plaintext फाइल छोड़ देता है। गलती से stage की गई decrypted vault फाइल ही वह सबसे आम तरीका है जिससे असली credentials public repository तक पहुँच जाते हैं।

Git पूरी तरह से encrypted फाइलों के लिए एक readable diff दिखा सकता है, इसके लिए वह उन्हें प्रोसेस करते समय decrypt करता है:

git config --local diff.ansible-vault.textconv "ansible-vault view --vault-password-file ~/.ansible/vault-prod.txt"
printf '%s\n' 'group_vars/**/vault.yml diff=ansible-vault' >> .gitattributes

इसे enable करने से पहले समझ लें कि यह क्या करता है। git diff अब आपके terminal में production secrets प्रिंट करेगा, जो आपके scrollback और किसी भी screen share में दिखाई दे सकते हैं। यह एक मशीन पर एक व्यक्ति के लिए स्थानीय सुविधा है, इसलिए git config को local ही रखें। यह मानकर चलें कि अन्य लोगों के checkouts अलग तरह से व्यवहार करेंगे, जब तक कि वे खुद इसे set न कर लें।

जब Vault सही टूल न रहे

Vault एक फाइल फॉर्मेट है जिसमें प्रत्येक लेबल के लिए एक पासवर्ड होता है, और यही संरचना तय करती है कि यह कब अपर्याप्त हो जाता है। जब निम्नलिखित में से कोई भी स्थिति हो, तो एक वास्तविक secret store पर स्विच करें।

• आपको प्रति-व्यक्ति एक्सेस की आवश्यकता है। playbook चलाने वाले हर व्यक्ति के पास एक ही पासवर्ड होता है, और vault IDs एक्सेस को environment के आधार पर विभाजित करते हैं, न कि व्यक्ति के आधार पर।
• आपको audit trail की आवश्यकता है। Vault इस बारे में कुछ भी रिकॉर्ड नहीं करता कि किसने क्या डिक्रिप्ट किया, या कब किया।
• आपको निर्धारित समय पर rotation की आवश्यकता है। Vault में कोई expiry या versioning नहीं है, इसलिए कोई भी आपको यह नहीं बताता कि credential दो साल से बदला नहीं गया है।
• एप्लिकेशन को खुद runtime पर secret की आवश्यकता है। बूट होते समय अपना डेटाबेस पासवर्ड पढ़ने वाली सर्विस को इसे आपके deployment repository से नहीं पढ़ना चाहिए।

तब यह पैटर्न उलट जाता है। Ansible secrets को स्टोर करना बंद कर देता है और उन्हें runtime पर एक lookup plugin के माध्यम से प्राप्त करना शुरू करता है। यह HashiCorp Vault (एक अलग प्रोडक्ट जिसका नाम भ्रमित करने वाला है), किसी क्लाउड प्रदाता के secret manager, या कंट्रोल मशीन पर मौजूद keyring के विरुद्ध होता है। Repository में एक पाथ होता है, स्टोर में वैल्यू होती है, और स्टोर एक्सेस लॉग रखता है। एक छोटी टीम के लिए, API वाला एक self-hosted पासवर्ड मैनेजर, जैसे कि एक Vaultwarden सर्वर, छोटे स्तर पर वही काम करता है।

एक credential इन सबसे बाहर रहता है। सर्वर तक पहुँचने के लिए आपकी कंट्रोल मशीन जिस SSH key का उपयोग करती है, वह vault की समस्या नहीं है, क्योंकि किसी भी play के चलने से पहले Ansible को इसकी आवश्यकता होती है। इसे एक agent और passphrase के साथ संभालें, जैसा कि SSH key प्रबंधन के मूल सिद्धांतों में बताया गया है।

FAQ

क्या मुझे पूरी vars फाइल को encrypt करना चाहिए या केवल secret स्ट्रिंग को?

जब फाइल में केवल secrets हों, तो पूरी फाइल को encrypt करें, क्योंकि एक ही कमांड से सब कुछ rotate हो जाता है और लेआउट सरल रहता है। जब secrets साधारण variables के साथ हों, तो ansible-vault encrypt_string का उपयोग करें, क्योंकि तब diff में केवल encrypted मान बदलता है और reviewer देख सकता है कि किस variable में बदलाव किया गया है। इसका नुकसान rotation में होता है। ansible-vault rekey पूरी फाइलों को कवर करता है और इनलाइन !vault ब्लॉक्स को नहीं छूता है, इसलिए उन्हें नए पासवर्ड के तहत मैन्युअल रूप से फिर से generate करना पड़ता है।

Ansible Vault पासवर्ड फाइल को कहाँ स्टोर करना चाहिए?

इसे रिपॉजिटरी के बाहर, 0600 मोड के साथ, ~/.ansible/vault-prod.txt जैसे पाथ पर रखें। इसे --vault-password-file के साथ पॉइंट करें, या ansible.cfg में [defaults] के तहत vault_password_file सेट करें, या एनवायरनमेंट में ANSIBLE_VAULT_PASSWORD_FILE सेट करें। CI में, जॉब को अपने क्रेडेंशियल स्टोर से पासवर्ड एक अस्थायी फाइल में लिखने दें, वेरिएबल को एक्सपोर्ट करें, और जॉब समाप्त होने पर फाइल को डिलीट कर दें। यदि फाइल executable है, तो Ansible इसे चलाता है और standard output से पासवर्ड पढ़ता है, जिससे आप इसे डिस्क पर स्टोर करने के बजाय सीधे keyring से प्राप्त कर सकते हैं।

मैं staging और production के लिए अलग-अलग vault पासवर्ड का उपयोग कैसे करूँ?

प्रत्येक पासवर्ड को --vault-id staging@/path/to/file और --vault-id prod@/path/to/file के साथ एक लेबल दें, और प्रत्येक एनवायरनमेंट की फाइलों को उसके अपने लेबल के तहत encrypt करें। रन टाइम पर दोनों IDs पास करें, या उन्हें [defaults] के तहत vault_identity_list में सूचीबद्ध करें। डिफ़ॉल्ट रूप से Ansible अपने पास मौजूद हर secret को तब तक आज़माता है जब तक कि कोई फाइल को decrypt न कर दे, इसलिए यदि आप चाहते हैं कि यह केवल उसी secret को आज़माए जिसका लेबल फाइल हेडर से मेल खाता है, तो vault_id_match = True सेट करें। कई IDs लोड होने पर, --encrypt-vault-id के साथ encrypt करने वाली ID चुनें।

क्या Ansible Vault रन आउटपुट में पासवर्ड दिखने से रोकता है?

नहीं। Vault केवल रिपॉजिटरी में 'at rest' (स्टोर किए गए) secrets की सुरक्षा करता है। एक बार जब कोई टास्क चलता है, तो मान plaintext होता है, और verbose रन या विफल टास्क इसे लॉग में ले जा सकते हैं। क्रेडेंशियल संभालने वाले प्रत्येक टास्क में no_log: true जोड़ें, टेम्पलेट की गई किसी भी फाइल पर प्रतिबंधात्मक mode और owner सेट करें, और secrets को कमांड आर्ग्युमेंट्स के रूप में पास करने से बचें, क्योंकि कमांड चलते समय वे टारगेट होस्ट पर प्रोसेस लिस्ट में दिखाई देते हैं।