In diesem Artikel konzentrieren wir uns auf zwei wichtige Ansible-Konzepte. Das erste Konzept wird sein, wie die SSH-schlüsselbasierte und passwortbasierte Authentifizierung in Ansible funktioniert. Das zweite Konzept ist, wie man die Privilegien erhöht, wenn man mit Ad-hoc-Befehlen und Playbooks arbeitet.
Ich habe ein Labor-Setup mit drei Knoten, auf dem Ubuntu 20.04 LTS-Computer mit VirtualBox und Vagrant ausgeführt werden. Es gibt einen ausführlichen Artikel über den Laboraufbau, den Sie unter dem folgenden Link lesen können.
- Automatisierte Ansible Lab-Einrichtung mit Vagrant und Virtualbox unter Linux
Schlüsselbasierte Authentifizierung in Ansible
Das erste, was Sie beim Erlernen von Ansible verstehen müssen, ist, wie die Kommunikation zwischen dem Controller und den verwalteten Knoten abläuft. Ansible verwendet das SSH-Protokoll um eine Verbindung zu den verwalteten Knoten herzustellen und die Aufgabe auszuführen.
Jedes Mal, wenn Sie ein Playbook oder Ad-hoc-Befehle ausführen, müssen Sie das SSH-Passwort angeben, damit Ansible sich über SSH bei den verwalteten Knoten authentifizieren kann.
Um dies zu vermeiden, wird empfohlen, ein SSH-Schlüsselpaar zu erstellen und den öffentlichen Schlüssel mit allen Knoten zu teilen, damit Ansible über das Schlüsselpaar kommunizieren kann.
Ich habe zwei Schlüsselpaare namens first_key erstellt und second_key Verwenden Sie das folgende Skript zur Demonstration.
Erstellen Sie eine Textdatei namens create_keypair.sh mit folgendem Inhalt.
#!/usr/bin/env bash
# THIS SCRIPT WILL CREATE SSH KEY PAIR AND DISTRIBUTE ACROSS ALL NODES
read -p "Enter the name for the key : " KEY_NAME
ssh-keygen -b 2048 -t rsa -f /home/vagrant/.ssh/${KEY_NAME} -q -N ""
# LOOPING THROUGH AND DISTRIBUTING THE KEY
for val in controller managed1 managed2; do
echo "-------------------- COPYING KEY TO ${val^^} NODE ------------------------------"
sshpass -p 'vagrant' ssh-copy-id -f -i /home/vagrant/.ssh/${KEY_NAME}.pub -o "StrictHostKeyChecking=no" [email protected]$val
done Geben Sie dem Skript die Ausführungsberechtigung und führen Sie es aus.
$ chmod +x path/to/create_keypair.sh
$ ./create_keypair.sh
Ich habe dieses Skript für mein Labor-Setup erstellt. Sie können den Abschnitt für die for-Schleife bearbeiten und Ihre verwalteten Knotennamen entsprechend hinzufügen.
$ tree .ssh/
.ssh/
├── authorized_keys
├── first_key
├── first_key.pub
├── known_hosts
├── second_key
└── second_key.pub
Wenn Sie Schlüssel mit anderen Namen als dem Standardnamen (id_rsa) erstellt haben, versucht ssh, die Standardschlüsselnamen zu finden, und wenn sie nicht gefunden werden, fordert es zur passwortbasierten Authentifizierung auf.
debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /home/vagrant/.ssh/id_rsa debug1: Trying private key: /home/vagrant/.ssh/id_dsa debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa debug1: Trying private key: /home/vagrant/.ssh/id_ecdsa_sk debug1: Trying private key: /home/vagrant/.ssh/id_ed25519 debug1: Trying private key: /home/vagrant/.ssh/id_ed25519_sk debug1: Trying private key: /home/vagrant/.ssh/id_xmss debug1: Next authentication method: password [email protected]'s password:
In diesem Fall müssen Sie die private Schlüsseldatei explizit mit dem -i erwähnen Flagge.
$ ssh -v -i /home/vagrant/.ssh/first_key [email protected]
Wenn Sie einen Ad-hoc-Befehl oder ein Playbook ausführen, können Sie die --key-file verwenden oder --private-key flag und übergeben Sie die Datei mit dem privaten Schlüssel als Argument. Im folgenden Beispiel können Sie sehen, dass ich beide Schlüssel (first_key &second_key) verwendet habe, um erfolgreich mit den verwalteten Knoten zu kommunizieren.
# USING --key-file FLAG
$ ansible managed1 -m ping --key-file /home/vagrant/.ssh/second_key
managed1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
} # USING --private-key FLAG
$ ansible managed1 -m ping --private-key /home/vagrant/.ssh/first_key
managed1 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": false,
"ping": "pong"
}
Sie können auch den Parameter "private_key_file hinzufügen " in der ansible.cfg Konfigurationsdatei, die auf Ad-hoc-Befehle und alle Playbook-Aufgaben angewendet wird.
$ vim ansible.cfg
Fügen Sie die folgende Zeile hinzu:
Private_key_file = /home/vagrant/.ssh/first_key
Ersetzen Sie /home/vagrant/.ssh/first_key mit Ihren eigenen.
Sie können auch "ansible_ssh_private_key" hinzufügen Parameter in Ihrer Inventardatei, der Vorrang vor ansible.cfg hat Datei. Unten ist, wie mein Inventar jetzt eingerichtet ist. Knoten verwaltet1 verwendet "first_key" und verwaltet2 verwendet "second_key" .
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key [ubuntu2] managed2 ansible_ssh_private_key_file=/home/vagrant/.ssh/second_key
Wenn Sie jetzt den Ad-hoc-Befehl oder das Playbook erneut ausführen, können Sie sehen, dass beide Schlüssel erfolgreich authentifiziert werden. Sie können die Ausführlichkeit erhöhen, um zu überprüfen, ob die richtigen Schlüssel gemäß unserer Eingabe verwendet werden.
$ ansible -vvv all -m ping
Jetzt sollten Sie ein gutes Verständnis dafür haben, wie die schlüsselbasierte Authentifizierung in Ansible funktioniert. Es ist wichtig, den Vorrang beim Hinzufügen des Parameters in verschiedenen Dateien zu verstehen. Die Befehlszeilenoption hat höhere Priorität, gefolgt von der Inventardatei und ansible.cfg Konfigurationsdatei.
Passwortbasierte SSH-Authentifizierung in Ansible
Wenn Sie eine Aufgabe ausführen, verwendet Ansible den aktuellen Benutzer im Controller-Knoten, um über SSH mit den verwalteten Knoten zu kommunizieren. Sie können das Shell-Modul verwenden und die Datei „whoami ", um den Benutzernamen in den verwalteten Knoten zu überprüfen. In meinem Fall lautet der Benutzername "vagrant" . Der vagabundierende Benutzer authentifiziert sich mit Schlüsseln, die ich im vorherigen Abschnitt eingerichtet habe.
$ whoami
vagrant
$ ansible all -m shell -a "whoami" managed2 | CHANGED | rc=0 >> vagrant managed1 | CHANGED | rc=0 >> vagrant
Wenn Sie sich als anderer Benutzer mit den verwalteten Knoten verbinden möchten, können Sie --u verwenden oder --user kennzeichnen und den Benutzernamen als Argument übergeben. Wenn Sie das folgende Bild sehen, versuche ich, den Benutzer „karthick“ zu verwenden, der kein SSH-Schlüssel-Setup hat und keine Schlüssel an die verwalteten Knoten verteilt, sodass die Verbindung fehlschlägt.
$ ansible all -m shell -a "whoami" -u karthick
$ ansible all -m shell -a "whoami" --user karthick
Um die passwortbasierte Authentifizierung zu verwenden, können Sie den -k verwenden oder --ask-pass Flagge. Sie werden aufgefordert, das SSH-Passwort für den Benutzer (karthick) einzugeben. Stellen Sie sicher, dass das Passwort für den Benutzer auf allen Knoten gleich ist.
$ ansible all -m shell -a "whoami" -u karthick -k
$ ansible all -m shell -a "whoami" -u karthick --ask-pass
Sie können das Passwort auch in einer Datei speichern und den Dateinamen als Argument an --connection-password-file übergeben oder --conn-pass-file Flagge. Dies wird nicht empfohlen, da Sie das Kennwort in einer Nur-Text-Datei speichern. Sie können Ansible Vault verwenden, um die Passwortdatei zu verschlüsseln, aber dies ist ein separates Thema, das diskutiert werden muss.
$ ansible all -m shell -a "whoami" -u karthick --connection-password-file pass.txt
$ ansible all -m shell -a "whoami" -u karthick --conn-pass-file pass.txt
Sie können den Benutzernamen und das Passwort auch als Parameter in der Inventardatei übergeben. Auch dies ist nicht der beste Weg, um das Passwort zu speichern. Unten sehen Sie, wie meine Inventardatei jetzt eingerichtet ist.
[ubuntu1] managed1 ansible_ssh_private_key_file=/home/vagrant/.ssh/first_key ansible_user=vagrant [ubuntu2] managed2 ansible_user=karthick ansible_ssh_pass=password
$ ansible all -m shell -a "whoami" -u karthick managed1 | CHANGED | rc=0 >> vagrant managed2 | CHANGED | rc=0 >> karthick
Vorsicht: Ich kann die Beispiele mit Ad-hoc-Befehlen ausführen, aber die gleichen Flags gelten auch für das Playbook.
Privilegienausweitung in Ansible
Es gibt Zeiten, in denen Ihre Aufgabe erhöhte Rechte (Root) erfordert, um erfolgreich ausgeführt zu werden. Zum Beispiel Paketverwaltung. Sie können Pakete nur als root installieren, entfernen oder aktualisieren user oder mit sudo Privileg.
Wenn Sie das Hilfe-Flag zusammen mit Ansible oder Ansible-Playbook ausführen, finden Sie einen Abschnitt zur Rechteausweitung, wie im Bild gezeigt.
$ ansible --help
$ ansible-playbook --help
Wenn Sie eine Aufgabe mit root ausführen möchten Privileg, sollten Sie -b verwenden oder --become Flagge.
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -b
managed1 | CHANGED => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python3"
},
"changed": true,
"name": "sshd",
"state": "started",
Standardmäßig sudo wird als Privilegien-Eskalationsmethode verwendet. Sie können die Methode ändern, indem Sie --become-method festlegen Flagge. Sie können die Liste der unterstützten Methoden abrufen, indem Sie den folgenden Befehl ausführen.
$ ansible-doc -t become -l ansible.netcommon.enable Switch to elevated permissions on a network device community.general.doas Do As user community.general.dzdo Centrify's Direct Authorize community.general.ksu Kerberos substitute user community.general.machinectl Systemd's machinectl privilege escalation community.general.pbrun PowerBroker run community.general.pfexec profile based execution community.general.pmrun Privilege Manager run community.general.sesu CA Privileged Access Manager community.general.sudosu Run tasks using sudo su - runas Run As user su Substitute User sudo Substitute User DO
Sie können ein sudo angeben oder nicht Kennwort für die verwalteten Knoten, je nachdem, wie der Benutzer eingerichtet ist. In meinem Fall habe ich den Benutzer vagrant eingerichtet um sudo auszuführen ohne Passwortabfrage.
Wenn Ihr sudo Benutzer benötigt ein Passwort, um zu funktionieren, dann sollten Sie das -K verwenden oder --ask-become-pass Flag, das zur Eingabe von sudo auffordert Passwort.
Wie Sie aus dem folgenden Fehler ersehen können, wenn ich versuche, ohne sudo auszuführen Passwort für den Benutzer „karthick“, es wirft eine Fehlermeldung aus, die besagt:„Missing sudo password“ .
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b
SSH password:
managed1 | FAILED! => {
"msg": "Missing sudo password"
} $ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b -K
Das Sudo-Passwort kann in einer Datei gespeichert und als Argument an --become-password-file übergeben werden oder --become-pass-file Flagge. Ansible Vault kann zum Verschlüsseln dieser Datei verwendet werden, wird jedoch nicht empfohlen.
$ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-password-file pass.txt $ ansible ubuntu1 -m service -a "name=sshd state=restarted" -i inventory -u karthick -k -b --become-pass-file pass.txt
Sie können auch das "werden" einfügen Direktive im Playbook auf Aufgabenebene oder Spielebene.
Das folgende Bild zeigt, wie das "werden" Direktive wird auf der Spielebene verwendet .
Das folgende Bild zeigt, wie das "werden" Direktive wird auf der Aufgabenebene verwendet .
Wie Sie der Ausgabe entnehmen können, ist der ssh Der Dienst wird in managed1 problemlos neu gestartet Knoten.
$ ansible-playbook restart_service.yml PLAY [Restart SSHD service] *************************************************************************** TASK [Restart SSHD in managed1.anslab.com] ************************************************************ changed: [managed1] PLAY RECAP ******************************************************************************************** managed1 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Die Direktive "become" kann auch in ansible.cfg gesetzt werden Konfigurationsdatei und die Inventardatei. Es wird jedoch empfohlen, die Direktive im Playbook festzulegen. Sie können die verschiedenen Parameter für ansible.cfg abrufen Datei über den Link unten.
- Direktive werden
Wenn Sie die Aufgabe als ein anderer Benutzer ausführen möchten, nachdem Sie sich mit den verwalteten Knoten verbunden haben, sollten Sie den --become-user verwenden Flagge. Standardmäßig ist es auf root eingestellt Benutzer.
Schlussfolgerung
In diesem Artikel haben wir gesehen, wie die schlüsselbasierte Authentifizierung und die Kennwortauthentifizierung in Ansible funktionieren, und verschiedene Flags, die für die Authentifizierung unterstützt werden. Wir haben auch gesehen, wie Privilegieneskalation in Ansible funktioniert.
Um in die Tiefe zu gehen, sollten Sie ein gutes Verständnis dafür haben, wie verschiedene Verfahren zur Eskalation von Berechtigungen funktionieren, und die Umgebung gemäß Ihren Anforderungen einrichten, ohne die Sicherheit zu gefährden.
Weiterlesen:
- Erste Schritte mit Ansible Ad-Hoc-Befehlen