Vraag Hoe kan ik ansible veilig implementeren met wachtwoorden per host?


Ik zou willen gebruiken Ansible om een ​​groep bestaande servers te beheren. Ik heb een gemaakt ansible_hosts bestand, en met succes getest (met de -K optie) met opdrachten die alleen op een enkele host zijn gericht

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

Mijn probleem is nu dat de gebruikerswachtwoorden op elke host anders zijn, maar ik kan geen manier vinden om dit in Ansible af te handelen.

Gebruik makend van -K, Ik word alleen gevraagd voor een enkel sudo-wachtwoord vooraf, dat vervolgens wordt geprobeerd voor alle volgende hosts zonder te vragen om:

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

Onderzoek tot nu toe:

  • een StackOverflow-vraag met één onjuist antwoord ("gebruik -K") en een antwoord van de auteur met de woorden" Ik had wachtwoordloze sudo nodig "

  • de documenten van Ansible, die zeggen "Gebruik van wachtwoordloze sudo maakt dingen makkelijker te automatiseren, maar het is niet verplicht. "(nadruk van mij)

  • deze security StackExchange-vraag wat het als lees dat neemt NOPASSWD Is benodigd

  • artikel "Schaalbare en begrijpelijke provisioning ..." waarop staat:

    "Voor het uitvoeren van sudo moet je misschien een wachtwoord typen, wat een zekere manier is om Ansible voor altijd te blokkeren. Een simpele oplossing is om visudo op de doelhost uit te voeren en ervoor te zorgen dat de gebruiker die Ansible gebruikt om in te loggen geen wachtwoord hoeft in te voeren"

  • artikel "Basic Ansible Playbooks", waarop staat

    "Ansible kan als root inloggen op de doelserver en de noodzaak voor sudo voorkomen, of de gebruiker van de niet-gebruiker een sudo laten gebruiken zonder wachtwoord, maar de gedachte om te doen maakt of mijn milt dreigt mijn keel op te springen en mijn luchtpijp te blokkeren, dus ik niet"

    Mijn gedachten precies, maar dan hoe verder te gaan dan een enkele server?

  • anoniem nummer # 1227, "Ansible moet om een ​​sudo-wachtwoord vragen voor alle gebruikers in een playbook", dat een jaar geleden door mpdehaan werd afgesloten met de opmerking "Ik heb hier niet veel van gezien, ik denk dat de meeste mensen alleen maar van één gebruikersaccount verdringen of toetsen meestal. "

Dus ... hoe gebruiken mensen Ansible in situaties als deze? omgeving NOPASSWD in /etc/sudoers, het hergebruiken van wachtwoorden over hosts of het inschakelen van root-SSH-aanmelding lijken allemaal nogal drastische reducties in beveiliging.


97
2017-12-09 11:49


oorsprong


Is er een reden waarom je geen SSH-sleutels gebruikt? - Trondh
Ik gebruik al SSH-sleutels; ze hebben geen invloed op sudo (waarvoor nog steeds een wachtwoord nodig is). - supervacuo
Dit is misschien niet precies wat je zoekt, maar op Ubuntu-boxes gebruik ik nog steeds sleutels, d.w.z. mijn publieke sleutel in / root / authorized_keys zetten om direct als root binnen te komen. Een voor de hand liggend nadeel is dat rootaanmeldingen via ssh worden toegestaan ​​... Ik verbreek ook wachtwoordinlogs via ssh en voer fail2ban uit voor extra beveiliging. - senorsmile
@senorsmile bedankt voor het antwoord! Zou je in plaats daarvan een antwoord willen maken, zodat ik je kan downlaberen omdat ik de vraag niet lees? - supervacuo
d.w.z. de ansible_ssh_password instelling geldt alleen voor het SSH-wachtwoord (de aanwijzing staat in de naam ...). & Ik gebruik al key-based SSH-login. - supervacuo


antwoorden:


Je hebt zeker je onderzoek gedaan ...

Uit al mijn ervaring met ansible wat je wilt bereiken, wordt niet ondersteund. Zoals je al zei, verklaart ansible dat er geen wachtwoordloze sudo nodig is, en je hebt gelijk, maar dat is niet zo. Maar ik moet nog een methode zien om meerdere sudo-wachtwoorden te gebruiken binnen ansible, zonder natuurlijk meerdere configs uit te voeren.

Ik kan dus niet de exacte oplossing bieden waarnaar je op zoek bent, maar je vroeg wel ...

"Dus ... hoe gebruiken mensen Ansible in situaties als deze? Setting   NOPASSWD in / etc / sudoers, hergebruik van wachtwoord over hosts of inschakelen   root SSH login lijkt alles nogal drastisch de beveiliging te verminderen. "

Ik kan je daar één mening over geven. Mijn use-case is 1k-nodes in meerdere datacenters ter ondersteuning van een wereldwijd SaaS-bedrijf waarin ik enkele waanzinnig strenge beveiligingsmaatregelen moet ontwerpen / implementeren vanwege de aard van ons bedrijf. Beveiliging is altijd evenwichtsoefening, meer bruikbaarheid minder beveiliging, dit proces is niet anders als u 10 servers of 1000 of 100.000 gebruikt.

U hebt absoluut gelijk als u rootaanmeldingen niet gebruikt via wachtwoord of ssh-sleutels. In feite moet rootaanmelding volledig worden uitgeschakeld als op de servers een netwerkkabel is aangesloten.

Laten we het hebben over hergebruik van wachtwoorden, is het in een grote onderneming redelijk om sysadmins te vragen om verschillende wachtwoorden op elk knooppunt te hebben? misschien voor een paar knooppunten, maar mijn beheerders / ingenieurs zouden muiten als ze verschillende wachtwoorden op 1000 knooppunten zouden moeten hebben. Implementeren zou ook bijna onmogelijk zijn, elke gebruiker zou zijn eigen wachtwoorden ergens moeten opslaan, hopelijk een keypass, geen spreadsheet. En elke keer dat u een wachtwoord op een locatie zet waar het in platte tekst kan worden verwijderd, heeft u uw beveiliging sterk verminderd. Ik zou liever weten dat ze, uit het hoofd, een of twee echt sterke wachtwoorden kennen dan een keypass-bestand moeten raadplegen telkens wanneer ze zich moeten aanmelden of sudo op een computer moeten aanroepen.

Dus het opnieuw gebruiken van het wachtwoord en standaardisatie is iets dat volledig acceptabel en standaard is, zelfs in een veilige omgeving. Anders zouden ldap, keystone en andere directoryservices niet hoeven te bestaan.

Wanneer we naar geautomatiseerde gebruikers gaan, werken ssh-sleutels geweldig om je binnen te krijgen, maar je moet nog steeds sudo doorkomen. Uw keuzes zijn een gestandaardiseerd wachtwoord voor de geautomatiseerde gebruiker (wat in veel gevallen acceptabel is) of om NOPASSWD in te schakelen zoals u hebt aangegeven. De meeste geautomatiseerde gebruikers voeren slechts enkele commando's uit, dus het is heel goed mogelijk en zeker wenselijk om NOPASSWD in te schakelen, maar alleen voor vooraf goedgekeurde opdrachten. Ik raad u aan om uw configuratiemanagement te gebruiken (in dit geval anonymous) om uw sudoers-bestand te beheren, zodat u de lijst met wachtwoorden zonder wachtwoord eenvoudig kunt bijwerken.

Nu zijn er enkele stappen die u kunt nemen zodra u begint te schalen om het risico verder te isoleren. Hoewel we 1000 of meer knooppunten hebben, zijn het niet allemaal 'productieservers', sommige zijn testomgevingen, enzovoort. Niet alle beheerders hebben toegang tot productieservers, die kunnen dan wel dezelfde SSO-gebruiker / pas | -sleutel gebruiken als elders . Maar geautomatiseerde gebruikers zijn een beetje veiliger, bijvoorbeeld een geautomatiseerde tool die niet-productiebeheerders toegang hebben tot een gebruiker en referenties die niet kunnen worden gebruikt in de productie. Als u ansible op alle knooppunten wilt starten, moet u dit in twee batches doen, één keer voor niet-productie en één keer voor productie.

We gebruiken echter ook marionet, omdat het een handhavend configuratiebeheertool is, zodat de meeste veranderingen in alle omgevingen erdoorheen worden geduwd.

Het is duidelijk dat als dat functie-verzoek dat je citeerde wordt heropend / voltooid, wat je wilt doen volledig wordt ondersteund. Maar zelfs dan is veiligheid een proces van risicobeoordeling en compromis. Als u slechts een paar knooppunten heeft, kunt u de wachtwoorden onthouden zonder dat u zich hoeft te beroepen op een post-it-notitie, afzonderlijke wachtwoorden zijn iets veiliger. Maar voor de meesten van ons is het geen haalbare optie.


52
2017-12-30 16:53



Bedankt, @Zeb - ik had me voorgesteld dat gebruikers met tientallen tot duizenden servers zouden gebruiken NOPASSWD om gezond verstand redenen (waarschijnlijk ondersteund door strakkere firewall regels enz.), maar het is goed om je use-case en gedachten over het dreigingsmodel te lezen. - supervacuo
Eén opmerking echter over uw suggestie om te beperken tot 'vooraf goedgekeurd' sudo commando's (wat me wel eens overkwam toen ik dat ontdekte NOPASSWD is vrijwel vereist). Helaas lijkt dit volledig niet-ondersteund - ansible maakt geen beloftes over bellen bijv.  chown of mkdir binaire bestanden rechtstreeks, en moet kunnen sudo /bin/sh voor de meeste modules om te werken. - supervacuo
Ik meen me te herinneren dat een van mijn ingenieurs daar al een tijdje over klagen, dat is vervelend. - Zeb


Vanaf Ansible 1.5 is het mogelijk om een gecodeerde kluis voor host_vars en andere variabelen. Hiermee kunt u ten minste een per host (of per groep) opslaan ansible_sudo_passvariabele veilig. Helaas, --ask-vault-pass zal slechts één kluiswachtwoord vragen per onmogelijke aanroep, dus je bent nog steeds beperkt tot een enkel kluiswachtwoord voor alle hosts die je samen zult gebruiken.

Desondanks kan dit voor sommige toepassingen een verbetering zijn ten opzichte van het hebben van een enkel sudo-wachtwoord voor meerdere hosts, omdat een aanvaller zonder toegang tot je gecodeerde host_vars nog steeds een apart sudo-wachtwoord nodig zou moeten hebben voor elke machine (of computergroep) die hij of zij aanvalt.


36
2018-05-10 20:32



De ansible_sudo_pass optie lijkt ook nieuw - en lijkt te doen waar ik om vroeg. Een enkelvoudig kluiswachtwoord is ook ideaal voor mijn doeleinden. Bedankt! - supervacuo
Is er een manier om versleuteling te vermijden allemaal  host_vars deze methode gebruiken? (een mogelijke beperking genoteerd door Alex Dupuy) - supervacuo
@supervacuo - Om te voorkomen dat alle hostvars worden gecodeerd, gebruikt u gewoon een host var-map met main.yml (niet-versleuteld) en secret.yml (versleuteld) - zie laatste deel van dit documentgedeelte waar het het heeft over de "raleigh" -groep - dezelfde techniek werkt voor host vars en group vars. Ik gebruik dit vaak, de enige variatie is dat als een geheim alleen nodig is voor sommige playbooks, het handig kan zijn om het in een andere boom volledig op te slaan en het op te nemen via een pad dat de host- of var-naam bevat. - RichVel
Als ik de waarde 'ansible_ssh_pass' in de kluis heb gecodeerd, dus ik moet ook de waarde 'ansible_sudo_pass' dupliceren? Is er een manier voor de tweede sudo_pass-waarde om de eerste 'ssh_pass' -waarde te laten zien? - emeraldjava


Met Ansible 1.5 is het mogelijk om de ansible_sudo_pass variabele gebruik lookup('password', …):

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

Ik vind dit handiger dan het gebruik van bestanden in host_vars/ om verschillende redenen:

  • Ik gebruik het eigenlijk with_password: "passwords/{{ inventory_hostname}} encrypt=sha256_crypt" om de wachtwoorden voor de inzetten externe gebruiker (die dan nodig is voor sudo) dus ze zijn al aanwezig in de bestanden (hoewel het doen van deze op schrift gestelde lookups de zoutwaarde verliest opgeslagen in het bestand wanneer de hashed-waarde wordt gegenereerd).

  • Dit houdt alleen de wachtwoorden in het bestand (nr ansible_sudo_pass: bekende platte tekst) voor een toename van cryptografische beveiliging met epsilon. Belangrijker nog, dit betekent dat je niet alle andere host-specifieke variabelen versleutelt, zodat ze kunnen worden gelezen zonder het kluiswachtwoord.

  • Door de wachtwoorden in een aparte map te plaatsen, is het eenvoudiger om de bestanden buiten de controle te houden, of om een ​​tool zoals git-crypt om ze in gecodeerde vorm op te slaan (je kunt dit gebruiken met eerdere Ansible zonder kluis). Ik gebruik git-crypt en omdat ik de repository alleen bekijk in gedecodeerde vorm op gecodeerde bestandssystemen, heb ik geen moeite met de kluis en dus hoef ik geen kluiswachtwoord in te typen. (Het gebruik van beide is natuurlijk veiliger.)

U kunt ook de opzoeken functie met ansible_ssh_pass; dit kan zelfs mogelijk zijn met eerdere versies van Ansible die dat niet hebben ansible_sudo_pass.


22
2018-05-26 19:33



ik Tenslotte kwam er toe dit te proberen (bedankt!), maar kan niet zien hoe het zou werken zonder git-crypt; zo ver ik kan zien. Het lijkt op Ansible heeft nog geen ondersteuning voor gebruik lookup op een gecodeerde kluis. De password module docs beweren dat er nog niet-gedocumenteerde ondersteuning is voor versleutelde opslag, maar ik moet nog details vinden. Enige aanwijzingen? - supervacuo


Gebruik makend van voorbij lopen is een eenvoudige methode om ansible te voorzien van sudo-wachtwoorden. geeft één wachtwoord per bestand door, waardoor het eenvoudig is om wachtwoorden te delen via git of andere methoden. Het is ook beveiligd (met behulp van GnuPG) en als je gpg-agent gebruikt, kun je ansible gebruiken zonder een wachtwoord in te voeren voor elk gebruik.

Om het wachtwoord opgeslagen als servers/foo voor server foo naar ansible, gebruik het in een inventarisbestand als dit:

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

Aangezien je eerder de sleutel voor gpg-agent hebt ontgrendeld, zal dit een mogelijkheid zijn zonder dat je een wachtwoord hoeft in te voeren.


17
2018-01-19 19:51



Wat een uitstekende oplossing - bedankt! - Leng


Dit is een vrij oude thread, niettemin:

  • We gebruiken twee verschillende authenticatiesystemen in eigen beheer, het beheer van machines gebeurt vanuit lokale werkstations in mijn team.
  • Ik schreef een vars_plugin voor Ansible (een vrij complete implementatie is te vinden op https://gist.github.com/mfriedenhagen/e488235d732b7becda81) die verschillende authenticatiesystemen onderscheidt:
  • De naam van het authenticatiesysteem is groepspecifiek.
  • De gebruikte gebruikersnaam / sudo-gebruiker is specifiek voor groepen en beheerders.
  • Dus ik trek de gebruiker uit de admin-omgeving en het bijbehorende wachtwoord via de python-keyring-bibliotheek uit een wachtwoordkluis (we gebruiken de sleutelhanger van Mac OS X, maar van de documentatie kwallet worden Gnome en _win_crypto ook ondersteund).
  • Ik heb machtigingen ingesteld voor de wachtwoorden in de sleutelhanger van Mac OS X om me op de hoogte te stellen van het feit dat de opdrachtregelprogrammabeveiliging toegang vraagt ​​tot een wachtwoord voor elk verificatiesysteem dat wordt gebruikt door de hosts, dus voer ik "ansible -s all -mping" uit en krijg ik twee prompts (een voor elk authenticatiesysteem) waar ik op de spatiebalk druk en het anonymous de wachtwoorden ophaalt.

3
2018-03-03 17:33



Dit ziet er heel netjes uit, dank u - ik vind het een goed idee om geen wachtwoorden op te slaan op twee plaatsen. Op dit moment zit ik vast met het gebruik van KeepassX (omdat de GNOME-sleutelhanger niet erg draagbaar lijkt) maar misschien kan ik python-keepass werk? - supervacuo
Voor zover ik begrijp, is python-keyring hiervoor een abstractie, dus uw collega's kunnen andere besturingssystemen gebruiken. Of bewaart u uw keepassx db op een USB-stick en moet u vanaf werkstations met verschillende besturingssystemen beheren? - Mirko Friedenhagen
begrepen; Ik bedoelde dat ik KeepassX al moest gebruiken om toegang te krijgen tot wachtwoorden op niet-GNOME-systemen, dus ze op te slaan gnome-keyring zou betekenen dat je dubbele records bewaart. Nog veel leuker dan het gebruik NOPASSWD, hoewel ... - supervacuo


Een mogelijke manier om dit te doen is het gebruik van omgevingsvariabelen.

bijv.

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

Vervolgens kunt u in de plays het sudo-wachtwoord opzoeken met behulp van:

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

0
2017-07-21 08:57