सवाल प्रति-मेजबान पासवर्ड के साथ सुरक्षित रूप से मैं जवाब कैसे कार्यान्वित कर सकता हूं?


मैं उपयोग करना चाहता हूँ ansible मौजूदा सर्वर के समूह का प्रबंधन करने के लिए। मैंने एक बनाया है ansible_hosts फ़ाइल, और सफलतापूर्वक परीक्षण (के साथ -K विकल्प) कमांड के साथ जो केवल एक मेजबान को लक्षित करता है

ansible -i ansible_hosts host1 --sudo -K # + commands ...

मेरी समस्या यह है कि प्रत्येक होस्ट पर उपयोगकर्ता पासवर्ड अलग हैं, लेकिन मुझे जवाब में इसे संभालने का कोई तरीका नहीं मिल रहा है।

का उपयोग करते हुए -K, मुझे केवल एक ही सूडो पासवर्ड अप-फ्रंट के लिए संकेत दिया जाता है, जो कि बाद के सभी होस्टों के लिए बिना किसी संकेत के प्रयास किया जाता है:

host1 | ...
host2 | FAILED => Incorrect sudo password
host3 | FAILED => Incorrect sudo password
host4 | FAILED => Incorrect sudo password
host5 | FAILED => Incorrect sudo password

अब तक अनुसंधान:

  • StackOverflow सवाल एक गलत उत्तर के साथ ("उपयोग करें -K") और लेखक द्वारा एक प्रतिक्रिया ने कहा" पता चला कि मुझे पासवर्ड रहित सुडो की आवश्यकता है "

  • उत्तरदायी दस्तावेज़, जो कहता है "पासवर्ड रहित सुडो का उपयोग चीजों को स्वचालित करना आसान बनाता है, लेकिन यह आवश्यक नहीं है"(जोर मेरा)

  • यह सुरक्षा StackExchange सवाल है जो इसे पढ़ने के रूप में लेता है NOPASSWD आवश्यक है

  • लेख "स्केलेबल और समझने योग्य प्रावधान ..." जो कहते हैं:

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

  • लेख "मूल उत्तरदायी प्लेबुक", जो कहते हैं

    "उत्तरदायी लक्ष्य सर्वर में रूट के रूप में लॉग इन कर सकता है और सूडो की आवश्यकता से बच सकता है, या उत्तरदायी उपयोगकर्ता को पासवर्ड के बिना सुडो होने देना चाहिए, लेकिन ऐसा करने का विचार मेरे स्पलीन को मेरे गुलेट को छलांग लगाने और मेरी विंडपाइप को अवरुद्ध करने की धमकी देता है, इसलिए मैं नहीं है "

    मेरे विचार बिल्कुल, लेकिन फिर एक सर्वर से आगे कैसे विस्तार करें?

  • उत्तरदायी मुद्दा # 1227, "उत्तरदायी प्लेबुक में सभी उपयोगकर्ताओं के लिए सुडो पासवर्ड मांगना चाहिए", जिसे एक साल पहले mpdehaan द्वारा टिप्पणी के साथ बंद कर दिया गया था "इस के लिए बहुत अधिक मांग नहीं देखी गई है, मुझे लगता है कि ज्यादातर लोग केवल एक उपयोगकर्ता खाते से उपयोग कर रहे हैं या उपयोग कर रहे हैं अधिकांश समय चाबियाँ। "

तो ... इस तरह की स्थितियों में लोग उत्तरदायी कैसे उपयोग कर रहे हैं? सेटिंग NOPASSWD में /etc/sudoers, मेजबानों में पासवर्ड का पुन: उपयोग करना या रूट एसएसएच लॉगिन सक्षम करना सुरक्षा में काफी कठोर कमी दिखता है।


97
2017-12-09 11:49


मूल


क्या कोई कारण है कि आप एसएसएच कुंजी का उपयोग नहीं कर रहे हैं? - Trondh
मैं पहले से ही एसएसएच कुंजी का उपयोग कर रहा हूँ; वे प्रभावित नहीं करते हैं sudo (जो अभी भी एक पासवर्ड की आवश्यकता होनी चाहिए)। - supervacuo
यह वही नहीं हो सकता है जो आप खोज रहे हैं, लेकिन उबंटू बॉक्स पर मैं अभी भी चाबियों का उपयोग करता हूं, यानी रूट के रूप में सीधे प्राप्त करने के लिए अपनी सार्वजनिक कुंजी / रूट / अधिकृत_की में डाल रहा हूं। स्पष्ट दोष एसएसएच पर रूट लॉग इन की अनुमति दे रहा है ... मैं एसएसएच पर पासवर्ड लॉग इन भी अस्वीकार करता हूं और अतिरिक्त सुरक्षा के लिए fail2ban चलाता हूं। - senorsmile
प्रतिक्रिया के लिए @senorsmile धन्यवाद! क्या आप इसके बजाय उत्तर में इसे ध्यान में रखेंगे, इसलिए मैं आपको प्रश्न पढ़ने के लिए कम कर सकता हूं? - supervacuo
अर्थात।  ansible_ssh_password सेटिंग केवल एसएसएच पासवर्ड पर लागू होती है (सुराग नाम में है ...)। और मैं पहले से ही कुंजी-आधारित एसएसएच लॉगिन का उपयोग कर रहा हूं। - supervacuo


जवाब:


आपने निश्चित रूप से अपना शोध किया है ...

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

इसलिए, मैं उस सटीक समाधान की पेशकश नहीं कर सकता जिसे आप ढूंढ रहे हैं, लेकिन आपने पूछा था ...

"तो ... इस तरह की स्थितियों में लोग उत्तरदायी कैसे उपयोग कर रहे हैं? सेटिंग   / Etc / sudoers में NOPASSWD, मेजबानों या पासवर्ड में पासवर्ड का पुन: उपयोग करना   रूट एसएसएच लॉगिन सभी सुरक्षा में कठोर कमी लगते हैं। "

मैं आपको उस पर एक दृश्य दे सकता हूं। मेरा उपयोग केस एक वैश्विक सास फर्म का समर्थन करने वाले एकाधिक डेटा केंद्रों में 1k नोड्स है जिसमें मुझे अपने व्यापार की प्रकृति के कारण कुछ बेहद तंग सुरक्षा नियंत्रणों को डिजाइन / कार्यान्वित करना है। सुरक्षा हमेशा कार्य को संतुलित करती है, अधिक उपयोगिता कम सुरक्षा, यदि आप 10 सर्वर या 1,000 या 100,000 चला रहे हैं तो यह प्रक्रिया अलग नहीं है।

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

एक बड़े उद्यम में, पासवर्ड पुन: उपयोग के बारे में बात करते हैं, क्या यह प्रत्येक नोड पर sysadmins के अलग-अलग पासवर्ड रखने के लिए उचित है? कुछ नोड्स के लिए, शायद, लेकिन मेरे व्यवस्थापक / इंजीनियर विद्रोह करेंगे अगर उन्हें 1000 नोड्स पर अलग-अलग पासवर्ड रखना पड़ता था। यह कार्यान्वित करना असंभव होगा, प्रत्येक उपयोगकर्ता को कहीं भी अपने पासवर्ड कहीं भी स्टोर करना होगा, उम्मीद है कि एक कीपपास, स्प्रेडशीट नहीं। और हर बार जब आप किसी ऐसे स्थान पर पासवर्ड डालते हैं जहां इसे सादे पाठ में खींचा जा सकता है, तो आपने अपनी सुरक्षा में काफी कमी आई है। मैं उन्हें एक मशीन पर सूडो में लॉग इन करने या आमंत्रित करने के लिए हर बार एक कीप फ़ाइल फ़ाइल से परामर्श करने के बजाय दिल से, एक या दो वास्तव में मजबूत पासवर्ड के बारे में जानता हूं।

तो पासवर्ड पुन: उपयोग और मानकीकरण ऐसा कुछ है जो एक सुरक्षित वातावरण में पूरी तरह से स्वीकार्य और मानक है। अन्यथा ldap, keystone, और अन्य निर्देशिका सेवाओं को मौजूद होने की आवश्यकता नहीं होगी।

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

अब, जोखिम को अलग करने के लिए स्केलिंग शुरू करने के बाद आप कुछ कदम उठा सकते हैं। जबकि हमारे पास 1000 या तो नोड्स हैं, उनमें से सभी 'उत्पादन' सर्वर नहीं हैं, कुछ परीक्षण वातावरण हैं, आदि। सभी व्यवस्थापक उत्पादन सर्वर तक नहीं पहुंच सकते हैं, हालांकि वे अपने एसएसओ उपयोगकर्ता / पास | कुंजी का उपयोग कर सकते हैं, क्योंकि वे कहीं और होंगे । लेकिन स्वचालित उपयोगकर्ता थोड़ा अधिक सुरक्षित हैं, उदाहरण के लिए एक स्वचालित उपकरण जो गैर-उत्पादन प्रशासकों तक पहुंच सकता है, उस उपयोगकर्ता और प्रमाण-पत्र हैं जिनका उत्पादन में उपयोग नहीं किया जा सकता है। यदि आप सभी नोड्स पर उत्तरदायी लॉन्च करना चाहते हैं, तो आपको इसे दो बैचों में करना होगा, एक बार गैर-उत्पादन के लिए और एक बार उत्पादन के लिए।

हम हालांकि कठपुतली का उपयोग करते हैं, क्योंकि यह एक लागू कॉन्फ़िगरेशन प्रबंधन उपकरण है, इसलिए सभी वातावरण में अधिकांश परिवर्तन इसके माध्यम से बाहर निकल जाएंगे।

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


52
2017-12-30 16:53



धन्यवाद, @ ज़ेब - मैंने कल्पना की थी कि दर्जन से हजारों सर्वर वाले उपयोगकर्ता उपयोग करेंगे NOPASSWD वैसे भी सैनिटी कारणों के लिए (शायद कड़े फ़ायरवॉल नियमों द्वारा समर्थित है आदि।), लेकिन खतरे के मॉडल पर आपके उपयोग-मामले और विचारों को पढ़ना अच्छा होता है। - supervacuo
एक टिप्पणी, हालांकि, "पूर्व अनुमोदित" को प्रतिबंधित करने के बारे में आपके सुझाव पर sudo आदेश (जब मुझे पता चला कि मेरे साथ ऐसा हुआ था NOPASSWD बहुत जरूरी है)। दुर्भाग्य से, ऐसा लगता है पूरी तरह से असमर्थित भी - जवाब देने के बारे में कोई वादा नहीं करता है जैसे  chown या mkdir बाइनरी सीधे, और करने में सक्षम होने की जरूरत है sudo /bin/sh अधिकांश मॉड्यूल काम करने के लिए। - supervacuo
मुझे लगता है कि मेरे इंजीनियरों में से एक ने कुछ समय पहले शिकायत की है, यह कष्टप्रद है। - Zeb


उत्तर 1.5 से, एक का उपयोग करना संभव है एन्क्रिप्टेड वॉल्ट host_vars और अन्य चर के लिए। यह कम से कम प्रति होस्ट (या प्रति-समूह) को स्टोर करने में सक्षम बनाता है ansible_sudo_passसुरक्षित रूप से चर। दुर्भाग्य से, --ask-vault-pass प्रति जवाब आमंत्रण के लिए केवल एक वॉल्ट पासवर्ड के लिए संकेत मिलेगा, इसलिए आप अभी भी उन सभी होस्टों के लिए एक वॉल्ट पासवर्ड से बाध्य हैं जिन्हें आप एक साथ उपयोग करेंगे।

फिर भी, कुछ उपयोगों के लिए यह एकाधिक होस्टों में एक एकल सूडो पासवर्ड रखने में सुधार हो सकता है, क्योंकि आपके एन्क्रिप्टेड होस्ट_वर्स तक पहुंच के बिना हमलावर के रूप में अभी भी प्रत्येक मशीन (या मशीन समूह) के लिए एक अलग सूडो पासवर्ड की आवश्यकता होती है जिसे वह हमला करता है।


36
2018-05-10 20:32



ansible_sudo_pass विकल्प नया लगता है - और ऐसा लगता है जो मैं पूछ रहा था। एक ही वॉल्ट पासवर्ड मेरे उद्देश्यों के लिए भी आदर्श है। धन्यवाद! - supervacuo
एन्क्रिप्टिंग से परहेज करने का कोई तरीका है सब  host_vars इस विधि का उपयोग कर? (एलेक्स डुप्यू द्वारा उल्लेख की गई एक संभावित सीमा) - supervacuo
@supervacuo - सभी होस्ट वर्र्स को एन्क्रिप्ट करने से बचने के लिए, केवल एक मेजबान var निर्देशिका का उपयोग करें जिसमें main.yml (unencrypted) और secret.yml (एन्क्रिप्टेड) ​​है - अंतिम भाग देखें इस डॉक्टर खंड जहां यह "रैलीघ" समूह के बारे में बात करता है - वही तकनीक होस्ट वर्र्स और ग्रुप वर्र्स के लिए काम करती है। मैं इसका बहुत उपयोग करता हूं, केवल भिन्नता यह है कि यदि कुछ प्लेबुक के लिए केवल एक रहस्य की आवश्यकता होती है तो इसे पूरी तरह से एक अलग पेड़ में स्टोर करने के लिए उपयोगी हो सकता है और उस पथ के माध्यम से शामिल किया जा सकता है जिसमें मेजबान या var नाम शामिल है। - RichVel
अगर मैंने वॉल्ट में 'ansible_ssh_pass' मान एन्क्रिप्ट किया है, तो मुझे 'ansible_sudo_pass' मान को डुप्लिकेट करने की भी आवश्यकता है? क्या पहले ssho_pass मान को पहले 'ssh_pass' मान को वापस करने के लिए कोई तरीका है? - emeraldjava


उत्तर 1.5 के साथ, यह सेट करना संभव है ansible_sudo_pass चर का उपयोग कर lookup('password', …):

ansible_sudo_pass: "{{ lookup('password', 'passwords/' + inventory_hostname) }}"

मुझे फ़ाइलों का उपयोग करने से अधिक सुविधाजनक लगता है host_vars/ कई कारणों के लिए:

  • मैं वास्तव में उपयोग करता हूँ with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" के लिए पासवर्ड प्रावधान करने के लिए तैनात दूरस्थ उपयोगकर्ता (जिसके लिए इसके लिए आवश्यक है sudo), इसलिए वे पहले से ही फाइलों में मौजूद हैं (हालांकि इन सादे टेक्स्ट लुकअप करने से नमक मूल्य कम हो जाता है हैश किए गए मान उत्पन्न होने पर फ़ाइल में संग्रहीत)।

  • यह फ़ाइल में केवल पासवर्ड रखता है (नहीं ansible_sudo_pass: ज्ञात सादे पाठ) क्रिप्टोग्राफिक सुरक्षा में कुछ ईपीएसलॉन वृद्धि के लिए। अधिक महत्वपूर्ण बात यह है कि आप अन्य सभी होस्ट-विशिष्ट चर को एन्क्रिप्ट नहीं कर रहे हैं, इसलिए उन्हें वॉल्ट पासवर्ड के बिना पढ़ा जा सकता है।

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

आप भी इसका उपयोग कर सकते हैं देखो के साथ काम करो ansible_ssh_pass; यह उत्तर के पिछले संस्करणों के साथ भी संभव हो सकता है जो नहीं है ansible_sudo_pass


22
2018-05-26 19:33



मैं आखिरकार यह कोशिश करने के लिए चारों ओर मिल गया (धन्यवाद!), लेकिन यह नहीं देख सकता कि यह बिना काम कैसे करेगा git-crypt; जहा तक मै देख सकता हू। यह Ansible की तरह लगता है अभी तक समर्थन नहीं है उपयोग के लिए lookup एक एन्क्रिप्टेड वॉल्ट पर। password मॉड्यूल दस्तावेज़ कहें कि एन्क्रिप्टेड स्टोरेज के लिए अभी तक कुछ अनौपचारिक समर्थन है, लेकिन मुझे अभी तक विवरण नहीं मिला है। कोई सुराग? - supervacuo


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

के रूप में संग्रहीत पासवर्ड प्रदान करने के लिए servers/foo सर्वर के लिए foo जवाब देने के लिए, इस तरह की एक सूची फ़ाइल में इसका उपयोग करें:

[servers]
foo ansible_sudo=True \
    ansible_sudo_pass="{{ lookup('pipe', 'pass servers/foo') }}"

यह देखते हुए कि आपने पहले जीजीपी-एजेंट के लिए कुंजी अनलॉक की है, यह किसी भी पासवर्ड को दर्ज करने की आवश्यकता के बिना उत्तरदायी होगा।


17
2018-01-19 19:51



इस तरह का एक उत्कृष्ट समाधान - धन्यवाद! - Leng


यह एक पुराना धागा है, फिर भी:

  • हम घर में दो अलग-अलग प्रमाणीकरण प्रणालियों का उपयोग करते हैं, मशीनों का प्रबंधन मेरी टीम में स्थानीय वर्कस्टेशन से किया जाता है।
  • मैंने एक लिखा vars_plugin उत्तरदायी के लिए (बल्कि एक पूर्ण कार्यान्वयन पाया जा सकता है https://gist.github.com/mfriedenhagen/e488235d732b7becda81) जो कई प्रमाणीकरण प्रणालियों को अलग करता है:
  • प्रमाणीकरण प्रणाली का नाम समूह विशिष्ट है।
  • प्रयुक्त लॉगिन / सुडो उपयोगकर्ता समूह और व्यवस्थापक विशिष्ट है।
  • इसलिए मैं उपयोगकर्ता को व्यवस्थापक के पर्यावरण से और पासवर्ड से सुरक्षित पाइथन-कीरिंग लाइब्रेरी के माध्यम से संबंधित पासवर्ड खींचता हूं (हम मैक ओएस एक्स की कीचेन का उपयोग करते हैं, लेकिन प्रलेखन क्वेललेट जीनोम और _win_crypto से भी समर्थित हैं)।
  • मै मैक ओएस एक्स की चाबी में पासवर्ड पर अनुमतियों को इस तथ्य के बारे में सूचित करने के लिए अनुमतियां सेट करता हूं कि कमांड लाइन प्रोग्राम सुरक्षा अनुरोध करता है कि प्रत्येक प्रमाणीकरण प्रणाली के लिए पासवर्ड मेजबान, इसलिए मैं "ansible -s all -m ping" चलाता हूं और दो संकेत प्राप्त करता हूं (प्रत्येक प्रमाणीकरण प्रणाली के लिए एक) जहां मैं स्पेस बार दबाता हूं और उत्तरदायी पासवर्ड को चुनता है।

3
2018-03-03 17:33



यह बहुत साफ दिखता है, धन्यवाद - मुझे दो जगहों पर पासवर्ड स्टोर न करने का विचार पसंद है। फिलहाल मैं KeepassX का उपयोग कर फंस गया हूं (क्योंकि गनोम कीरिंग बहुत पोर्टेबल नहीं लगती है) लेकिन शायद मैं कर सकता हूं python-keepass काम? - supervacuo
जहां तक ​​मैं समझता हूं, पाइथन-कीरिंग इसके लिए एक अमूर्त है, इसलिए आपके सहयोगी अन्य ओएस का उपयोग कर सकते हैं। या आप अपने यूएसबी स्टिक पर अपने रखरखाव डीबी स्टोर करते हैं और विभिन्न ओएस के साथ वर्कस्टेशन से प्रशासन करना है? - Mirko Friedenhagen
समझ लिया; मेरा मतलब था कि मुझे पहले से ही KeepassX का उपयोग गैर-गनोम सिस्टम पर पासवर्ड तक पहुंचने के लिए करना है, इसलिए उन्हें संग्रहीत करना gnome-keyring डुप्लिकेट रिकॉर्ड रखने का मतलब होगा। उपयोग करने से अभी भी अच्छा है NOPASSWD, हालांकि… - supervacuo


ऐसा करने का एक संभावित तरीका पर्यावरणीय चर का उपयोग कर रहा है।

जैसे

pass1=foo pass2=bar ansible-playbook -i production servers.xml

फिर नाटकों में, आप सूडो पासवर्ड का उपयोग कर देख सकते हैं:

lookup('env', 'pass1') 
lookup('env', 'pass2') 

0
2017-07-21 08:57