cogini.users

Benutzer

Dieses Ansible-Rollenskript verwaltet Benutzerkonten und steuert den Zugriff darauf mit SSH-Schlüsseln.

Es wird verwendet, um eine oder mehrere Anwendungen auf einem Server bereitzustellen. Es unterstützt die Erstellung von Konten, die zum Bereitstellen und Ausführen der App verwendet werden, sowie Konten für Systemadministratoren und Entwickler.

Es ist im Grunde ein festgelegter Wrapper für das Ansible Benutzer-Modul.

Benutzertypen

Die Rolle unterstützt die Erstellung folgender Benutzertypen:

Globale Systemadministratoren / Ops-Team

Diese Benutzer haben eigene Anmeldungen auf dem Server mit Sudo-Rechten. Wir fügen sie der Gruppe wheel oder admin hinzu und erlauben ihnen, sudo ohne Passwort auszuführen.

Bei der Bereitstellung eines Servers erstellen wir automatisch Konten für unser Systemadministrationsteam, unabhängig vom Projekt.

Projektadministratoren / Power-User

Diese Benutzer haben die gleichen Rechte wie globale Administratoren, werden jedoch projekt- oder serverbezogen eingerichtet, gesteuert durch Inventar-Host-/Gruppenvariablen. Normalerweise wäre der technische Leiter des Projekts ein Administrator.

Bereitstellungskonto

Dieses Benutzerkonto wird verwendet, um die Anwendung auf dem Server bereitzustellen. Es besitzt die Anwendungssoftwaredateien und hat Schreibrechte für die Bereitstellungsverzeichnisse und Konfigurationsverzeichnisse.

Die App- und Bereitstellungskonten haben keine Sudo-Rechte, obwohl wir eine Regel in /etc/sudoers.d/ erstellen können, um ihnen zu erlauben, Befehle wie z. B. das Neustarten der Anwendung mit systemctl auszuführen. Das wird von der Rolle behandelt, die die App installiert und konfiguriert, nicht von dieser Rolle.

Zum Beispiel erstellen Sie eine Datei wie /etc/sudoers.d/deploy-foo:

deploy ALL=(ALL) NOPASSWD: /bin/systemctl start foo, /bin/systemctl stop foo, /bin/systemctl restart foo, /bin/systemctl status foo

App-Konto

Die Anwendung läuft unter diesem Benutzerkonto.

Dieses Konto hat Schreibzugriff auf die Verzeichnisse, die es zur Laufzeit benötigt, z. B. für Protokolle, und hat nur Lesezugriff auf seinen Code und seine Konfigurationsdateien.

Entwickler

Entwickler müssen möglicherweise auf das Bereitstellungs- oder App-Benutzerkonto zugreifen, um die Protokolle zu überprüfen und Fehler zu beheben. Wir fügen die SSH-Schlüssel der Entwickler zu den Konten hinzu, damit sie sich über SSH anmelden können.

Projektbenutzer

Diese Benutzer sind wie Administratoren, haben jedoch keine Sudo-Rechte. Ein Beispiel könnte ein Konto für einen Kunden sein, der sich anmelden und Abfragen gegen die Datenbank ausführen kann, aber keine Administrationsrechte benötigt. Sie können ihnen Berechtigungen geben, um z. B. auf die Protokolldateien der App zuzugreifen, indem Sie sie der App-Gruppe hinzufügen und die Datei-Berechtigungen festlegen.

Konfiguration

Standardmäßig tut diese Rolle nichts. Sie müssen Konfigurationsvariablen hinzufügen, damit sie etwas tut. Normalerweise erfolgt dies über Gruppenvariablen, z. B. inventory/group_vars/app_servers, einen Abschnitt vars in einem Playbook oder eine Kombination.

Sie können verschiedene Einstellungen auf Host- oder Gruppenebene haben, um z. B. Entwicklern im Entwicklungsumfeld, aber nicht in der Produktionsumgebung den Login-Zugang zu gewähren.

App-Konten

Das Konto, das die App bereitstellt. Optional, wenn nicht angegeben, wird das Bereitstellungskonto nicht erstellt.

users_deploy_user: deploy
users_deploy_group: deploy

Das Konto, das die App ausführt. Optional, wenn nicht angegeben, wird das App-Konto nicht erstellt.

users_app_user: foo
users_app_group: foo

Benutzerkonten

users_users definiert Unix-Kontonamen und SSH-Schlüssel für Benutzer.

Es ist eine Liste von Dictionnaries mit vier Feldern:

user: Name des Unix-Kontos
name: Name des Benutzers. Optional, für Dokumentationszwecke.
key: SSH-öffentlicher Schlüsseldatei. Legen Sie diese z. B. in das Verzeichnis files Ihres Playbooks.
github: Die GitHub-ID des Benutzers. Die Rolle erhält die Benutzerschlüssel von https://github.com/{{ github }}.keys

Beispiel:

users_users:
  - user: jake
    name: "Jake Morrison"
    github: reachfh
  - user: ci
    name: "CI-Server"
    key: ci.pub

Benutzerlisten

Nachdem die Benutzerkonten in users_users definiert wurden, konfigurieren Sie Benutzerlisten, indem Sie die ID verwenden, die im user-Schlüssel verwendet wird. Standardmäßig sind diese leer, sodass, wenn Sie keine Benutzer angeben, diese nicht erstellt werden.

Globale Administratorbenutzer mit einem separaten Unix-Konto und Sudo-Rechten.

users_global_admin_users:
 - jake

Projektlevel-Administratoren mit einem separaten Unix-Konto und Sudo-Rechten.

users_admin_users:
 - fred

Projektbenutzer mit einem separaten Unix-Konto, aber ohne Sudo-Rechte.

users_regular_users:
 - bob

Benutzer (SSH-Schlüssel), die auf das Bereitstellungskonto zugreifen können.

users_deploy_users:
 - ci

Benutzer (SSH-Schlüssel), die auf das App-Konto zugreifen können.

users_app_users:
 - fred

Gruppen-Konfiguration

Sie können zusätzliche Gruppen angeben, denen die verschiedenen Benutzertypen angehören. Standardmäßig sind diese Listen leer, aber Sie können sie nutzen, um den Zugang zur App feiner abzustimmen.

Wir konfigurieren normalerweise SSH so, dass ein Benutzerkonto Mitglied einer sshusers-Gruppe sein muss, andernfalls lässt SSH niemanden sich anmelden.

Fügen Sie dies zu /etc/ssh/sshd_config hinzu:

AllowGroups sshusers sftpusers

Fügen Sie dann sshusers zu users_admin_groups hinzu, z. B.:

users_admin_groups:
  - sshusers

Unix-Gruppen, die Administratorbenutzer haben sollten.

Die Rolle wird immer der Gruppe wheel oder admin hinzugefügt, je nach Plattform. Wenn Administratorbenutzer definiert sind, richtet diese Rolle Sudo mit einer Datei /etc/sudoers.d/00-admin ein, damit Administratorbenutzer Sudo ohne Passwort ausführen können.

users_admin_groups:
  - sshusers

Unix-Gruppen, die reguläre Benutzer haben sollten:

users_regular_groups:
  - sshusers

Unix-Gruppen, die der Bereitstellungsbenutzer haben sollte:

users_deploy_groups:
  - sshusers

Unix-Gruppen, die der Anwendungsbenutzer haben sollte:

users_app_groups:
  - sshusers

Benutzer löschen

Diese Rolle definiert Benutzer, die sie mit "ansible-" im Kommentar erstellt. Das ermöglicht es, zu verfolgen, wann Benutzer zu den Listen hinzugefügt oder entfernt werden und die Konten zu löschen.

Sie können auch Konten in der Liste users_delete_users angeben, und sie werden gelöscht. Dies ist nützlich, um veraltete Konten zu bereinigen.

Sie können steuern, ob das Home-Verzeichnis des Benutzers beim Löschen des Kontos gelöscht wird, mit den Variablen users_delete_remove und users_delete_force. Weitere Informationen finden Sie in der Ansible-Dokumentation. Aus Sicherheitsgründen sind diese Variablen standardmäßig auf nein, aber wenn Sie die Systembenutzer mit dieser Rolle verwalten, möchten Sie sie wahrscheinlich auf ja setzen.

users_delete_remove: yes
users_delete_force: yes

Die Rolle kann optional autorisierte Schlüssel von Systembenutzern wie 'root' oder 'ubuntu' entfernen. Dies ist aus Sicherheitsgründen nützlich, um Backup-Root-Schlüssel zu vermeiden, sobald Sie benannte Administratorbenutzer eingerichtet haben.

users_remove_system_authorized_keys: true

Einrichtung

Die normale Vorgehensweise besteht darin, diese Rolle als erstes auf einer neuen Instanz auszuführen. Dadurch werden Administratorbenutzer erstellt und ihre Schlüssel eingerichtet, damit sie die anderen Rollen ausführen können, die den Server konfigurieren. Eine projektbezogene Rolle ist dafür verantwortlich, den Server für die App vorzubereiten, z. B. Verzeichnisse zu erstellen und Abhängigkeiten zu installieren. Wir stellen die App normalerweise von einem Build- oder CI-Server ohne Sudo unter Verwendung des Bereitstellungsbenutzerkontos bereit.

Hier ist ein typisches Playbook:

- name: Benutzer verwalten
  hosts: '*'
  vars:
    users_app_user: foo
    users_app_group: foo
    users_deploy_user: deploy
    users_deploy_group: deploy
    users_users:
      - user: jake
        name: "Jake Morrison"
        github: reachfh
    users_app_users:
      - jake
    users_deploy_users:
      - jake
  roles:
    - { role: cogini.users, become: true }

Fügen Sie den Host zur Datei inventory/hosts hinzu.

[web-servers]
web-server-01

Fügen Sie den Host zur .ssh/config oder eine projektspezifische ssh.config-Datei hinzu.

Host web-server-01
    HostName 123.45.67.89

Auf einem physischen Server, wo wir mit einem Root-Konto ohne SSH-Schlüssel beginnen, müssen wir den Server beim ersten Mal einrichten, indem wir das Passwort mit -k angeben.

ansible-playbook -k -u root -v -l web-server-01 playbooks/manage-users.yml --extra-vars "ansible_host=123.45.67.89"

Unter macOS erfordert der -k-Befehl das askpass-Utility, das standardmäßig nicht installiert ist, sodass es auf Paramiko zurückfällt, das .ssh/config nicht versteht. Daher geben wir ansible_host manuell an.

Bei nachfolgenden Ausführungen, nachdem die Administratorbenutzer eingerichtet sind, verwenden Sie:

ansible-playbook -u $USER -v -l web-server-01 playbooks/manage-users.yml

Veraltete Benutzer löschen

Definieren Sie veraltete Benutzerkonten, die gelöscht werden sollen, in der Liste users_delete_users, z. B.:

ansible-playbook -u $USER -v -l web-servers playbooks/manage-users.yml --extra-vars "users_delete_users=[fred] users_delete_remove=yes users_delete_force=yes"