cogini.users

Utilisateurs

Ce rôle Ansible gère les comptes utilisateurs et contrôle l'accès à ceux-ci avec des clés SSH.

Il est utilisé pour déployer une ou plusieurs applications sur un serveur. Il prend en charge la création de comptes utilisés pour déployer et exécuter l'application, ainsi que des comptes pour les administrateurs système et les développeurs.

C'est essentiellement un cadre préconfiguré sur le module utilisateur Ansible.

Types d'utilisateurs

Le rôle prend en charge la création des types de comptes utilisateurs suivants :

Administrateurs système globaux / équipe des opérations

Ces utilisateurs ont leurs propres connexions sur le serveur avec des permissions sudo. Nous les ajoutons au groupe wheel ou admin, puis leur permettons de lancer sudo sans mot de passe.

Lors de la configuration d'un serveur, nous créons automatiquement des comptes pour notre équipe d'administrateurs système, indépendamment du projet.

Administrateurs de projet / utilisateurs avancés

Ces utilisateurs ont les mêmes droits que les administrateurs globaux, mais sont configurés sur une base par projet ou par serveur, contrôlés avec les variables d'hôte/groupe d'inventaire. Normalement, le responsable technique du projet serait un administrateur.

Compte de déploiement

Ce compte utilisateur est utilisé pour déployer l'application sur le serveur. Il possède les fichiers logiciels de l'application et a des permissions d'écriture dans les répertoires de déploiement et de configuration.

Les comptes d'application et de déploiement n'ont pas de permissions sudo, bien que nous puissions créer une règle dans /etc/sudoers.d/ pour leur permettre d'exécuter des commandes comme redémarrer l'application via systemctl. Cela est géré par le rôle qui installe et configure l'application, pas par ce rôle.

Par exemple, créez un fichier comme /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

Compte d'application

L'application s'exécute sous ce compte utilisateur.

Ce compte a un accès en écriture aux répertoires dont il a besoin à l'exécution, par exemple pour les journaux, et a un accès en lecture seule à son code et à ses fichiers de configuration.

Développeurs

Les développeurs peuvent avoir besoin d'accéder au compte de déploiement ou au compte d'application pour consulter les journaux et le déboguer. Nous ajoutons les clés SSH des développeurs aux comptes, leur permettant de se connecter via SSH.

Utilisateurs de projet

Ces utilisateurs sont comme des administrateurs, mais n'ont pas de sudo. Un exemple pourrait être un compte pour un client afin de pouvoir se connecter et exécuter des requêtes contre la base de données, mais sans droits d'administrateur. Vous pouvez leur donner des permissions pour accéder, par exemple, aux fichiers journaux de l'application en les ajoutant au groupe de l'application et en définissant les permissions des fichiers.

Configuration

Par défaut, ce rôle ne fait rien. Vous devez ajouter des variables de configuration pour qu'il fasse quelque chose. Cela se fait normalement via des variables de groupe, par exemple inventory/group_vars/app_servers, une section vars dans un playbook, ou une combinaison.

Vous pouvez avoir des paramètres différents au niveau d'un hôte ou d'un groupe pour, par exemple, donner aux développeurs un accès de connexion dans l'environnement de développement mais pas en production.

Comptes d'application

Le compte qui déploie l'application. Optionnel, s'il n'est pas spécifié, l'utilisateur de déploiement ne sera pas créé.

users_deploy_user: deploy
users_deploy_group: deploy

Le compte qui exécute l'application. Optionnel, s'il n'est pas spécifié, l'utilisateur de l'application ne sera pas créé.

users_app_user: foo
users_app_group: foo

Comptes utilisateurs

Le users_users définit les noms de comptes Unix et les clés SSH pour les utilisateurs.

C'est une liste de dictionnaires avec quatre champs :

user : Nom du compte Unix
name : Nom de l'utilisateur. Optionnel, pour la documentation.
key : Fichier de clé publique SSH. Mettez-les dans, par exemple, le répertoire files de votre playbook.
github : L'identifiant GitHub de l'utilisateur. Le rôle obtient les clés de l'utilisateur à partir de https://github.com/{{ github }}.keys

Exemple :

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

Listes d'utilisateurs

Après avoir défini les comptes utilisateurs dans users_users, configurez les listes d'utilisateurs, en spécifiant l'identifiant utilisé dans la clé user. Par défaut, ces listes sont vides, donc si vous ne spécifiez pas d'utilisateurs, ils ne seront pas créés.

Utilisateurs administrateurs globaux avec un compte Unix distinct et des permissions sudo.

users_global_admin_users:
 - jake

Utilisateurs administrateurs au niveau du projet avec un compte Unix distinct et des permissions sudo.

users_admin_users:
 - fred

Utilisateurs de projet avec un compte Unix distinct mais sans permission sudo.

users_regular_users:
 - bob

Utilisateurs (clés SSH) qui peuvent accéder au compte de déploiement.

users_deploy_users:
 - ci

Utilisateurs (clés SSH) qui peuvent accéder au compte de l'application.

users_app_users:
 - fred

Configuration de groupe

Vous pouvez spécifier des groupes supplémentaires auxquels les différents types d'utilisateurs auront accès. Par défaut, ces listes sont vides, mais vous pouvez les utiliser pour affiner l'accès à l'application.

Nous configurons normalement SSH de sorte qu'un compte utilisateur doive être membre d'un groupe sshusers, sinon SSH n'autorisera personne à se connecter.

Ajoutez ceci à /etc/ssh/sshd_config

AllowGroups sshusers sftpusers

Puis ajoutez sshusers à users_admin_groups, par exemple :

users_admin_groups:
  - sshusers

Groupes Unix que les utilisateurs administrateurs devraient avoir.

Le rôle sera toujours ajouté au groupe wheel ou admin, selon la plateforme. S'il y a des utilisateurs administrateurs définis, ce rôle configure sudo avec un fichier /etc/sudoers.d/00-admin afin que les utilisateurs administrateurs puissent exécuter sudo sans mot de passe.

users_admin_groups:
  - sshusers

Groupes Unix que les utilisateurs réguliers devraient avoir :

users_regular_groups:
  - sshusers

Groupes Unix que l'utilisateur de déploiement devrait avoir :

users_deploy_groups:
  - sshusers

Groupes Unix que l'utilisateur de l'application devrait avoir :

users_app_groups:
  - sshusers

Suppression d'utilisateurs

Ce rôle définit les utilisateurs qu'il crée avec "ansible-" dans le commentaire. Cela lui permet de suivre lorsque des utilisateurs sont ajoutés ou supprimés des listes et de supprimer les comptes.

Vous pouvez également spécifier des comptes dans la liste users_delete_users et ils seront supprimés. C'est utile pour nettoyer les comptes anciens.

Vous pouvez contrôler si vous souhaitez supprimer le répertoire personnel de l'utilisateur lors de la suppression du compte avec les variables users_delete_remove et users_delete_force. Consultez la documentation d'Ansible pour plus de détails. Pour plus de sécurité, ces variables sont réglées sur non par défaut, mais si vous gérez les utilisateurs système avec ce rôle, vous souhaiterez probablement les definir sur oui.

users_delete_remove: oui
users_delete_force: oui

Le rôle peut également supprimer des clés autorisées d'utilisateurs système comme 'root' ou 'ubuntu'. Cela est utile pour la sécurité afin d'éviter les clés de sauvegarde root, une fois que vous avez configuré des utilisateurs administrateurs nommés.

users_remove_system_authorized_keys: vrai

Configuration

La séquence normale consiste à exécuter ce rôle en premier sur une nouvelle instance. Cela crée des utilisateurs administrateurs et configure leurs clés pour qu'ils puissent exécuter les autres rôles qui configurent le serveur. Un rôle spécifique à un projet est responsable de la préparation du serveur pour l'application, par exemple en créant des répertoires et en installant des dépendances. Nous déployons normalement l'application depuis un serveur de construction ou CI, sans sudo, en utilisant le compte d'utilisateur de déploiement.

Voici un playbook typique :

- name: Gérer les utilisateurs
  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 }

Ajoutez l'hôte au fichier inventory/hosts.

[serveurs-web]
serveur-web-01

Ajoutez l'hôte à .ssh/config ou un fichier ssh.config spécifique au projet.

Host serveur-web-01
    HostName 123.45.67.89

Sur un serveur physique où nous commençons avec un compte root et sans clés SSH, nous devons d'abord bootstrap le serveur la première fois, en spécifiant le mot de passe avec -k.

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

Sur macOS, la commande -k nécessite l'utilitaire askpass, qui n'est pas installé par défaut, donc elle utilise paramiko, qui ne comprend pas .ssh/config, donc nous spécifions ansible_host manuellement.

Lors des exécutions suivantes, après que les utilisateurs administrateurs soient configurés, utilisez :

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

Suppression d'utilisateurs anciens

Définissez les comptes utilisateurs anciens à supprimer dans la liste users_delete_users, par exemple :

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