سؤال كيف يمكنني تنفيذ كلمات المرور باستخدام كلمات المرور لكل مضيف ، بشكل آمن؟


أود أن استخدم ansible لإدارة مجموعة من الخوادم الموجودة. لقد خلقت ansible_hosts ملف ، واختبارها بنجاح (مع -K الخيار) مع الأوامر التي تستهدف مضيف واحد فقط

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

مشكلتي الآن هي أن كلمات مرور المستخدم على كل مضيف مختلفة ، ولكن لا أستطيع العثور على طريقة للتعامل مع هذا في Ansible.

عن طريق -K، تتم مطالبتي بكلمة مرور sudo واحدة فقط ، والتي يبدو أنها ستتم تجربتها بعد ذلك مع جميع المضيفات التالية بدون المطالبة:

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

البحث حتى الآن:

  • ا سؤال StackOverflow مع إجابة واحدة غير صحيحة ("استخدام -K") وردا واحدا من قبل المؤلف قائلا" وجدت أنني بحاجة إلى sudo بدون كلمة مرور "

  • مستندات Ansible، والتي تقول "استخدام sudo بدون كلمة مرور يجعل الأمور أسهل لأتمتة ، ولكن هذا غير مطلوب. "(التركيز الألغام)

  • هذا سؤال StackExchange الأمن الذي يأخذها كما قرأت ذلك NOPASSWD مطلوب

  • مقالة - سلعة "التوفير القابل للتطوير والمعرفة ..." الذي يقول:

    "قد يتطلب تشغيل sudo كتابة كلمة مرور ، وهي طريقة مؤكدة لمنع Ansible للأبد. إصلاح بسيط هو تشغيل visudo على المضيف المستهدف ، والتأكد من أن المستخدم Ansible سيستخدم لتسجيل الدخول ليس من الضروري كتابة كلمة مرور"

  • مقالة - سلعة "كتب التشغيل الأساسية Ansible"، الذي يقول

    "Ansible يمكن تسجيل الدخول إلى الخادم الهدف كجذر وتجنب الحاجة إلى sudo ، أو السماح للمستخدم sudo دون كلمة مرور ، ولكن التفكير في القيام إما يجعل الطحال يهدد بقفزتي وعرقلة بلدي القصبة الهوائية ، لذلك أنا لا "

    أفكاري بالضبط ، ولكن بعد ذلك كيفية التوسع خارج خادم واحد؟

  • قضية غريبة # 1227، "Ansible should ask for sudo password for all users in a playbook"، which was closed a year ago by mpdehaan with the comment "haven not seen much demand for this، I'm think most people are sudoing from one user account or using مفاتيح معظم الوقت. "

لذلك ... كيف يستخدم الناس Ansible في مثل هذه الحالات؟ ضبط NOPASSWD في /etc/sudoersأو إعادة استخدام كلمة المرور عبر المضيفين أو تمكين تسجيل الدخول إلى ملف SSH الجذري ، كل ذلك يبدو وكأنه تخفيضات جذرية في الأمان.


99
2017-12-09 11:49


الأصل


هل هناك سبب لعدم استخدامك مفاتيح SSH؟ - Trondh
أستخدم بالفعل مفاتيح SSH ؛ لا يؤثرون sudo (والتي لا تزال تحتاج إلى كلمة مرور). - supervacuo
قد لا يكون هذا هو بالضبط ما تبحث عنه ، ولكن في مربعات أوبونتو لا أزال أستخدم المفاتيح ، أي وضع مفتاحي العام في / root / authorized_keys للوصول مباشرة إلى الجذر. عيب واضح هو السماح بتسجيل الدخول الجذري على ssh ... أنا أيضا عدم السماح بتسجيل الدخول عبر كلمة مرور ssh وتشغيل fail2ban للأمن المضافة. - senorsmile
senorsmile شكرا على الرد! هل تمانع في جعلها إجابة بدلاً من ذلك حتى أتمكن من تقويضك لعدم قراءتك للسؤال؟ - supervacuo
أي ال ansible_ssh_password ينطبق الإعداد فقط على كلمة مرور SSH (الدليل موجود في الاسم ...). & وأنا أستخدم بالفعل الدخول إلى SSH الأساسي. - supervacuo


الأجوبة:


لقد قمت بالتأكيد بأبحاثك ...

من جميع تجربتي مع ما يُريد تحقيقه ، لا يتم دعمه. كما ذكرتم ، الدول التي لا تحتاج إلى أن لا تتطلب كلمة السر sudo ، وكنت على صواب ، فإنه لا. لكني لم أر أي طريقة لاستخدام كلمات sudo متعددة داخل ansible ، دون تشغيل تهيئات متعددة بالطبع.

لذا ، لا يمكنني تقديم الحل الدقيق الذي تبحث عنه ، ولكنك لم تسأل ...

"إذن ... كيف يستخدم الناس Ansible في مثل هذه الحالات؟ الإعداد   NOPASSWD في / etc / sudoers ، وإعادة استخدام كلمة المرور عبر المضيفين أو التمكين   جذر SSH تسجيل الدخول كل يبدو تخفيضات جذرية في الأمن ".

يمكن أن أعطيكم وجهة نظر واحدة حول ذلك. حالة الاستخدام الخاصة بي هي عقد 1k في مراكز بيانات متعددة تدعم شركة SaaS العالمية التي يتعين علي فيها تصميم / تنفيذ بعض عناصر التحكم الأمنية المشددة بجنون بسبب طبيعة أعمالنا. يعمل الأمان دائمًا على موازنة العمل ، حيث تكون قابلية الاستخدام أقل أمانًا ، ولا تختلف هذه العملية إذا كنت تستخدم 10 خوادم أو 1000 أو 100000.

أنت على حق تماما في عدم استخدام تسجيلات الدخول الجذر إما عن طريق كلمة المرور أو مفاتيح ssh. في الواقع ، يجب تعطيل تسجيل الدخول الجذري بالكامل إذا كان لدى الخوادم كابل شبكة موصول به.

دعنا نتحدث عن إعادة استخدام كلمة المرور ، في مؤسسة كبيرة ، هل من المعقول أن نطلب من sysadmins الحصول على كلمات مرور مختلفة على كل عقدة؟ بالنسبة للعقد الزوجية ، ربما ، ولكن ممثلي / مهندسي سيعملون على التمرد إذا كان لديهم كلمات مرور مختلفة على 1000 عقدة. ومن شبه المستحيل أن يكون تنفيذ ذلك مستحيلاً ، فسيتعين على كل مستخدم تخزين كلمات المرور الخاصة به في مكان ما ، على أمل أن يكون مفتاحًا ، وليس جدول بيانات. وفي كل مرة تضع فيها كلمة مرور في موقع يمكن سحبه من خلال النص العادي ، فإنك تقلل من الأمان بشكل كبير. أود أن أعرف أكثر ، عن ظهر قلب ، واحد أو اثنين من كلمات المرور قوية حقا من لديهم لاستشارة ملف keypass في كل مرة يحتاجون إلى تسجيل الدخول أو استدعاء sudo على الجهاز.

لذا فإن إعادة استخدام كلمة المرور وتوحيدها أمر مقبول تمامًا ومعيار حتى في بيئة آمنة. وإلا لن تحتاج ldap و keystone وخدمات الدليل الأخرى إلى الوجود.

عندما ننتقل إلى المستخدمين المؤتمنين ، تعمل مفاتيح ssh بشكل رائع للوصول إليك ، ولكنك لا تزال بحاجة إلى المرور عبر sudo. اختياراتك هي كلمة مرور موحدة للمستخدم الآلي (وهو مقبول في كثير من الحالات) أو لتمكين NOPASSWD كما أشرت. معظم المستخدمين الآليين يقومون بتنفيذ أوامر قليلة فقط ، لذلك من الممكن جدًا ومن المؤكد أنه من المستحسن تمكين NOPASSWD ، ولكن فقط للأوامر المعتمدة مسبقًا. أقترح عليك استخدام إدارة التهيئة الخاصة بك (غير المرغوب فيها في هذه الحالة) لإدارة ملف sudoers الخاص بك بحيث يمكنك بسهولة تحديث قائمة الأوامر بدون كلمة مرور.

الآن ، هناك بعض الخطوات التي يمكنك اتخاذها بمجرد بدء التدريج لزيادة عزل الخطر. في حين أن لدينا 1000 عقدة أو ما شابه ، إلا أنها ليست جميعها خوادم "إنتاجية" ، وبعضها عبارة عن بيئات اختبار ، إلخ. لا يمكن لجميع المشرفين الوصول إلى خوادم الإنتاج ، ولكن يمكن للمستخدمين استخدام نفس مفتاح مستخدم / تمرير SSO كما يفعلون في أماكن أخرى . ولكن المستخدمين المؤتمنين يكونون أكثر أمانًا ، على سبيل المثال أداة تلقائية يمكن للمسؤولين غير المنتجين الوصول إليها مستخدمًا وبيانات اعتماد لا يمكن استخدامها في الإنتاج. إذا كنت تريد أن تطلق العنان على جميع النقاط ، فعليك القيام بذلك على دفعتين ، مرة واحدة لغير الإنتاج ومرة ​​واحدة للإنتاج.

ولكننا نستخدم أيضًا الدمية ، نظرًا لأنها أداة لإدارة التهيئة ، لذا فإن معظم التغييرات التي يتم إجراؤها على جميع البيئات سيتم دفعها عبرها.

من الواضح أنه إذا تم إعادة فتح / إكمال هذه الميزة التي تم الاستشهاد بها من قبل ، فسيتم دعم ما تبحث عنه تمامًا. ومع ذلك ، فإن الأمن هو عملية تقييم المخاطر والتوافق. إذا لم يكن لديك سوى عدد قليل من العقد التي يمكنك تذكر كلمات المرور لها دون اللجوء إلى ملاحظة ما بعدها ، فستكون كلمات المرور المنفصلة أكثر أمانًا. لكن بالنسبة لمعظمنا ، ليس خيارًا مناسبًا.


52
2017-12-30 16:53



شكرًا ، زب - لقد تخيلت أن المستخدمين الذين لديهم عشرات إلى آلاف الخوادم سيستخدمون NOPASSWD لأسباب العقل على أي حال (ربما مدعوم بقواعد أكثر صرامة للجدار الناري إلخ) ، ولكن من الجيد أن تقرأ حالة الاستخدام والأفكار حول نموذج التهديد. - supervacuo
تعليق واحد ، على الرغم من اقتراحك حول تقييد "الموافقة المسبقة" sudo الأوامر (التي وقعت لي عندما اكتشفت ذلك NOPASSWD مطلوب إلى حد كبير). لسوء الحظ ، يبدو هذا غير معتمد تماما كذلك - لا تقدم أي وعود بشأن الاتصال مثلا  chown أو mkdir الثنائيات مباشرة ، وتحتاج إلى أن تكون قادرة على sudo /bin/sh لمعظم الوحدات للعمل. - supervacuo
يبدو لي أن أذكر أحد المهندسين الذين يشتكيون من ذلك إلى الخلف ، وهذا أمر مزعج. - Zeb


من Ansible 1.5 على ، من الممكن استخدام قبو مشفر من أجل host_vars والمتغيرات الأخرى. يعمل ذلك على الأقل على تمكينك من تخزين كل مضيف (أو لكل مجموعة) ansible_sudo_passمتغير بأمان. للأسف، --ask-vault-pass سيطالبك بكلمة مرور واحدة فقط لكل دعوة خفية ، لذلك لا تزال مقيدًا بكلمة مرور واحدة لكل المضيفين الذين ستستخدمهم معًا.

ومع ذلك ، بالنسبة لبعض الاستخدامات قد يكون هذا تحسنا على وجود كلمة مرور sudo واحدة عبر عدة مضيفين ، حيث أن المهاجم بدون الوصول إلى host_vars المشفرة سيظل بحاجة إلى كلمة مرور sudo منفصلة لكل جهاز (أو مجموعة أجهزة) يهاجمها.


36
2018-05-10 20:32



ال ansible_sudo_pass يبدو الخيار جديدًا أيضًا - ويبدو أنه يفعل ما كنت أطلبه. كلمة مرور واحدة في القبو مثالية لأغراضي ، كذلك. شكر! - supervacuo
هل هناك طريقة لتجنب التشفير الكل  host_vars باستخدام هذه الطريقة؟ (قيود محتملة لاحظها Alex Dupuy) - supervacuo
supervacuo - لتجنب تشفير جميع الأجهزة المضيفة للمضيف ، ما عليك سوى استخدام دليل var host يحتوي على main.yml (غير مشفر) و secret.yml (مشفر) - راجع الجزء الأخير من هذا القسم وثيقة حيث يتحدث عن مجموعة "raleigh" - نفس الأسلوب يعمل من أجل الفؤرة المضيفة ومجموعة Vars. أستخدم هذا كثيرًا ، والتغير الوحيد هو أنه إذا كان هناك سر مطلوب فقط لبعض كتب التشغيل ، فقد يكون من المفيد تخزينه في شجرة مختلفة تمامًا وإدراجه عبر مسار يتضمن اسم المضيف أو var. - RichVel
إذا قمت بتشفير قيمة "ansible_ssh_pass" في الخزنة ، لذا أحتاج أيضًا إلى تكرار القيمة "ansible_sudo_pass"؟ هل هناك طريقة لقيمة sudo_pass الثانية للتعبير عن قيمة "ssh_pass" الأولى؟ - emeraldjava


مع Ansible 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" لتوفير كلمات المرور لل نشر المستخدم عن بعد (الذي هو مطلوب بعد ذلك ل سودو)، لذلك هم موجودون بالفعل في الملفات (على الرغم من أن القيام بهذه الأبحاث غير الظاهرة يفقد قيمة الملح تخزينها في الملف عند إنشاء قيمة التجزئة).

  • هذا يحتفظ فقط بكلمات المرور في الملف (لا ansible_sudo_pass: معروف عاديا) لبعض زيادة إبسيلون في الأمن التشفير. الأهم من ذلك ، هذا يعني أنك لا تقوم بتشفير جميع المتغيرات الأخرى الخاصة بالمضيف ، بحيث يمكن قراءتها بدون كلمة مرور القبو.

  • يؤدي وضع كلمات المرور في دليل منفصل إلى تسهيل الاحتفاظ بالملفات خارج نطاق التحكم في المصدر أو استخدام أداة مثل GIT-سرداب لتخزينها في شكل مشفر (يمكنك استخدام هذا مع Ansible في وقت سابق أن يفتقر إلى ميزة قبو). أستخدم git-crypt وحيث إنني لا أراجع سوى المستودع في شكل مُفكَّر مشفَّر في أنظمة الملفات المشفرة ، فأنا لا أزعج بالقبو وبالتالي لا أحتاج إلى كتابة كلمة مرور vault. (استخدام كلاهما سيكون أكثر أمانًا بالطبع.)

يمكنك أيضا استخدام ابحث عن وظيفة مع ansible_ssh_pass. هذا قد يكون من الممكن مع الإصدارات السابقة من Ansible التي لا تملك ansible_sudo_pass.


22
2018-05-26 19:33



أنا أخيرا حصلت على محاولة هذا (شكرا!) ، ولكن لا أستطيع أن أرى كيف ستعمل بدون git-crypt. بقدر ما أستطيع أن أرى. يبدو وكأنه Ansible لا يوجد حتى الآن دعم لاستخدام lookup في قبو مشفر. ال password وحدة نمطية لنفترض أن هناك بعض الدعم غير الموثق للتخزين المشفر ، لكني لم أجد تفاصيل بعد. أي أدلة؟ - supervacuo


عن طريق البشري هي طريقة بسيطة لتوفير كلمات المرور مع sudo. تمرير مخازن كلمة مرور واحدة لكل ملف مما يجعل من السهل لمشاركة كلمات المرور عبر بوابة أو غيرها من الوسائل. كما أنها آمنة (باستخدام GnuPG) وإذا كنت تستخدم gpg-agent ، فإنها تتيح لك إمكانية الاستخدام دون إدخال كلمة مرور على كل استخدام.

لتوفير كلمة المرور المخزنة servers/foo للخادم foo لأقلها ، استخدمها في ملف مخزون كهذا:

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

وبالنظر إلى أنك قمت بإلغاء قفل مفتاح gpg-agent في وقت سابق ، فسيتم تشغيل هذا دون الحاجة إلى إدخال أي كلمة مرور.


19
2018-01-19 19:51



هذا حل ممتاز - شكرا لك! - Leng


هذا خيط قديم ، مع ذلك:

  • نحن نستخدم نظامين مختلفين للمصادقة داخل الشركة ، وتتم إدارة الآلات من محطات العمل المحلية في فريقي.
  • لقد كتبت vars_plugin من أجل Ansible (يمكن العثور على تطبيق كامل تمامًا في https://gist.github.com/mfriedenhagen/e488235d732b7becda81) الذي يميز العديد من أنظمة المصادقة:
  • اسم نظام التوثيق هو مجموعة محددة.
  • مستخدم login / sudo المستخدم هو مجموعة ومدير محدد.
  • لذا ، أقوم بسحب المستخدم من بيئة المشرف وكلمة المرور المقابلة عبر مكتبة مفاتيح الثعبان من كلمة مرور آمنة (نستخدم سلسلة المفاتيح الخاصة بنظام التشغيل Mac OS X ، ولكن من وثائق kwallet Gnome و _win_crypto مدعومة أيضًا).
  • أقوم بتعيين الأذونات على كلمات المرور في Keychain الخاص بـ Mac OS X لإعلامنا عن الحقيقة ، أن يطلب برنامج أمان سطر الأوامر الوصول إلى كلمة مرور لكل نظام مصادقة يستخدمه المضيفين ، لذلك أقوم بتشغيل "ping -s all -m ansible" واحصل على مطالبين (واحد لكل نظام مصادقة) حيث أضغط على شريط المسافة ويصعد ansible كلمات المرور.

3
2018-03-03 17:33



يبدو هذا أنيقًا جدًا ، شكرًا لك - أنا أحب فكرة عدم الحاجة إلى تخزين كلمات المرور في مكانين. في اللحظة التي أقوم فيها باستخدام KeepassX (لأن حلقة مفاتيح جنوم لا تبدو محمولة جدا) ولكن ربما يمكنني القيام بها python-keepass عمل؟ - supervacuo
بقدر ما أفهم ، فإن python-keyring هي فكرة مجردة لهذا ، لذا قد يستخدم زملاؤك أنظمة تشغيل أخرى. أو هل تقوم بتخزين الـ keepassx ديسيبل الخاص بك على عصا USB ويجب أن تديرها من محطات العمل مع أنظمة تشغيل مختلفة؟ - Mirko Friedenhagen
يفهم. كنت أعني أنني مضطر بالفعل إلى استخدام KeepassX للوصول إلى كلمات المرور على أنظمة غير GNOME ، لذا قم بتخزينها في gnome-keyring يعني الاحتفاظ بسجلات مكررة. لا يزال طريقة أجمل من استخدام NOPASSWD، على أية حال… - supervacuo


إحدى الطرق الممكنة للقيام بذلك هي استخدام المتغيرات البيئية.

مثلا

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

ثم في المسرحيات ، يمكنك البحث عن كلمة sudo باستخدام:

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

0
2017-07-21 08:57