Ansible Vault میں Git secrets encrypt کرنے کا طریقہ

Ansible Vault کیا محفوظ کرتا ہے، اور کیا محفوظ نہیں کرتا

Ansible Vault آپ کی playbook repository میں موجود secrets کو encrypt کرتا ہے، اس لیے git میں plaintext password کے بجائے ciphertext محفوظ ہوتا ہے۔ ansible-vault command پوری file یا file کے اندر کسی ایک value کو encrypt کرتا ہے۔ اس کے لیے آپ کے منتخب کردہ password سے اخذ کی گئی symmetric key استعمال ہوتی ہے۔ play کے چلنے پر Ansible اس content کو memory میں decrypt کرتا ہے، اس لیے variable کسی بھی دوسرے variable کی طرح کام کرتا ہے۔

اس model کی ایک واضح حد ہے۔ Vault کسی secret کو repository میں at rest حالت میں محفوظ کرتا ہے، اس سے زیادہ نہیں۔ Task چلنے کے بعد value memory، rendered template، module arguments اور run output میں plaintext کے طور پر موجود ہوتی ہے، جب تک آپ اسے ظاہر ہونے سے نہ روکیں۔ جو بھی شخص playbook چلا سکتا ہے، اس کے پاس vault password ہوتا ہے۔ اس لیے vault ٹیم سے باہر کے لوگوں سے secrecy فراہم کرتا ہے، لیکن ٹیم کے اندر ہر شخص کے لیے الگ access control نہیں دیتا۔

اگر آپ نے ابھی playbook نہیں لکھی تو VPS کے خلاف پہلی Ansible playbook سے شروع کریں، اور جب اس playbook کو password درکار ہو تو یہاں واپس آئیں۔

ایک پوری فائل encrypt کریں یا صرف ایک string؟

ansible-vault encrypt فائل کو ciphertext سے replace کرتا ہے۔ header line کے نیچے فائل base64 text کے ایک block میں تبدیل ہو جاتی ہے، اور یہ header line $ANSIBLE_VAULT سے شروع ہوتی ہے۔ اسے اس وقت استعمال کریں جب فائل میں صرف secrets ہوں۔

ansible-vault encrypt_string ایک value کو encrypt کرتا ہے اور YAML snippet دکھاتا ہے، جسے آپ عام vars file میں paste کر سکتے ہیں۔ variable name قابلِ مطالعہ رہتا ہے اور صرف value ciphertext ہوتی ہے۔ اسے اس وقت استعمال کریں جب secrets، plaintext settings کے ساتھ موجود ہوں۔

روزمرہ کام میں اہم فرق diff کا ہے۔ vault file کو ہر بار save کرنے پر نئے random salt کے ساتھ دوبارہ encrypt کیا جاتا ہے، اس لیے ciphertext کا ہر byte تبدیل ہو جاتا ہے۔ اس کے بعد git diff ایک unreadable block کو دوسرے unreadable block سے replace ہوا دکھاتا ہے۔ اس کا مطلب ہے کہ reviewer یہ معلوم نہیں کر سکتا کہ آپ نے ایک password rotate کیا ہے یا پوری file دوبارہ لکھی ہے۔ encrypt_string کے ساتھ ہر secret plaintext file کے اندر اپنے الگ block میں ہوتا ہے۔ اس لیے diff بالکل دکھاتا ہے کہ کون سا variable تبدیل ہوا، جبکہ باقی file جوں کی توں رہتی ہے۔

inline form کی ایک قیمت ہے، اور وہ rotation کے وقت سامنے آتی ہے: ansible-vault rekey inline blocks کو تبدیل نہیں کرتا۔ جب secret list طویل ہو اور کم تبدیل ہوتی ہو تو file form منتخب کریں۔ جب file میں secrets کے ساتھ معمول کے variables بھی ہوں اور آپ چاہتے ہوں کہ code review بامعنی رہے، تو inline form منتخب کریں۔

group_vars کی ساخت سے معلوم ہوتا ہے کہ کیا محفوظ ہے

Ansible group_vars/<group>.yml لوڈ کرتا ہے، اور group_vars/<group>/ ڈائریکٹری کے اندر موجود ہر فائل بھی لوڈ کرتا ہے۔ ڈائریکٹری والی ساخت ہی استعمال کریں، کیونکہ اس سے ایک ہی group میں plaintext فائل اور encrypted فائل ساتھ رکھی جا سکتی ہیں۔

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 encrypted ہوتی ہے۔ ہر vars.yml plaintext ہوتی ہے۔ فائل کھولے بغیر معلوم ہو جاتا ہے کہ کون سی values محفوظ ہیں، کیونکہ filename یہ بات واضح کرتا ہے۔

اس pattern کا دوسرا حصہ indirection ہے۔ encrypted فائل کے اندر ہر variable کے آگے vault_ لگائیں۔

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

پھر plaintext فائل میں موجود ان ناموں کو reference کریں۔

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

Roles اور templates db_password استعمال کرتے ہیں اور انہیں کبھی معلوم نہیں ہوتا کہ value کہاں سے آئی ہے۔ اس سے playbook اور role کے درمیان تقسیم واضح رہتی ہے۔ plaintext vars.yml searchable index کے طور پر بھی کام کرتی ہے: grep -r vault_ group_vars/ repository کو درکار ہر secret کی فہرست دیتا ہے، بغیر کسی چیز کو decrypt کیے۔ اس کی قیمت ہر secret کے لیے ایک اضافی نام ہے، اور vault_ کے نام میں typo ہونے پر syntax error کے بجائے runtime پر undefined variable ظاہر ہوتا ہے۔

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 value کو standard input سے پڑھتا ہے، جس کی وجہ سے وہ آپ کی shell history file میں شامل نہیں ہوتی۔ دوسری صورت value کو command line پر رکھتی ہے، جہاں shell اسے ریکارڈ کر لیتا ہے:

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

دونوں صورتوں میں command ایک YAML block دکھاتا ہے۔ اسے vars file میں بالکل اسی طرح paste کریں جیسے دکھایا گیا ہے، کیونکہ !vault tag کے نیچے indentation بھی value کا حصہ ہے۔

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

!vault tag YAML loader کو بتاتا ہے کہ scalar، text کے بجائے ciphertext ہے۔ Header میں format version، cipher، اور اسے encrypt کرنے والا vault ID label شامل ہوتا ہے۔ vault ID کے بغیر encrypted کی گئی value میں بغیر label کے 1.1 header ہوتا ہے۔ یہ پھر بھی کام کرتا ہے، لیکن آپ کو password کے ماخذ کے بارے میں کم معلومات دیتا ہے۔

Vault کا password کہاں محفوظ ہوتا ہے؟

Repository سے باہر۔ یہی ایک اصول ہے جس کی کوئی استثنا نہیں۔

--ask-vault-pass ہر run میں ایک بار prompt کرتا ہے اور کچھ بھی محفوظ نہیں کرتا۔ یہ laptop کے لیے موزوں ہے، لیکن cron job یا CI runner کے لیے موزوں نہیں۔

Password file ایک plain text file ہوتی ہے جس کی پہلی لائن password ہوتی ہے۔ اسے سخت permissions کے ساتھ خالی بنائیں، پھر editor میں password درج کریں، تاکہ password آپ کی shell history میں شامل نہ ہو:

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

--vault-password-file کے ذریعے کسی بھی command کو اس file کی طرف متوجہ کریں:

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

ہر command میں یہ flag دہرانا آسانی سے بھولا جا سکتا ہے، اس لیے اسے repository کے root میں موجود ansible.cfg میں ایک بار set کریں۔

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

یہی setting environment variable ANSIBLE_VAULT_PASSWORD_FILE سے بھی value لیتی ہے، اور CI job عموماً اسی طرح اسے فراہم کرتی ہے۔ Job اپنی credential store سے password لے کر temporary directory میں موجود file میں لکھتی ہے، variable export کرتی ہے، اور run ختم ہونے پر file delete کر دیتی ہے۔ Filename pattern کو .gitignore میں بھی شامل کریں، کیونکہ ansible.cfg میں موجود path commit ہو چکا ہے، اور بالآخر کوئی نہ کوئی checkout کے اندر اصل file بنا دے گا۔

اگر password file executable ہو تو Ansible اسے run کرتا ہے اور file کو text کے طور پر پڑھنے کے بجائے اس کے standard output سے password حاصل کرتا ہے۔ اسی طریقے سے vault password کو system keyring یا cloud secret manager سے حاصل کیا جا سکتا ہے، بغیر اسے disk پر لکھے۔ --vault-id کے ذریعے استعمال ہونے والی script کے لیے اضافی تقاضے ہیں: اس کا نام -client پر یا -client کے ساتھ کسی extension پر ختم ہونا چاہیے، یہ executable ہونی چاہیے، اسے --vault-id option قبول کرنا چاہیے، اور اسے password standard output پر print کرنا چاہیے۔

دو vault IDs: staging اور production

vault ID وہ label ہے جو vault password کے ساتھ منسلک ہوتا ہے اور اسے label@source کے طور پر لکھا جاتا ہے۔ source prompt، password file کا path، یا client script کا path ہوتا ہے۔ Labels کی مدد سے ایک ہی repository میں ایک سے زیادہ passwords کے تحت secrets رکھے جا سکتے ہیں، اس لیے staging password سے production file نہیں کھلتی۔

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 فراہم کریں جس کی run کو ضرورت ہو:

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

ایک رویہ صارفین کو حیران کرتا ہے۔ بطور default، label lock نہیں بلکہ صرف hint ہوتا ہے۔ Ansible اس وقت اپنے پاس موجود ہر secret کو file کے خلاف آزماتا ہے، جب تک ان میں سے کوئی اسے decrypt نہ کر دے۔ اس لیے staging سے label کی گئی file بھی کھل جاتی ہے، اگر production password اتفاقاً درست key ہو۔ [defaults] کے تحت vault_id_match = True، یا environment variable ANSIBLE_VAULT_ID_MATCH، set کریں۔ اس کے بعد Ansible صرف اسی secret کو استعمال کرتا ہے جس کا label file header سے مطابقت رکھتا ہو۔ اس جانچ کے لیے 1.2 header ضروری ہے، اس لیے یہ صرف اس content پر لاگو ہوتی ہے جسے ابتدا ہی میں vault ID کے ساتھ encrypt کیا گیا ہو۔

ایک سے زیادہ IDs loaded ہونے پر ansible-vault encrypt کو معلوم نہیں رہتا کہ encryption کے لیے کون سا password استعمال کرنا ہے۔ اسے --encrypt-vault-id prod کے ساتھ نام دیں، یا ansible.cfg میں vault_encrypt_identity set کریں تاکہ repository کے لیے default موجود ہو۔

اس کا فائدہ deployment scope میں ہے۔ staging deploy کرنے والی CI job کو صرف staging password دیا جاتا ہے، اس لیے compromised runner production credentials نہیں پڑھ سکتا۔ جب آپ ایک ہی control machine سے Linux servers کے پورے fleet پر plays چلا رہے ہوں، تو یہ علیحدگی ایک چھوٹے incident اور بہت بڑے incident کے درمیان فرق بن جاتی ہے۔

جب کوئی شخص ٹیم چھوڑ دے تو vault کی encryption key دوبارہ بنائیں

Rekey کرنے سے vault کا password تبدیل ہو جاتا ہے اور content کو نئے password کے تحت دوبارہ encrypt کیا جاتا ہے۔ اس سے پہلے کی کوئی کارروائی واپس نہیں ہوتی۔ جس شخص کے پاس کبھی پرانا password رہا ہو، وہ اپنے پاس موجود repository کی کسی بھی copy کو اب بھی decrypt کر سکتا ہے، جس میں اس copy کے تمام پرانے commits بھی شامل ہیں۔ اس لیے password رکھنے والا شخص جاتے ہی vault password کو compromised سمجھیں، اور rotation اس ترتیب سے کریں۔

1. Servers اور third-party services میں اصل credentials تبدیل کریں۔ رسائی واقعی اسی مرحلے میں منسوخ ہوتی ہے۔
2. نئے values کو ansible-vault edit کے ذریعے 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 password کو disk سے پڑھنے کے بجائے ایک بار طلب کرتا ہے۔ وہی label برقرار رکھیں، جب تک اسے تبدیل کرنے کی کوئی خاص وجہ نہ ہو، کیونکہ command سے rewrite ہونے والی ہر file کے header میں label لکھا جاتا ہے۔

یہاں inline form کی لاگت سامنے آتی ہے۔ ansible-vault rekey مکمل طور پر encrypted files پر کام کرتا ہے، اس لیے plaintext vars file کے اندر موجود !vault block تبدیل نہیں ہوتا۔ پہلے انہیں تلاش کریں، پھر نئے password کے تحت encrypt_string سے ہر block دوبارہ بنائیں:

grep -rl '!vault' group_vars/ host_vars/

مکمل trade-off یہی ہے۔ Inline blocks readable diffs فراہم کرتے ہیں، لیکن rotation کے وقت آپ کو دستی مرحلہ کرنا پڑتا ہے۔ مکمل طور پر encrypted files ایک command سے rotate ہو جاتی ہیں، لیکن review کے لیے کوئی مفید معلومات فراہم نہیں کرتیں۔

آپ کے output میں secret اب بھی کیوں ظاہر ہوتا ہے

Vault اسی وقت اپنا کام مکمل کر لیتا ہے جب value decrypt ہو جاتی ہے۔ Ansible task کا result report کرتا ہے، اور جو module اپنے arguments echo کرتا ہے وہ credential کو اسی report میں شامل کر دیتا ہے۔ verbose run، template task پر --diff، اپنے arguments dump کرنے والا failed task، یا output کو file میں لکھنے والا callback plugin، ہر ایک plaintext محفوظ کر سکتا ہے۔ File کو encrypt کرنے سے ان میں سے کسی مسئلے پر اثر نہیں پڑا۔

no_log: true یہ control ہے۔ اسے ہر اس 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 کا result output میں شامل نہیں کرتا۔ اس طرح log صرف یہ record کرتا ہے کہ task چلا تھا، لیکن یہ record نہیں کرتا کہ task نے کیا process کیا۔ اسے خاص طور پر loops پر set کریں، کیونکہ loop ہر item کے لیے الگ result report کرتا ہے، اور credential list پر چلنے والا loop پوری list report کر دیتا ہے۔

چار دوسری جگہیں بھی ہیں جہاں decrypted secret باہر آ سکتا ہے، اور no_log ان میں سے کسی کو cover نہیں کرتا:

• Template سے render ہونے والی file کو وہ mode اور owner وراثت میں ملتے ہیں جو آپ نے اسے دیے ہیں۔ Credential رکھنے والی ہر چیز کے لیے mode: "0600" اور مخصوص owner set کریں، ورنہ secret target host پر تمام users کے لیے readable ہو جائے گا۔
• ansible.builtin.command یا ansible.builtin.shell کو دیا گیا secret command کے چلنے کے دوران target host کی process list میں ظاہر ہوتا ہے، جہاں کوئی بھی local user اسے پڑھ سکتا ہے۔ اس کے بجائے secret کو file یا environment variable کے ذریعے pass کریں۔
• Fact caching gathered facts کو control machine کی disk پر لکھتی ہے۔ اس لیے secret رکھنے والا registered variable ایسی cache file میں محفوظ ہو سکتا ہے جسے کوئی sensitive نہیں سمجھتا۔
• عموماً یہی secret دوسری جگہ بھی موجود ہوتا ہے، مثلاً container کی جانب سے پڑھی جانے والی environment file میں۔ وہاں کے rules الگ ہیں، اور Compose env files سے credentials باہر رکھنا اس پہلو کا احاطہ کرتا ہے۔

no_log debugging کو مشکل بناتا ہے، اور یہی اس کا مقصد ہے۔ جب کوئی task test host پر غلط برتاؤ کرے تو اسے عارضی طور پر ہٹا دیں، اور change کے production تک پہنچنے سے پہلے اسے دوبارہ شامل کر دیں۔

خفیہ کردہ فائلیں پڑھیں اور ترمیم کریں، plaintext پیچھے چھوڑے بغیر

ansible-vault view group_vars/prod/vault.yml فائل کو pager میں decrypt کرتا ہے اور disk پر کچھ نہیں لکھتا۔ ansible-vault edit فائل کو temporary file میں decrypt کرتا ہے، آپ کی $EDITOR کھولتا ہے، اور اسے بند کرنے پر دوبارہ encrypt کر دیتا ہے۔ دونوں کو ansible-vault decrypt پر ترجیح دیں، کیونکہ ansible-vault decrypt plaintext فائل کو working tree میں موجود چھوڑ دیتا ہے۔ غلطی سے decrypted vault file کو stage کر دینا وہ عام ترین طریقہ ہے جس سے حقیقی credential public repository تک پہنچتا ہے۔

Git مکمل طور پر encrypted فائلوں کے لیے readable diff دکھا سکتا ہے، کیونکہ یہ 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 اب production secrets کو آپ کے terminal میں print کرے گا، جس سے وہ scrollback اور ہر screen share میں ظاہر ہوں گے۔ یہ ایک مشین پر ایک شخص کے لیے local سہولت ہے، اس لیے git config کو local رکھیں۔ توقع رکھیں کہ دوسرے لوگوں کے checkouts مختلف طریقے سے کام کریں گے، جب تک وہ بھی یہی configuration نہ کریں۔

جب Vault درست tool نہ رہے

Vault ایک file format ہے جس میں ہر label کے لیے ایک password ہوتا ہے، اور یہی ساخت اس کی حد مقرر کرتی ہے۔ جب درج ذیل میں سے کوئی بات درست ہو تو کسی حقیقی secret store پر منتقل ہو جائیں۔

• آپ کو ہر شخص کے لیے الگ access درکار ہو۔ playbook چلانے والے تمام افراد کے پاس ایک ہی password ہوتا ہے، اور vault IDs صرف environment کے لحاظ سے access تقسیم کرتے ہیں، افراد کے لحاظ سے نہیں۔
• آپ کو audit trail درکار ہو۔ Vault یہ ریکارڈ نہیں کرتا کہ کس نے کیا decrypt کیا یا کب کیا۔
• آپ کو مقررہ schedule کے مطابق rotation درکار ہو۔ Vault میں expiry اور versioning نہیں ہوتی، اس لیے یہ معلوم کرنے کا کوئی طریقہ نہیں ہوتا کہ کوئی credential دو سال سے تبدیل نہیں ہوا۔
• application کو خود runtime پر secret درکار ہو۔ boot کے وقت database password پڑھنے والی service کو یہ password آپ کے deployment repository سے نہیں پڑھنا چاہیے۔

اس کے بعد pattern الٹ جاتا ہے۔ Ansible secrets محفوظ کرنا بند کرتا ہے اور lookup plugin کے ذریعے runtime پر انہیں fetch کرنا شروع کرتا ہے۔ اس مقصد کے لیے HashiCorp Vault استعمال کیا جا سکتا ہے، جو ملتے جلتے نام کا ایک مختلف product ہے، یا کسی cloud provider کا secret manager، یا control machine پر موجود keyring۔ repository میں path ہوتا ہے، store میں value ہوتی ہے، اور store access log محفوظ کرتا ہے۔ چھوٹی team کے لیے API رکھنے والا self-hosted password manager، جیسے Vaultwarden server، کم پیمانے پر یہی کام انجام دیتا ہے۔

ایک credential اس پورے نظام سے باہر رہتا ہے۔ control machine سرورز تک پہنچنے کے لیے جو SSH key استعمال کرتی ہے، وہ vault کا مسئلہ نہیں ہے، کیونکہ کوئی بھی play چلنے سے پہلے Ansible کو اس key کی ضرورت ہوتی ہے۔ اسے agent اور passphrase کے ذریعے manage کریں، جیسا کہ SSH key management کی بنیادی باتوں میں بیان کیا گیا ہے۔

FAQ

کیا مجھے پوری vars فائل encrypt کرنی چاہیے یا صرف secret string؟

جب فائل میں صرف secrets ہوں تو پوری فائل encrypt کریں، کیونکہ ایک command پوری فائل کو rotate کر دیتا ہے اور layout سادہ رہتا ہے۔ جب secrets عام variables کے ساتھ موجود ہوں تو ansible-vault encrypt_string استعمال کریں، کیونکہ diff میں صرف encrypted value تبدیل ہوتی ہے اور reviewer دیکھ سکتا ہے کہ کون سا variable تبدیل ہوا ہے۔ اس کا trade-off rotation ہے۔ ansible-vault rekey پوری files کو cover کرتا ہے اور inline !vault blocks کو تبدیل نہیں کرتا، اس لیے نئے password کے تحت انہیں ہاتھ سے دوبارہ generate کرنا ہوگا۔

Ansible Vault password file کہاں store کرنی چاہیے؟

اسے repository کے باہر 0600 mode کے ساتھ، مثلاً ~/.ansible/vault-prod.txt جیسے path پر store کریں۔ --vault-password-file کے ذریعے اس کی طرف اشارہ کریں، یا ansible.cfg میں [defaults] کے تحت vault_password_file set کریں، یا environment میں ANSIBLE_VAULT_PASSWORD_FILE set کریں۔ CI میں job سے کہیں کہ وہ اپنے credential store سے password لے کر temporary file میں لکھے، variable export کرے، اور job ختم ہونے پر file delete کر دے۔ اگر file executable ہو تو Ansible اسے run کرتا ہے اور standard output سے password پڑھتا ہے۔ اس طرح password کو disk پر store کرنے کے بجائے keyring سے حاصل کیا جا سکتا ہے۔

staging اور production کے لیے مختلف vault passwords کیسے استعمال کروں؟

--vault-id staging@/path/to/file اور --vault-id prod@/path/to/file کے ذریعے ہر password کو ایک label دیں، اور ہر environment کی files کو اپنے label کے تحت encrypt کریں۔ دونوں IDs run time پر pass کریں، یا انہیں [defaults] کے تحت vault_identity_list میں درج کریں۔ By default Ansible ہر دستیاب secret کو آزما کر دیکھتا ہے کہ کون سا file کو decrypt کرتا ہے۔ اگر آپ چاہتے ہیں کہ یہ صرف اسی secret کو آزمائے جس کا label file header سے match کرتا ہو تو vault_id_match = True set کریں۔ متعدد IDs load ہونے پر encrypt کرنے والا ID --encrypt-vault-id کے ذریعے منتخب کریں۔

کیا Ansible Vault password کو run output میں ظاہر ہونے سے روکتا ہے؟

نہیں۔ Vault repository میں secret کو صرف at rest حالت میں protect کرتا ہے۔ Task چلنے کے بعد value plaintext ہوتی ہے، اور verbose run یا failed task اسے log میں شامل کر سکتا ہے۔ ہر اس task میں جو credential handle کرے no_log: true شامل کریں، template سے بننے والی ہر file پر محدود permissions کے لیے mode اور owner set کریں، اور secrets کو command arguments کے طور پر pass کرنے سے گریز کریں، کیونکہ command چلنے کے دوران target host کی process list میں یہ arguments نظر آتے ہیں۔