Sunucu başına şifre ile güvenilir bir şekilde nasıl uygulayabilirim?

Bir grup varolan sunucuyu yönetmek için ansible kullanmak istiyorum . Bir ansible_hostsdosya oluşturdum ve -Kyalnızca tek bir bilgisayarı hedefleyen komutlarla ( seçenekle) başarıyla test ettim

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

Şimdi benim sorunum, her ana bilgisayardaki kullanıcı şifrelerinin farklı olması, ancak bunu Ansible'da kullanmanın bir yolunu bulamıyorum.

Kullanarak -K, sadece ön tarafta tek bir sudo şifresi istenir, bu daha sonra sorulmadan tüm sonraki ana bilgisayarlar için denenmiştir:

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

Şu ana kadar araştırma:

• Bir yanlış cevaplı ("use ") ve yazarın "Parolasız sudo'ya ihtiyacım olduğunu öğrendim" yazan bir yanıt içeren bir StackOverflow sorusu-K

• "Parolasız sudo kullanımı işleri otomatikleştirmeyi kolaylaştırıyor, ancak bu gerekli değil " diyen Ansible docs . (vurgu madeni)

• Bu güvenlik StackExchange sorusuNOPASSWD gerekli olduğu gibi onu okur

• "Ölçeklenebilir ve Anlaşılabilir Hazırlama ..." başlıklı makale şöyledir :

  "sudo çalıştırmak sonsuza dek Ansible'ı engellemenin kesin bir yolu olan bir parola yazmayı gerektirebilir. Basit bir düzeltme, hedef ana bilgisayarda visudo çalıştırmak ve Ansible kullanıcısının oturum açmak için kullanacağı bir parola yazmak zorunda olmadığından emin olmaktır"

• makale "Temel yanıtlayıcı 'Playbooks" diyor,

  "Ansible, hedef sunucuya root olarak giriş yapabilir ve sudo ihtiyacını önleyebilir ya da ansible kullanıcısının parola olmadan sudo olmasına izin verebilir, fakat ya yapmama düşüncesi dalağımı gulletimi fırlatıp soluk borumu tıkamak için tehdit ediyor. yapamaz"

  Düşüncelerim tam olarak, ama sonra tek bir sunucunun ötesine nasıl geçilir?

• 1227 , "Ansible bir oyun kitabındaki tüm kullanıcılar için sudo şifresini sormalı", "bir yıl önce mpdehaan tarafından" Bu konuda çok fazla talep görmedim, sanırım çoğu insan yalnızca birinden sudo ediyor " kullanıcı hesabı veya çoğu zaman tuşları kullanarak. "

Peki ... insanlar böyle durumlarda Ansible'ı nasıl kullanıyor? Ayar NOPASSWDiçinde /etc/sudoers, ana makineler arasında şifreyi yeniden veya kök SSH giriş sağlayan tüm güvenlik içinde oldukça ciddi azalmalara görünüyor.

Kesinlikle araştırmanı yaptın ...

Yaptığım şeyi nezaketle yaptığım deneyimlerden, başarmak istediğin şey desteklemiyor. Bahsettiğin gibi, ansible şifresiz sudo gerektirmediğini ve haklı olduğunu söylüyor. Ancak, tabii ki çoklu konfigürasyonlar çalıştırmadan, birden fazla sudo şifresi kullanma olanını ansible içinde görmedim.

Bu yüzden, tam olarak aradığınız çözümü öneremem ama sordunuz ...

“Öyleyse… insanlar böyle durumlarda Ansible'ı nasıl kullanıyorlar? / Etc / sudoers'da NOPASSWD'yi ayarlamak, ana bilgisayarlar arasında parolayı yeniden kullanmak veya kök SSH girişini etkinleştirmek, hepsinde güvenlik açısından oldukça büyük düşüşler gibi görünüyor.”

Bu konuda size bir fikir verebilirim. Kullanım durumum, işimizin doğası gereği delicesine sıkı güvenlik kontrolleri tasarlamak / uygulamak zorunda olduğum küresel bir SaaS firmasını destekleyen birden fazla veri merkezinde 1k düğüm. Güvenlik her zaman dengeleyicidir, daha fazla kullanılabilirlik daha az güvenliktir, 10 veya 1000 veya 100.000 sunucu çalıştırıyorsanız, bu işlem farklı değildir.

Kök girişlerini şifre veya ssh tuşları ile kullanmamanız kesinlikle doğrudur. Aslında, sunucular kendilerine bağlı bir ağ kablosuna sahipse kök giriş işlemi tamamen devre dışı bırakılmalıdır.

Parolaların yeniden kullanımı hakkında konuşalım, büyük bir kuruluşta, sistem yöneticilerinden her düğümde farklı parolalara sahip olmalarını istemek mantıklı mıdır? Birkaç düğüm için, belki, ancak yöneticilerim / mühendislerim, 1000 düğümde farklı şifreler olması durumunda isyan ederlerdi. Bunun da neredeyse imkansız olacağını uygulamak, her kullanıcının bir yerde kendi şifrelerini saklaması gerekecek, umarım bir elektronik tablo değil. Ve ne zaman bir parola düz metinde çıkarılabileceği bir yere koyduğunuzda, güvenliğinizi büyük ölçüde azalttınız. Bir makineye sudo girmeleri veya çağırmaları gerektiğinde her seferinde bir anahtar geçiş dosyasına başvurmaları gerekmeksizin gerçekten bir ya da iki şifreli şifreyi bilmelerini isterdim.

Dolayısıyla parolanın yeniden kullanımı ve standardizasyonu güvenli bir ortamda bile tamamen kabul edilebilir ve standart bir şeydir. Aksi halde ldap, kilit taşı ve diğer dizin hizmetlerinin mevcut olması gerekmeyecektir.

Otomatikleştirilmiş kullanıcılara geçtiğimizde, ssh anahtarları içeri girmek için harika çalışıyor, ancak yine de sudo'dan geçmeniz gerekiyor. Seçimleriniz, otomatik kullanıcı için (çoğu durumda kabul edilebilir) standartlaştırılmış bir paroladır veya belirttiğiniz NOPASSWD'yi etkinleştirmek içindir. Çoğu otomatik kullanıcı yalnızca birkaç komut yürütür, bu nedenle NOPASSWD'yi etkinleştirmek oldukça mümkün ve kesinlikle istenir, ancak yalnızca önceden onaylanmış komutlar için. Şifreniz komutları kolayca güncelleyebilmeniz için sudoers dosyanızı yönetmek için yapılandırma yönetiminizi (bu durumda etkili) kullanmanızı öneririm.

Şimdi, riski daha da izole etmek için ölçeklendirmeye başladığınızda atabileceğiniz bazı adımlar var. 1000 kadar düğümümüz olmasına rağmen, hepsi 'üretim' sunucusu değil, bazıları test ortamı vb. . Ancak otomatik kullanıcılar biraz daha güvenlidir; örneğin, üretim dışı yöneticilerin erişebileceği otomatik bir araç, üretimde kullanılamayan bir kullanıcıya ve kimlik bilgilerine sahiptir. Tüm düğümlerde yanıt vermeyi başlatmak istiyorsanız, bir kez üretim dışı ve bir kez üretim için iki grup halinde yapmanız gerekir.

Yine de kukla kullanıyoruz, çünkü zorlayıcı bir konfigürasyon yönetimi aracı olduğundan, tüm ortamlarda yapılan çoğu değişiklik bu durumdan atılır.

Açıkçası, bahsettiğiniz bu özellik isteği yeniden açılır / tamamlanırsa, yapmak istediğiniz şey tamamen desteklenir. Yine de güvenlik, risk değerlendirme ve uzlaşma sürecidir. Eğer bir post-not'a başvurmadan şifrelerini hatırlayabileceğiniz sadece birkaç düğümünüz varsa, ayrı şifreler biraz daha güvenli olacaktır. Ama çoğumuz için bu uygun bir seçenek değil.

Ansible 1.5 'den itibaren host_vars ve diğer değişkenler için şifreli bir kasa kullanmak mümkündür . Bu, en azından bir ana bilgisayar başına (veya grup başına) ansible_sudo_passdeğişkeni güvenli bir şekilde saklamanızı sağlar . Ne yazık ki, --ask-vault-passher makul çağrı için yalnızca bir kasa şifresi isteyecektir, bu yüzden birlikte kullanacağınız tüm ana bilgisayarlar için tek bir kasa şifresi ile sınırlandırılmışsınızdır.

Bununla birlikte, bazı kullanımlar için bu, birden fazla ana bilgisayarda tek bir sudo şifresine sahip olma konusunda bir gelişme olabilir, çünkü şifrelenmiş ana bilgisayar_varlarına erişiminiz olmayan bir saldırganın, saldırdığı her makine (veya makine grubu) için ayrı bir sudo şifresine ihtiyacı olacaktır.

Ansible 1.5 ile, ansible_sudo_pass değişkenini aşağıdakiler kullanarak ayarlamak mümkündür lookup('password', …):

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

Bunu host_vars/birkaç nedenden dolayı dosyaları kullanmaktan daha uygun buluyorum :

• Aslında kullanmak with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" hükmüne için şifreleri dağıtma (o için gerekli olan uzaktan kullanıcıya sudo (bunlar düz metin aramaları yapıyor karma değeri oluşturulur dosyada saklanır tuz değerini kaybeder rağmen)), bu yüzden onlar zaten dosyalarında mevcut olduğu .

• Bu ansible_sudo_pass:, şifreleme güvenliğinde bazı epsilon artışları için sadece dosyadaki şifreleri tutar ( bilinen düz metin değil). Daha da önemlisi, diğer tüm host-değişkenleri şifrelemediğiniz anlamına gelir, bu yüzden kasa şifresi olmadan okunabilirler.

• Şifreleri ayrı bir dizine koymak, dosyaları kaynak kontrolünün dışında tutmayı veya şifreli biçimde saklamak için git-crypt gibi bir aracı kullanmayı kolaylaştırır (bunu, kasa özelliğini taşımayan önceki Ansible ile kullanabilirsiniz). Git-crypt kullanıyorum ve yalnızca şifreli dosya sistemlerinde şifreli biçimde depoyu kontrol ettiğimden beri kasa ile uğraşmıyorum ve bu yüzden bir kasa şifresi yazmam gerekmiyor. (Her ikisini de kullanmak elbette daha güvenli olurdu.)

Ayrıca kullanabilirsiniz arama ile işlevini ansible_ssh_pass ; bu, ansible_sudo_pass'a sahip olmayan önceki Ansible sürümlerinde bile mümkün olabilir .

Kullanılması geçiş sudo şifreleri ile yanıtlayıcı 'sağlamak için basit bir yöntemdir. pass, dosya başına bir parola depolar; bu, parolaları git veya diğer yöntemlerle paylaşmayı kolaylaştırır. Aynı zamanda güvenli (GnuPG kullanarak) ve eğer gpg-agent kullanıyorsanız, her kullanımda bir şifre girmeden ansible kullanmanıza izin verir.

servers/fooSunucunun foosaklayabileceği şekilde depolanan şifreyi sağlamak için , aşağıdaki gibi bir envanter dosyasında kullanın:

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

Daha önce gpg-agent için anahtarın kilidini açtıysanız, bu herhangi bir parola girmenize gerek kalmadan sorunsuz çalışacaktır.

Bu yine de oldukça eski bir konu:

• İki farklı kimlik doğrulama sistemi kurum içinde kullanıyoruz, makinelerin yönetimi ekibimdeki yerel iş istasyonlarından yapılıyor.
• vars_pluginAnsible için bir yazı yazdım (oldukça eksiksiz bir uygulama https://gist.github.com/mfriedenhagen/e488235d732b7becda81 adresinde bulunabilir ):
• Kimlik doğrulama sisteminin adı gruba özgüdür.
• Kullanılan giriş / sudo kullanıcısı gruba ve yöneticiye özgüdür.
• Bu yüzden kullanıcıyı yöneticinin ortamından ve karşılık gelen parolayı python-keyring kütüphanesi üzerinden bir parola güvenliğinden çekerim (Mac OS X'in anahtar zincirini kullanıyoruz, ancak Gnome ve _win_crypto belgelerini de destekliyoruz).
• Mac OS X'in anahtarlığındaki parolalar üzerindeki izinleri belirledim, komut satırı program güvenliği ana bilgisayarlar tarafından kullanılan her kimlik doğrulama sistemi için bir parola erişimi istiyor, bu yüzden "ansible -s all -m ping" komutunu çalıştırıyorum. ve boşluk çubuğuna bastığımda iki istem (her bir kimlik doğrulama sistemi için bir tane olsun) ve yanıtlayanlar şifreleri alır.

Bunu yapmanın olası bir yolu çevresel değişkenleri kullanmaktır.

Örneğin

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

Sonra oyunlarda, aşağıdakileri kullanarak sudo şifresini arayabilirsiniz:

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