Est-il dangereux d'avoir un utilisateur ansible avec sudo sans mot de passe?

Je suis nouveau à Ansible. La plupart des guides d'approvisionnement VPS que j'ai vus jusqu'à présent font ceci:

désactiver la connexion de root
créer un nouvel utilisateur qui ne peut se connecter qu'avec ssh(pas un mot de passe)
ajouter le nouvel utilisateur au wheelgroupe, avec l' autorisation sudo sans mot de passe

Je comprends (1) et (2), mais pas (3).

Sûrement sans mot de passe, sudoc'est comme se connecter en tant que root? Je comprends l'avantage (commodité), mais n'est-ce pas très précaire?

Je me rends compte que les administrateurs gèrent leurs réseaux de différentes manières, et cela pourrait donc être considéré comme "subjectif", mais c'est une pratique TRÈS courante, elle est même montrée dans divers documents officiels ansibles ainsi que dans des guides publiés par les sociétés d'hébergement. Cela va à l'encontre du bon sens. Quelle est la logique derrière cela?

— lonix
source

Ansible est destiné à automatiser les tâches administratives, il a donc généralement besoin d'un accès de niveau supérieur (racine), d'où "sudo sans mot de passe". Si vous n'en avez besoin que pour exécuter un sous-ensemble des commandes disponibles sur votre système, vous pouvez le verrouiller uniquement pour ces commandes avec une configuration sudo plus détaillée. Le sudo sans mot de passe ne signifie pas nécessairement l'accès à tout root peut faire (bien que cela devienne difficile à appliquer lorsque vous réalisez que l'utilisateur peut potentiellement modifier votre configuration sudo via sudo pour se donner un meilleur contrôle ...).

— David Spillett

@DavidSpillett Je me posais des questions à ce sujet - c'est-à-dire définir les commandes sudo à autoriser dans le fichier sudoers ... mais j'ai lu quelque part qu'ansible fait tout en interprétant via des commandes python complexes, et que cette approche deviendrait rapidement compliquée.

— lonix

Réponses:

Si le compte de service peut exécuter sudo sans mot de passe, vous devez protéger l'accès à ce compte.

Le fait de ne pas avoir de mot de passe pour le compte et d'utiliser uniquement des clés ssh pour s'y connecter, permet de le faire, à condition que vous puissiez également garder la clé privée ssh en sécurité.

— Michael Hampton
source

J'ai donc "en quelque sorte" raison de me sentir perturbé par cette convention - et pourtant, c'est la convention pour ansible, par nécessité / pragmatisme.

— lonix

Vous dites donc que je "déplace" essentiellement la sécurité de base du VPS vers mon système local, qui contient la clé ssh du compte ansible? Dans ce cas, le point faible n'est pas le VPS lui-même, c'est plutôt moi! Et je dois être extrêmement vigilant dans la protection de cette clé ssh, en échange de la commodité que l'automatisation ansible me donne.

— lonix

La clé ssh, mot de passe protégé avec ssh-agent, est une bonne information d'identification.

— John Mahowald

@lonix Tous les systèmes sécurisés ont besoin d'informations d'identification. Les systèmes sécurisés sont au moins aussi sûrs que les mesures que vous mettez en sécurisant ces informations d'identification, car les avoir donne un accès à 100%. Alors oui, vous ne pouvez pas vous attendre à sécuriser votre VPS si vous ne sécurisez pas correctement votre clé SSH (ou votre mot de passe root ou autre). Le fait que vous configuriez sudo sans mot de passe ne signifie rien de ce point de vue, l'activation de sudo avec mot de passe ne change pas le fait qu'il est essentiel de sécuriser la clé SSH.

— Giacomo Alzetta

@GiacomoAlzetta Je sais que, ce que je voulais dire ci-dessus, c'est que la responsabilité est transférée de la machine distante à la machine locale. Comme l'escalade sudo se fait sans mot de passe, le point faible devient local.

— lonix

Le nouvel utilisateur créé en (2) ne peut se connecter qu'avec la clé SSH, pas de mot de passe. La clé SSH donne un accès root indirect. Cela revient donc à autoriser simplement la connexion root avec une clé.

Le compte n'ayant pas de mot de passe, il n'est pas possible d'avoir sudodemandé un mot de passe. Ansible doit également pouvoir exécuter des commandes. Avoir un mot de passe supplémentaire à fournir au même endroit que la clé n'augmenterait pas la sécurité.

— RalfFriedl
source

Le problème est qu'ansible est destiné aux administrateurs et à l'automatisation, donc si vous avez besoin d'entrer un mot de passe pour exécuter un script, ce n'est pas vraiment la meilleure façon. De plus, il n'est pas sûr de stocker le mot de passe de sudo dans un fichier ou une base de données et de l'obtenir à chaque fois qu'il exécute le playbook. Ainsi, la combinaison de sudo sans mot de passe et de l'authentification avec les clés ssh est la meilleure méthode pour garantir la sécurité et aucun problème correct en exécutant le playbook. Vous êtes également administrateur et savez ce que vous programmez dans le playbook. Le playbook ne peut donc pas détruire vos serveurs.

— NicoKlaus
source

Les playbooks peuvent détruire vos systèmes, mais si vous utilisez uniquement des clés d'environnement de test distinctes, cela ne détruira pas les hôtes de production.

— John Mahowald

Exactement, c'est, espérons-le, une condition préalable lorsque vous travaillez sur des systèmes productifs.

— NicoKlaus

Ansible a 'ansible-vault' et des plugins / modules / bibliothèques qui permettent de stocker des secrets dans de nombreux systèmes de stockage de secrets tiers comme bitwarden, hashicorp vault, keepass, etc.

— Zoredache