Im Eingangskapitel Grundlagen haben wir uns mit der Installation bereits befasst. Mit den Hintergrundinformationen haben wir uns auch schon in den beiden Kapiteln Playbooks und YAML - was ist das? eingehend beschäftigt, sowie erste Erfahrungen mit Playbooks gesammelt.
Oft steht man vor der Herausforderung, Admin-Konten auf unzähligen Zielsystemen anzulegen und wieder zu löschen. So sind im Zuge eines onboarding von neuen Admins jeweils Konten anzulegen und mit Passworten und Schlüsselmaterial zu versorgen. Beim Ausscheiden eines Admins, müssen dessen|ihre Konten samt Passworten und Schlüssel wieder gelöscht werden.
Es soll ja zuweilen Unternehmungen geben, bei denen sich das Personal mehr oder weniger in sehr kurzen Zeitabständen die Klinge in die Hand geben, was das Prozedere dann zusätzlich vom Aufwand her nach oben treibt.
Möchte ein bestehender Admin sein|ihr Passwort oder Schlüssel ändern, kann dies auch zu einer zeitraubenden Tätigkeit ausarten. Was liegt also näher das Anlegen und Löschen der Konten samt Passwörter und Schlüsselmaterial sowie die Pflege dieser Daten mit Hilfe von Ansible zu automatisieren?
Der ungeduldigen Leser kann auch direkt zur Tat schreiten und das manuelle Anlegen der Inventory-Hülle, des Playbooks und der zugehörigen Rollen überspringen und diese Aufgaben mit folgendem Befehl sozusagen auf einem Rutsch erledigen:
$ mkdir ~/ansible ; wget https://gitlab.nausch.org/django/example_13/-/archive/main/example_13-main.tar.gz -O - | tar -xz --strip-components=1 -C ~/ansible
Wichtig: Aber nicht vergessen die Admin-Inventory-Daten in ein Ansible-.Vault verpacken!
$ ansible-vault encrypt ~/ansible/inventories/production/group_vars/all/admins
Anschliessend kann man direkt zur Ausführung schreiten.
Dreh- und Angelpunkt unserer Admin-Verwaltung ist natürlich unser Inventory. Dank unserer Vorbereitungen ins Sachen Ansible Vault können wir natürlich gehashte Passwörter und SSH-keys im Inventory vorhalten, da diese dort ja sicher verwahrt vorliegen.
Wir werden uns also erst einmal unsere Admins im Inventory eine zugehörige Datei anlegen.
$ ansible-vault create ~/ansible/inventories/production/group_vars/all/admins
Dort legen wir als erstes mal eine Hülle für die weitere Bearbeitung an.
linux_admins: - user : Vorname Nachname name : User-Name groups : wheel ids : 1000 shell : /bin/bash state : present # present bzw. absent pwd : <-- Ergebnis: openssl passwd -6 --> key : ssh-key
Damit wir keine PLAIN-Text Passworte sondern nun gehashte Passwörter im Inventory stehen haben wollen, denn aus Sicherheitsgründen dürfen nur die Admins selbst deren Passwort kennen und sonst niemand bitten wir diese uns das gehashte Passwort mit openssl
zu generieren.
$ openssl passwd -6 Password: Verifying - Password: $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31
Ferner benötigen wir noch den SSH-Publickey den wir uns ebenso wie das gerade erstellte gehashte Passwort von unseren Admins auf einem sicheren Kommunikationsweg zukommen.
Diese Daten übernehmen wir dann in unser Inventory:
$ ansible-vault edit inventories/production/group_vars/all/admins
linux_admins: - user : Michael Nausch name : django groups : wheel ids : 1000 shell : /bin/bash state : present pwd : $6$QYCbUeY2/EecXmL4$iA7Q.M457er0F0354573RoPyKcbbPMozx8uFYKMpZLJnz2JIoAlcMxi0o0b1zJywJLECw1fSB2OCdfzc9vOX1 key : ssh-ed25519 AAAAC3N1NTE5A0aTHP001zaC1lZDI1NTE5AAAAINPs/cN40aTu2HTGeHhV7IV1EngqT5 openpgp:0xDAED833F - user : Christoph Leichi name : rookie groups : wheel ids : 1001 shell : /bin/bash state : present pwd : $6$n9UE0JVV7T.nzFJOdSY1dHDEsbfY3$0SPNKmewfaQ0z5thaRMrrrI9Uig.nzFJOdSY1erIZbw5yzDqeCg4S2oXa8zn2jEf9KDfjg31 key : ssh-ed25519 AAAAC3NzaqK6Pb38bv0oM9fw0C1lZDI1NTE5AAAAIDo46Pb38bv0oM9fmgM6byylc0815 rookie@nausch.org - user : Oliver Gewinnbringer name : oliver groups : wheel ids : 1002 shell : /bin/bash state : present pwd : $6$nJVSYV9J17.SY1v0oM9fow8Do46dHDEsbfY3$0SPNKmewfaQ0z5tsafZi3haRMrrrI9Uig.OdSY1e6dHDEsbfY3$rI51ewfaQ0z5th key : ssh-ed25519 AAAAK6Pb38bv0oM9fw8DoOdSY1er4b38bNzaqK6Pb38bv0oM9fw01erIZbw5yzDqeCC5 oliver@nausch.org
In diesem Beispiel haben wir also drei Admins mit den zugehörigen Daten.
Hatten wir das Gitlab-Paket wie unter dem Abschnitt Lösung beschrieben können wir die nächsten Schritte zum Anlegen des Playbooks und der Rolle mit den zugehörigen Tasks, getrost überspringen und gleich zur Ausführung schreiten.
Das Playbook an sich ist relativ unspektakulär, wird doch nur die zugehörige Rolle eingebunden, wie wir hier sehen.
$ vim ~/ansible/playbooks/admin_updates.yml
--- # Ansible Playbook zum Anlegen, Aktualisieren und Löschen der Administratoren, # inkl. der zugehörigen Passwörter und SSH-Schlüssel, basierend auf den Angaben # im Inventory. Admins mit dem state "present" werden angelegt bzw. deren Passworte # und Schlüssel aktualisiert. Admins mit dem state "absent" werden auf den Hosts # gelöscht und können anschliessend aus dem Inventory entfernt werden. # # Aufruf zum Anlegen, Ändern oder Löschen auf allen Hosts, die im Inventory # definiert sind: # # $ ansible-playbook playbooks/admin_updates.yml # # bzw. für einzelne Hosts: # $ ansible-playbook playbooks/admin_updates.yml --limit <-hostnames-> - name: admin_updates.yml # Name des Playbooks hosts: DMZ # Hostgruppe für den das Playbook gelten soll roles: - role: admins # Admins anlegen, ändern oder löschen tags: admins # Tag-Kennzeichnung der definierten Rolle ...
Bevor wir unsere Rolle admins
anlegen, kopieren wir noch kurz das Vorlageverzeichnis common
, welches wir bei der Erstkonfiguration von Ansible, wie im Kapitel Ansible mit Hilfe von Ansible einrichten beschrieben, bereits angelegt hatten.
$ cp -avr ~/ansible/roles/common/ ~/ansible/roles/admins
Nun legen wir unseren Main-Task an.
$ vim ~/ansible/roles/admins/tasks/main.yml
--- # User unter Archlinux erstellen - include: useranlage.yml # Admin-Gruppe und -User pflegen - include: sudoers.yml # Admins der Gruppe wheel sudoers zuweisen ...
Was nun noch fehlt sind die beiden eigentlichen Tasks. Als erstes legen wir den Task an, mit Hilfe dessen die jeweilige(n) Admin-Gruppe(n) und User gepflegt werden.
$ vim ~/ansible/roles/admins/tasks/useranlage.yml
--- - name: "Sicherstellen dass die Gruppen der Admin-User existieren." ansible.builtin.group: gid: '{{ item.ids }}' name: '{{ item.name }}' state: present with_items: '{{ linux_admins }}' - name: "Sicherstellen dass die Admin-User existieren." ansible.builtin.user: append: true comment: '{{ item.user }}' create_home: true force: true state: '{{ item.state }}' group: '{{ item.name }}' groups: '{{ item.groups }}' name: '{{ item.name }}' password: '{{ item.pwd }}' shell: '{{ item.shell }}' uid: '{{ item.ids }}' remove: true with_items: '{{ linux_admins }}' - name: "Gruppe(n) entfernen, sofern der User zum Löschen gekennzeichnet ist mit absent im Inventory/Vault." ansible.builtin.group: gid: '{{ item.ids }}' name: '{{ item.name }}' state: '{{ item.state }}' with_items: '{{ linux_admins }}' - name: "SSH-Client-Verzeichnis anlegen." ansible.builtin.file: path: /home/{{ item.name }}/.ssh state: directory owner: '{{ item.name }}' group: '{{ item.name }}' mode: '0700' when: ' item.state == "present" ' with_items: '{{ linux_admins }}' - name: "SSH-Key des Admins hinterlegen." ansible.builtin.copy: dest: /home/{{ item.name }}/.ssh/authorized_keys content: | {{ item.key }} owner: '{{ item.name }}' group: '{{ item.name }}' mode: '0600' when: ' item.state == "present" ' with_items: '{{ linux_admins }}' - name: "SSH-Client-Verzeichnis entfernen, sofern der User zum Löschen gekennzeichnet ist mit absent im Inventory/Vault." ansible.builtin.file: path: /home/{{ item.name }}/.ssh state: absent when: ' item.state == "absent" ' with_items: '{{ linux_admins }}' ...
Zu guter Letzt legen wir noch den Task an, damit die Admins, die Mitglied der Gruppe wheels
sind, auch sudo-Rechte erlangen können.
$ vim ~/ansible/roles/admins/tasks/sudoers.yml
--- - name: "Der Gruppe wheel sudo Rechte zuweisen." ansible.builtin.copy: content: "# Generated by Ansible, do not edit manually!\n# Allows people in group wheel to run all command\n%wheel ALL=(ALL) ALL\n" dest: /etc/sudoers.d/10_passwd_sudo_wheel owner: root group: root mode: '0440' validate: visudo -cf %s ...
Mit Hilfe dieses Playbooks können alle erforderlichen Konfigurationsschritte reproduzierbar und beliebig oft abgesetzt werden. Somit können neue Admins hinzugefügt, SSH-Keys und Passwörter ausgerollt bzw. aktualisiert werden und natürlich bestehende Admin-Konten auch bei Bedarf wieder gelöscht werden.
Folgende Schritte werden also mit Hilfe des Playbooks abgearbeitet:
absent
im Inventory/Vault.absent
im Inventory/Vault.wheel
sudo Rechte zuweisen.
Entscheidend für das Anlegen bzw. Löschen eines Admins ist die Array-Variable state
; ist ihr der Wert present
zugewiesen wir der Admin neu angelegt und dessen Schlüssel angelegt. Ist der Wert der Vaiable aber absent
wir dessen Gruppe und User auf den Zielsystemen entfernt. Nach einem erfolgreichen Playbooklauf können wir dann anschliessend den Admin wieder aus dem Inventory löschen oder eben solange dort stehen lassen, bis dieser wieder z.B. nach einem Sabbatical seinen Dienst antritt.
Haben wir die Daten in unserem Vault entsprechend aktualisiert können wir, wie im Playbook vermerkt, das Playbook wie gewohnt aufrufen. Aufruf via für alles Hosts:
$ ansible-playbook playbooks/admin_updates.yml
bzw. für einzelne Hosts:
$ ansible-playbook playbooks/admin_updates.yml --limit <-hostnames->
Interessiert uns lediglich die erfolgreiche Abarbeitung unseres Playbook-Aufrufs können wir dies z.B. beim Host mit dem Namen vml000137
auch wie folgt erreichen:
$ ansible-playbook playbooks/admin_updates.yml --limit vml000137 | sed -n '/PLAY RECAP/,$p'
PLAY RECAP ******************************************************************************************************** vml000137 : ok=7 changed=0 unreachable=0 failed=0 skipped=1 rescued=0 ignored=0
Wir haben nun eine standardisiertes Verfahren für die Pflege unserer Admins, so dass aufwändiges manuelles Anlegen oder Löschen von Admin-Konten nicht mehr wichtige Ressourcen auffrisst. Auch können so unsere Admins ihre Passwörter und|oder SSH-Key sehr einfach auf Dutzenden oder vielen Hunderten Servern austauschen und aktualisieren.