Ansible Vault ఉపయోగించి Git లో రహస్యాలను ఎలా దాచాలి?

Ansible Vault దేనిని రక్షిస్తుంది, దేనిని రక్షించదు

Ansible Vault మీ playbook repository లోని రహస్యాలను (secrets) encrypt చేస్తుంది, కాబట్టి git లో plaintext పాస్‌వర్డ్‌లకు బదులుగా ciphertext నిల్వ చేయబడుతుంది. ansible-vault కమాండ్ మీరు ఎంచుకున్న పాస్‌వర్డ్ నుండి పొందిన symmetric key ని ఉపయోగించి, ఒక పూర్తి ఫైల్‌ను లేదా ఫైల్‌లోని ఒకే ఒక విలువను encrypt చేస్తుంది. play రన్ అయినప్పుడు Ansible ఆ కంటెంట్‌ను మెమరీలో decrypt చేస్తుంది, కాబట్టి ఆ variable ఇతర variable ల మాదిరిగానే పనిచేస్తుంది.

ఈ మోడల్‌కు ఒక స్పష్టమైన పరిమితి ఉంది. Vault ఒక రహస్యాన్ని repository లో నిల్వ ఉన్నప్పుడు (at rest) మాత్రమే రక్షిస్తుంది, అంతకు మించి ఏమీ చేయదు. ఒక task రన్ అయిన తర్వాత, ఆ విలువ మెమరీలో, రూపొందించబడిన template లో, module arguments లో మరియు మీరు ఆపకపోతే run output లో కూడా plaintext గానే ఉంటుంది. playbook ని రన్ చేయగల ప్రతి ఒక్కరికీ vault పాస్‌వర్డ్ తెలుస్తుంది, కాబట్టి vault మీకు టీమ్ వెలుపల ఉన్న వ్యక్తుల నుండి గోప్యతను ఇస్తుంది, టీమ్ లోపల వ్యక్తిగత ప్రాతిపదికన access control ని ఇవ్వదు.

మీరు ఇంకా playbook రాయకపోతే, VPS పై మొదటి Ansible playbook తో ప్రారంభించండి మరియు ఆ playbook కి పాస్‌వర్డ్ అవసరమైనప్పుడు తిరిగి రండి.

మొత్తం ఫైల్‌ను ఎన్‌క్రిప్ట్ చేయాలా, లేదా ఒకే స్ట్రింగ్‌నా?

ansible-vault encrypt ఒక ఫైల్‌ను సైఫర్‌టెక్స్ట్‌తో భర్తీ చేస్తుంది. ఆ ఫైల్ $ANSIBLE_VAULT తో మొదలయ్యే హెడర్ లైన్ కింద base64 టెక్స్ట్ యొక్క ఒకే బ్లాక్‌గా మారుతుంది. ఫైల్‌లో రహస్యాలు (secrets) తప్ప మరేమీ లేనప్పుడు దీనిని ఉపయోగించండి.

ansible-vault encrypt_string ఒక విలువను ఎన్‌క్రిప్ట్ చేసి, మీరు సాధారణ vars ఫైల్‌లో పేస్ట్ చేయగల YAML స్నిప్పెట్‌ను ప్రింట్ చేస్తుంది. వేరియబుల్ పేరు చదవగలిగేలా ఉంటుంది మరియు విలువ మాత్రమే సైఫర్‌టెక్స్ట్‌గా ఉంటుంది. రహస్యాలు ప్లెయిన్‌టెక్స్ట్ సెట్టింగ్‌లతో కలిసి ఉన్నప్పుడు దీనిని ఉపయోగించండి.

రోజువారీ పనిలో ముఖ్యమైన వ్యత్యాసం 'diff' లో ఉంటుంది. మీరు vault ఫైల్‌ను సేవ్ చేసిన ప్రతిసారీ అది కొత్త రాండమ్ సాల్ట్‌తో మళ్ళీ ఎన్‌క్రిప్ట్ అవుతుంది, కాబట్టి సైఫర్‌టెక్స్ట్‌లోని ప్రతి బైట్ మారుతుంది. అప్పుడు git diff ఒక చదవలేని బ్లాక్ మరొక చదవలేని బ్లాక్‌తో భర్తీ చేయబడినట్లు చూపిస్తుంది; దీనివల్ల మీరు ఒక పాస్‌వర్డ్‌ను మార్చారా లేదా మొత్తం ఫైల్‌ను తిరగరాశారా అనేది రివ్యూ చేసేవారికి అర్థం కాదు. encrypt_string తో, ప్రతి రహస్యం ప్లెయిన్‌టెక్స్ట్ ఫైల్‌లో దాని స్వంత బ్లాక్‌గా ఉంటుంది, కాబట్టి ఏ వేరియబుల్ మారిందో diff ఖచ్చితంగా చూపిస్తుంది మరియు ఫైల్‌లోని మిగిలిన భాగాన్ని అలాగే ఉంచుతుంది.

ఇన్‌లైన్ ఫార్మాట్‌కు ఒక పరిమితి ఉంది, అది రహస్యాలను మార్చే (rotation) సమయంలో తెలుస్తుంది: 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_ అనే ప్రిఫిక్స్‌ను జోడించండి.

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

ఆ తర్వాత, పక్కనే ఉన్న ప్లెయిన్‌టెక్స్ట్ ఫైల్ నుండి ఆ పేర్లను రిఫరెన్స్ చేయండి.

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

Roles మరియు templates అన్నీ db_password నే ఉపయోగిస్తాయి, ఆ విలువ ఎక్కడి నుండి వచ్చిందో వాటికి తెలియదు. దీనివల్ల playbook మరియు role మధ్య విభజన స్పష్టంగా ఉంటుంది. ప్లెయిన్‌టెక్స్ట్ vars.yml ఒక సెర్చ్ చేయదగిన ఇండెక్స్‌గా కూడా పనిచేస్తుంది: రిపోజిటరీకి ఏయే రహస్యాలు (secrets) అవసరమో grep -r vault_ group_vars/ ద్వారా దేనినీ డిక్రిప్ట్ చేయకుండానే తెలుసుకోవచ్చు. దీనివల్ల ప్రతి రహస్యానికి ఒక అదనపు పేరును కేటాయించాల్సి ఉంటుంది, అలాగే vault_ పేరులో ఏదైనా తప్పు దొర్లితే, అది సింటాక్స్ ఎర్రర్‌గా కాకుండా రన్ టైమ్‌లో undefined variable ఎర్రర్‌గా కనిపిస్తుంది.

encrypt_string ఉపయోగించి ఒక వేరియబుల్‌ను ఎన్‌క్రిప్ట్ చేయడం

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

రహస్య విలువను టైప్ చేసి, ఆపై Ctrl-D నొక్కండి. --stdin-name స్టాండర్డ్ ఇన్‌పుట్ నుండి విలువను చదువుతుంది, దీనివల్ల అది మీ షెల్ హిస్టరీ ఫైల్‌లో సేవ్ అవ్వదు. మరొక పద్ధతిలో విలువను కమాండ్ లైన్‌లోనే ఇస్తారు, కానీ అప్పుడు షెల్ దానిని రికార్డ్ చేస్తుంది:

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

ఏ పద్ధతిలోనైనా కమాండ్ ఒక YAML బ్లాక్‌ను ప్రింట్ చేస్తుంది. దానిని vars ఫైల్‌లో ఉన్నది ఉన్నట్లుగా పేస్ట్ చేయండి, ఎందుకంటే !vault ట్యాగ్ కింద ఉండే ఇండెంటేషన్ (indentation) ఆ విలువలో ఒక భాగం.

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

!vault ట్యాగ్, ఆ స్కేలార్ (scalar) సాధారణ టెక్స్ట్ కాదని, సైఫర్‌టెక్స్ట్ (ciphertext) అని YAML లోడర్‌కు తెలియజేస్తుంది. ఈ హెడర్‌లో ఫార్మాట్ వెర్షన్, సైఫర్ మరియు దానిని ఎన్‌క్రిప్ట్ చేసిన vault ID లేబుల్ ఉంటాయి. vault ID లేకుండా ఎన్‌క్రిప్ట్ చేసిన విలువకు 1.1 హెడర్ ఉంటుంది, ఇందులో లేబుల్ ఉండదు. ఇది కూడా పనిచేస్తుంది, కానీ ఆ పాస్‌వర్డ్ దేనికి సంబంధించినదో తెలుసుకోవడం కొంచెం కష్టమవుతుంది.

Vault పాస్‌వర్డ్ ఎక్కడ ఉంటుంది?

రిపోజిటరీకి వెలుపల. ఇది ఎటువంటి మినహాయింపులు లేని ఏకైక నియమం.

--ask-vault-pass ప్రతి రన్‌కు ఒకసారి అడుగుతుంది మరియు దేనినీ నిల్వ చేయదు. ఇది ల్యాప్‌టాప్‌లకు సరిపోతుంది, కానీ cron job లేదా CI runner కు సరిపోదు.

పాస్‌వర్డ్ ఫైల్ అనేది మొదటి లైన్‌లో పాస్‌వర్డ్ ఉండే ఒక plain text ఫైల్. దీన్ని కఠినమైన అనుమతులతో (permissions) ఖాళీగా సృష్టించి, ఆపై ఎడిటర్‌లో నింపండి, తద్వారా పాస్‌వర్డ్ మీ shell history లోకి ఎప్పటికీ చేరదు:

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 అనే environment variable నుండి చదువుతుంది, CI job సాధారణంగా దీని ద్వారానే పాస్‌వర్డ్‌ను అందిస్తుంది. ఆ job తన సొంత credential store నుండి పాస్‌వర్డ్‌ను ఒక తాత్కాలిక డైరెక్టరీలోని ఫైల్‌లోకి రాసి, ఆ variable ను export చేసి, రన్ ముగిసిన తర్వాత ఫైల్‌ను తొలగిస్తుంది. ఫైల్‌నేమ్ ప్యాటర్న్‌ను .gitignore లో కూడా చేర్చండి, ఎందుకంటే ansible.cfg లోని పాత్ కమిట్ చేయబడుతుంది, కాబట్టి ఎప్పటికైనా ఎవరో ఒకరు checkout లోపల అసలైన ఫైల్‌ను సృష్టించే అవకాశం ఉంది.

పాస్‌వర్డ్ ఫైల్ executable అయితే, Ansible దాన్ని రన్ చేసి, ఫైల్‌ను టెక్స్ట్‌గా చదవడానికి బదులుగా దాని standard output నుండి పాస్‌వర్డ్‌ను చదువుతుంది. డిస్క్‌పై ఎక్కడా రాయకుండానే system keyring లేదా cloud secret manager నుండి vault పాస్‌వర్డ్‌ను పొందడానికి ఇది మార్గం. --vault-id ద్వారా ఉపయోగించే స్క్రిప్ట్‌కు అదనపు అవసరాలు ఉన్నాయి: దాని పేరు -client తో లేదా -client మరియు ఒక extension తో ముగియాలి, అది executable అయి ఉండాలి, అది --vault-id ఆప్షన్‌ను అంగీకరించాలి మరియు అది పాస్‌వర్డ్‌ను standard output లో ప్రింట్ చేయాలి.

రెండు 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

ఒక రన్ (run) కు అవసరమైన ప్రతి 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 తన వద్ద ఉన్న ప్రతి రహస్యాన్ని ఫైల్‌పై ప్రయత్నిస్తుంది, ఏదో ఒకటి ఫైల్‌ను డీక్రిప్ట్ చేసే వరకు ఇది కొనసాగుతుంది. కాబట్టి, ఒకవేళ production పాస్‌వర్డ్ సరైన కీ అయితే, staging అని లేబుల్ చేసిన ఫైల్ కూడా ఓపెన్ అవుతుంది. [defaults] కింద vault_id_match = True ని సెట్ చేయండి, లేదా ANSIBLE_VAULT_ID_MATCH ఎన్విరాన్‌మెంట్ వేరియబుల్‌ను ఉపయోగించండి; అప్పుడు Ansible ఫైల్ హెడర్‌తో సరిపోలే లేబుల్ ఉన్న రహస్యాన్ని మాత్రమే ఉపయోగిస్తుంది. ఆ తనిఖీకి 1.2 హెడర్ అవసరం, కాబట్టి ఇది మొదట vault IDతో ఎన్‌క్రిప్ట్ చేయబడిన కంటెంట్‌కు మాత్రమే వర్తిస్తుంది.

ఒకటి కంటే ఎక్కువ IDలు లోడ్ అయినప్పుడు, ansible-vault encrypt ఏ పాస్‌వర్డ్‌తో ఎన్‌క్రిప్ట్ చేయాలో గుర్తించలేదు. --encrypt-vault-id prod తో దానిని పేర్కొనండి, లేదా రిపోజిటరీకి డిఫాల్ట్ ఉండేలా ansible.cfg లో vault_encrypt_identity ని సెట్ చేయండి.

దీని వల్ల కలిగే ప్రయోజనం deployment పరిధి. Staging ను డిప్లాయ్ చేసే CI జాబ్‌కు staging పాస్‌వర్డ్ మాత్రమే ఇవ్వబడుతుంది, కాబట్టి ఒకవేళ రన్నర్ compromised అయినా అది production క్రెడెన్షియల్స్‌ను చదవలేదు. మీరు ఒక కంట్రోల్ మెషీన్ నుండి అనేక Linux సర్వర్ల పై ప్లేలను రన్ చేస్తున్నప్పుడు, ఈ విభజన ఒక చిన్న సంఘటనకు మరియు చాలా పెద్ద ప్రమాదానికి మధ్య ఉన్న వ్యత్యాసాన్ని సూచిస్తుంది.

ఎవరైనా సంస్థను వదిలి వెళ్ళినప్పుడు vault ను rekey చేయడం

Rekeying ప్రక్రియ vault పాస్‌వర్డ్‌ను మారుస్తుంది మరియు కంటెంట్‌ను కొత్త పాస్‌వర్డ్ కింద తిరిగి ఎన్‌క్రిప్ట్ చేస్తుంది. ఇది గతంలో జరిగిన దేనినీ రద్దు చేయదు. పాత పాస్‌వర్డ్ తెలిసిన ఎవరైనా, తమ వద్ద ఉన్న repository కాపీని, అందులోని ప్రతి పాత commit ను ఇప్పటికీ decrypt చేయగలరు. కాబట్టి, ఒక వ్యక్తి సంస్థను వదిలి వెళ్ళిన క్షణమే ఆ vault పాస్‌వర్డ్ పనికిరాదని భావించాలి మరియు ఈ క్రింది క్రమంలో మార్పులు చేయాలి.

1. సర్వర్లలో మరియు థర్డ్-పార్టీ సేవలలో ఉన్న అసలు credentials ను మార్చండి. ఈ దశ మాత్రమే వాస్తవంగా యాక్సెస్‌ను రద్దు చేస్తుంది.
2. ansible-vault edit ఉపయోగించి కొత్త విలువలను vault ఫైళ్ళలో ఉంచండి.
3. ఎన్‌క్రిప్ట్ చేయబడిన ప్రతి ఫైల్‌ను కొత్త vault పాస్‌వర్డ్‌కు rekey చేయండి.
4. కొత్త vault పాస్‌వర్డ్‌ను, repository కాకుండా వేరే సురక్షిత ఛానల్ ద్వారా అవసరమైన వ్యక్తులకు అందించండి.

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 ఒకే కమాండ్‌లో అనేక ఫైళ్ళను స్వీకరిస్తుంది, మరియు --new-vault-id prod@prompt డిస్క్ నుండి చదవడానికి బదులుగా కొత్త పాస్‌వర్డ్‌ను ఒకేసారి అడుగుతుంది. లేబుల్‌ను మార్చడానికి బలమైన కారణం లేకపోతే, పాత లేబుల్‌నే ఉంచండి, ఎందుకంటే కమాండ్ తిరిగి రాసే ప్రతి ఫైల్ హెడర్‌లో ఆ లేబుల్ ఉంటుంది.

ఇక్కడే inline ఫారమ్ వాడటం వల్ల అదనపు పని ఉంటుంది. ansible-vault rekey పూర్తిగా ఎన్‌క్రిప్ట్ చేయబడిన ఫైళ్ళపై పనిచేస్తుంది, కాబట్టి plaintext vars ఫైల్‌లో ఉన్న !vault బ్లాక్ అలాగే ఉండిపోతుంది. ముందుగా వాటిని గుర్తించి, ఆపై కొత్త పాస్‌వర్డ్ కింద encrypt_string ఉపయోగించి ప్రతి ఒక్కదానిని తిరిగి రూపొందించండి:

grep -rl '!vault' group_vars/ host_vars/

ఇది మొత్తం ప్రక్రియలోని లాభనష్టాలు. Inline బ్లాక్‌లు మీకు చదవగలిగే diffs ను ఇస్తాయి, కానీ rotation సమయంలో మీరు మాన్యువల్‌గా పని చేయాల్సి ఉంటుంది. పూర్తిగా ఎన్‌క్రిప్ట్ చేయబడిన ఫైళ్ళు ఒకే కమాండ్‌తో rotate అవుతాయి, కానీ review చేసేటప్పుడు వాటిలో ఏమీ కనిపించదు.

మీ అవుట్‌పుట్‌లో రహస్య సమాచారం ఎందుకు కనిపిస్తుంది

Vault విలువను డీక్రిప్ట్ చేసిన వెంటనే దాని పని పూర్తవుతుంది. Ansible ఒక టాస్క్ ఫలితాన్ని నివేదిస్తుంది, మరియు దాని ఆర్గ్యుమెంట్లను ప్రతిబింబించే (echo) మాడ్యూల్ ఆ క్రెడెన్షియల్‌ను ఆ నివేదికలోకి తీసుకువెళుతుంది. verbose రన్, టెంప్లేట్ టాస్క్‌పై --diff, ఆర్గ్యుమెంట్లను డంప్ చేసే విఫలమైన టాస్క్, లేదా అవుట్‌పుట్‌ను ఫైల్‌లోకి రాసే కాల్‌బ్యాక్ ప్లగిన్ - వీటిలో ప్రతి ఒక్కటి ప్లెయిన్‌టెక్స్ట్‌ను కలిగి ఉంటాయి. ఫైల్‌ను ఎన్‌క్రిప్ట్ చేయడం వల్ల వీటిలో దేనికీ ఎటువంటి ప్రయోజనం ఉండదు.

no_log: true అనేది దీనికి పరిష్కారం. క్రెడెన్షియల్‌ను స్వీకరించే ఏదైనా టాస్క్‌పై దీన్ని సెట్ చేయండి.

- 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 ఆ టాస్క్ ఫలితాన్ని అవుట్‌పుట్ నుండి నిలిపివేస్తుంది, కాబట్టి ఆ టాస్క్ దేనిని హ్యాండిల్ చేసిందో నమోదు చేయకుండానే, అది రన్ అయినట్లుగా లాగ్ రికార్డ్ చేస్తుంది. ముఖ్యంగా లూప్‌లపై దీన్ని సెట్ చేయండి, ఎందుకంటే లూప్ ప్రతి ఐటెమ్‌కు ఒక ఫలితాన్ని నివేదిస్తుంది, మరియు క్రెడెన్షియల్ జాబితాపై లూప్ మొత్తం జాబితాను నివేదిస్తుంది.

డీక్రిప్ట్ చేసిన రహస్య సమాచారం బయటపడే మరో నాలుగు మార్గాలు ఉన్నాయి, వీటిని no_log కవర్ చేయదు:

• టెంప్లేట్ నుండి రెండర్ చేయబడిన ఫైల్, మీరు దానికి ఇచ్చిన mode మరియు owner లను పొందుతుంది. రహస్య సమాచారం ఉన్న దేనికైనా mode: "0600" మరియు నిర్దిష్టమైన ఓనర్‌ను సెట్ చేయండి, లేకపోతే ఆ రహస్యం టార్గెట్ హోస్ట్‌లో అందరికీ చదవగలిగేలా (world readable) మారుతుంది.
• ansible.builtin.command లేదా ansible.builtin.shell కి పంపిన రహస్య సమాచారం, కమాండ్ రన్ అవుతున్నప్పుడు టార్గెట్ హోస్ట్‌లోని ప్రాసెస్ లిస్ట్‌లో కనిపిస్తుంది, అక్కడ ఏ లోకల్ యూజర్ అయినా దాన్ని చదవగలరు. దానికి బదులుగా ఫైల్ లేదా ఎన్విరాన్‌మెంట్ వేరియబుల్ ద్వారా పంపండి.
• ఫ్యాక్ట్ క్యాచింగ్ (Fact caching) సేకరించిన ఫ్యాక్ట్‌లను కంట్రోల్ మెషీన్‌లోని డిస్క్‌పై రాస్తుంది, కాబట్టి రహస్య సమాచారాన్ని కలిగి ఉన్న రిజిస్టర్డ్ వేరియబుల్ ఎవరూ ఊహించని విధంగా సెన్సిటివ్ క్యాచీ ఫైల్‌లో ఉండవచ్చు.
• అదే రహస్య సమాచారం సాధారణంగా రెండవ చోట కూడా ఉంటుంది, ఉదాహరణకు కంటైనర్ చదివే ఎన్విరాన్‌మెంట్ ఫైల్. అక్కడ నియమాలు వేరుగా ఉంటాయి, మరియు Compose env ఫైళ్లలో క్రెడెన్షియల్స్ లేకుండా చేయడం అనే విభాగం ఆ అంశాన్ని కవర్ చేస్తుంది.

no_log డీబగ్గింగ్‌ను కష్టతరం చేస్తుంది, ఇది సరిగ్గా దాని కోసమే ఉద్దేశించబడింది. ఒక టాస్క్ సరిగ్గా పనిచేయనప్పుడు టెస్ట్ హోస్ట్‌పై దీన్ని తాత్కాలికంగా తొలగించండి, మరియు మార్పు ప్రొడక్షన్‌కు వెళ్లే ముందు తిరిగి సెట్ చేయండి.

Plaintext ఫైళ్లను వదలకుండా ఎన్‌క్రిప్ట్ చేసిన ఫైళ్లను చదవడం మరియు సవరించడం

ansible-vault view group_vars/prod/vault.yml ఫైల్‌ను డీక్రిప్ట్ చేసి నేరుగా పేజర్‌లోకి పంపుతుంది, డిస్క్‌పై ఎటువంటి సమాచారాన్ని రాయదు. ansible-vault edit ఫైల్‌ను తాత్కాలిక ఫైల్‌లోకి డీక్రిప్ట్ చేసి, మీ $EDITORని ఓపెన్ చేస్తుంది, మీరు దాన్ని క్లోజ్ చేసినప్పుడు తిరిగి ఎన్‌క్రిప్ట్ చేస్తుంది. ఈ రెండింటినీ ansible-vault decrypt కంటే ఎక్కువగా ప్రాధాన్యత ఇవ్వండి, ఎందుకంటే ఇది వర్కింగ్ ట్రీలో ప్లెయిన్‌టెక్స్ట్ ఫైల్‌ను అలాగే ఉంచుతుంది. పొరపాటున స్టేజ్ చేయబడిన డీక్రిప్ట్ చేసిన వాల్ట్ ఫైల్ ద్వారానే అసలైన క్రెడెన్షియల్స్ పబ్లిక్ రిపోజిటరీలోకి చేరే అవకాశం ఎక్కువగా ఉంటుంది.

Git పూర్తిగా ఎన్‌క్రిప్ట్ చేసిన ఫైళ్లను డీక్రిప్ట్ చేస్తూ, వాటికి చదవగలిగే diffని చూపగలదు:

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

దీనిని ఎనేబుల్ చేసే ముందు అది ఏమి చేస్తుందో అర్థం చేసుకోండి. git diff ఇప్పుడు ప్రొడక్షన్ సీక్రెట్స్‌ను మీ టెర్మినల్‌లో ప్రింట్ చేస్తుంది, దీనివల్ల అవి మీ స్క్రోల్‌బ్యాక్‌లో మరియు స్క్రీన్ షేరింగ్‌లో కనిపిస్తాయి. ఇది ఒకే మెషీన్‌పై ఒక వ్యక్తి కోసం మాత్రమే ఉద్దేశించిన స్థానిక సౌకర్యం, కాబట్టి git configని లోకల్‌గా ఉంచండి. ఇతర వ్యక్తులు ఇదే సెటప్‌ను కాన్ఫిగర్ చేయకపోతే, వారి చెకౌట్‌లు భిన్నంగా ప్రవర్తిస్తాయని గుర్తుంచుకోండి.

Vault సరైన సాధనం కానప్పుడు

Vault అనేది ప్రతి లేబుల్‌కు ఒక పాస్‌వర్డ్‌ను కలిగి ఉండే ఫైల్ ఫార్మాట్, ఈ నిర్మాణం అది ఎక్కడ విఫలమవుతుందో నిర్ణయిస్తుంది. ఈ క్రింది వాటిలో ఏది నిజమైనా, మీరు ఒక నిజమైన secret store కు మారాలి.

• మీకు వ్యక్తిగత ప్రాతిపదికన యాక్సెస్ అవసరం. ప్లేబుక్‌ను రన్ చేసే ప్రతి ఒక్కరికీ ఒకే పాస్‌వర్డ్ ఉంటుంది, మరియు Vault IDలు యాక్సెస్‌ను ఎన్విరాన్‌మెంట్ ఆధారంగా విభజిస్తాయి తప్ప, వ్యక్తి ఆధారంగా కాదు.
• మీకు ఆడిట్ ట్రైల్ అవసరం. ఎవరు దేనిని డీక్రిప్ట్ చేశారో లేదా ఎప్పుడు చేశారో Vault ఏమీ రికార్డ్ చేయదు.
• మీకు షెడ్యూల్ ప్రకారం రొటేషన్ అవసరం. Vault లో ఎక్స్‌పైరీ లేదా వెర్షనింగ్ ఉండదు, కాబట్టి రెండు సంవత్సరాలుగా క్రెడెన్షియల్ మారలేదని మీకు ఏదీ తెలియజేయదు.
• అప్లికేషన్‌కు రన్ టైమ్‌లో సీక్రెట్ అవసరం. ఒక సర్వీస్ తన డేటాబేస్ పాస్‌వర్డ్‌ను బూట్ సమయంలో చదువుతుంటే, అది మీ డిప్లాయ్‌మెంట్ రిపోజిటరీ నుండి చదవకూడదు.

అప్పుడు ఈ పద్ధతి మారుతుంది. Ansible సీక్రెట్స్‌ను స్టోర్ చేయడం ఆపివేసి, రన్ టైమ్‌లో lookup plugin ద్వారా వాటిని సేకరించడం ప్రారంభిస్తుంది. ఇది HashiCorp Vault (గందరగోళంగా ఇలాంటి పేరున్న మరొక ప్రొడక్ట్), క్లౌడ్ ప్రొవైడర్ యొక్క secret manager, లేదా కంట్రోల్ మెషీన్‌లోని keyring ద్వారా జరుగుతుంది. రిపోజిటరీ ఒక పాత్‌ను కలిగి ఉంటుంది, స్టోర్ విలువను కలిగి ఉంటుంది, మరియు స్టోర్ యాక్సెస్ లాగ్‌ను నిర్వహిస్తుంది. చిన్న టీమ్ కోసం, API కలిగిన self-hosted పాస్‌వర్డ్ మేనేజర్, ఉదాహరణకు Vaultwarden సర్వర్, అదే పనిని తక్కువ పరిధిలో పూర్తి చేస్తుంది.

ఒక క్రెడెన్షియల్ మాత్రం వీటన్నింటికీ వెలుపల ఉంటుంది. సర్వర్లను చేరుకోవడానికి మీ కంట్రోల్ మెషీన్ ఉపయోగించే SSH key అనేది Vault సమస్య కాదు, ఎందుకంటే ఏదైనా ప్లే రన్ కావడానికి ముందే Ansible కు అది అవసరం. దీనిని ఒక ఏజెంట్ మరియు పాస్‌ఫ్రేజ్‌తో నిర్వహించండి, దీనికి సంబంధించి SSH key నిర్వహణ ప్రాథమికాంశాలు చూడండి.

FAQ

నేను మొత్తం vars ఫైల్‌ను ఎన్‌క్రిప్ట్ చేయాలా లేదా కేవలం secret స్ట్రింగ్‌ను మాత్రమేనా?

vars ఫైల్‌లో కేవలం secrets మాత్రమే ఉన్నప్పుడు మొత్తం ఫైల్‌ను ఎన్‌క్రిప్ట్ చేయండి, ఎందుకంటే ఒకే కమాండ్‌తో అన్నింటినీ మార్చవచ్చు (rotate) మరియు ఫైల్ నిర్మాణం సరళంగా ఉంటుంది. సాధారణ వేరియబుల్స్‌తో పాటు secrets ఉన్నప్పుడు ansible-vault encrypt_string ఉపయోగించండి, దీనివల్ల diff లో కేవలం ఎన్‌క్రిప్ట్ చేసిన విలువ మాత్రమే మారుతుంది మరియు ఏ వేరియబుల్ మారిందో రివ్యూయర్ సులభంగా గుర్తించగలరు. అయితే, ఇందులో rotation కష్టమవుతుంది. ansible-vault rekey మొత్తం ఫైళ్లను కవర్ చేస్తుంది, కానీ inline !vault బ్లాక్‌లను వదిలేస్తుంది, కాబట్టి కొత్త పాస్‌వర్డ్ కింద వాటిని మాన్యువల్‌గా మళ్లీ జనరేట్ చేయాల్సి ఉంటుంది.

Ansible Vault పాస్‌వర్డ్ ఫైల్‌ను ఎక్కడ భద్రపరచాలి?

దీనిని రిపోజిటరీకి వెలుపల, 0600 మోడ్‌తో, ~/.ansible/vault-prod.txt వంటి పాత్‌లో ఉంచాలి. దీనిని --vault-password-file ద్వారా సూచించండి, లేదా ansible.cfg లోని [defaults] కింద vault_password_file ని సెట్ చేయండి, లేదా ఎన్విరాన్‌మెంట్‌లో ANSIBLE_VAULT_PASSWORD_FILE ని సెట్ చేయండి. CI లో, జాబ్ తన సొంత క్రెడెన్షియల్ స్టోర్ నుండి పాస్‌వర్డ్‌ను ఒక తాత్కాలిక ఫైల్‌లోకి రాసి, వేరియబుల్‌ను ఎగుమతి చేసి, జాబ్ ముగిశాక ఆ ఫైల్‌ను తొలగించేలా చేయాలి. ఫైల్ ఎగ్జిక్యూటబుల్ అయితే, Ansible దానిని రన్ చేసి standard output నుండి పాస్‌వర్డ్‌ను చదువుతుంది, దీనివల్ల మీరు డిస్క్‌లో స్టోర్ చేయకుండా keyring నుండి పాస్‌వర్డ్‌ను పొందవచ్చు.

స్టేజింగ్ మరియు ప్రొడక్షన్ కోసం వేర్వేరు vault పాస్‌వర్డ్‌లను ఎలా ఉపయోగించాలి?

ప్రతి పాస్‌వర్డ్‌కు --vault-id staging@/path/to/file మరియు --vault-id prod@/path/to/file తో ఒక లేబుల్‌ను కేటాయించి, ఆయా ఎన్విరాన్‌మెంట్ ఫైళ్లను వాటి లేబుల్ కింద ఎన్‌క్రిప్ట్ చేయండి. రన్ టైమ్‌లో రెండు IDలను పంపండి, లేదా [defaults] కింద vault_identity_list లో వాటిని పేర్కొనండి. డిఫాల్ట్‌గా Ansible తన వద్ద ఉన్న ప్రతి సీక్రెట్‌ను ఫైల్ డిక్రిప్ట్ అయ్యే వరకు ప్రయత్నిస్తుంది, కాబట్టి ఫైల్ హెడర్‌తో సరిపోయే లేబుల్ ఉన్న సీక్రెట్‌ను మాత్రమే ప్రయత్నించాలంటే vault_id_match = True ని సెట్ చేయండి. ఒకటి కంటే ఎక్కువ IDలు లోడ్ అయినప్పుడు, ఎన్‌క్రిప్ట్ చేయడానికి --encrypt-vault-id తో ఒకదానిని ఎంచుకోండి.

Ansible Vault పాస్‌వర్డ్ రన్ అవుట్‌పుట్‌లో కనిపించకుండా ఆపుతుందా?

లేదు. Vault రిపోజిటరీలో ఉన్నప్పుడు మాత్రమే సీక్రెట్‌ను రక్షిస్తుంది. ఒక టాస్క్ రన్ అయినప్పుడు, ఆ విలువ ప్లెయిన్ టెక్స్ట్‌గా మారుతుంది, కాబట్టి verbose రన్ లేదా ఫెయిల్ అయిన టాస్క్ ద్వారా అది లాగ్స్‌లోకి వెళ్ళవచ్చు. క్రెడెన్షియల్స్‌ను హ్యాండిల్ చేసే ప్రతి టాస్క్‌కు no_log: true ని జోడించండి, మీరు టెంప్లేట్ చేసే ఏ ఫైల్‌కైనా కఠినమైన mode మరియు owner సెట్ చేయండి, మరియు సీక్రెట్స్‌ను కమాండ్ ఆర్గ్యుమెంట్స్‌గా పంపడం మానుకోండి, ఎందుకంటే కమాండ్ రన్ అవుతున్నప్పుడు టార్గెట్ హోస్ట్‌లోని ప్రాసెస్ లిస్ట్‌లో అవి కనిపిస్తాయి.