Est-il mauvais d'utiliser sudo de Jenkins?

J'utilise le plugin Publish Over SSH pour déployer mes applications depuis Jenkinsdifférents environnements. Certains travaux de déploiement effectuent des préparations d'environnement et des choses comme arrêter et redémarrer le service système du serveur d'applications. Certaines de ces commandes nécessitent sudo.

Je suis simplement curieux de savoir si cela peut être une mauvaise pratique de sécurité d'exiger sudo dans les travaux Jenkins de publication et d'exécution à distance. Devrions-nous changer la politique de sécurité sur l'hôte cible pour permettre aux fonctions requises d'être exécutées sans sudo?

Non, c'est vraiment une bonne pratique de sécurité de sudo lorsque vous avez besoin de privilèges de niveau supérieur. C'est la raison pour laquelle la plupart des distributions interdisent la connexion par défaut et vous obligent à le faire au sudo sulieu de simplement taper su- elles veulent vous encourager à utiliser sudo pour ses avantages de sécurité. Il y a peu de raisons pour lesquelles:

• Audit. Lorsque vous faites un sudo, le système garde une trace de qui a fait le sudo et de la commande exécutée. Cela ajoute beaucoup à la criminalistique lorsque vous devez revenir en arrière et comprendre ce qui s'est passé - pour attribuer le blâme, attraper des activités néfastes ou simplement à des fins de dépannage (que s'est-il passé hier soir à 19 heures avant que ce serveur ne devienne AWOL?)

• Règles de Sudo. Ce n'est pas parce qu'un utilisateur doit exécuter quelque chose avec des privilèges escaladés qu'il doit tout exécuter avec des privilèges escaladés. Utiliser su ou ajouter un utilisateur à wheel permet à un utilisateur de tout faire . Avec sudo cependant, il est possible de spécifier ce que les utilisateurs peuvent et ne peuvent pas faire en utilisant des alias de commande qui permettent l'utilisation de caractères génériques, permettant ainsi des règles flexibles qui accordent aux utilisateurs des privilèges pour utiliser certaines commandes, mais pas d'autres.

• Durcissement. Il est possible de désactiver root. Comme dans, à toutes fins utiles, il n'existe pas et n'est utile / utilisable qu'en mode mono-utilisateur - nécessitant un redémarrage d'un serveur (et la seule raison pour laquelle cela est autorisé est pour la récupération de mot de passe). sudo sune fonctionne plus. Pour ce faire, définissez le shell de root sur / bin / nologin. ce qui est un excellent moyen de prévenir de nombreuses vulnérabilités d'escalade de racine. Cela suppose bien sûr que vous utilisez correctement la puce ci-dessus (et vous pouvez toujours accorder à un utilisateur administrateur spécifique toutes les autorisations, bien que cela nuise à votre position en matière de sécurité).

Ces éléments ne sont bien sûr qu'une partie de votre modèle de sécurité. Par exemple, à moins que vous n'ayez aucun utilisateur avec des privilèges administratifs complets (et parfois même alors), votre utilisateur peut être en mesure (probablement) de supprimer les journaux et l'historique - à moins que vous n'utilisiez un serveur de journaux et syslog pour expédier les journaux hors boîte. Il n'y a alors aucun moyen de remettre ce chat dans le sac. Bien sûr, si vous utilisez une structure de répertoire d'authentification centrale, cela revient en jeu: si je compromets un compte, il est compromis sur tous les serveurs de l'organisation - y compris probablement votre serveur de journaux.

En bref, la sécurité est compliquée, mais sudo est un excellent outil pour l'architecture d'un environnement sécurisé et plus de gens devraient l'utiliser dans toute sa mesure.

Que vous autorisiez sudoun accès à distance ou à distance à quelque chose, SUID rootvotre surface d'attaque est assez similaire. Je garderais sudodans la chaîne car cela vous permet de limiter facilement les commandes et a une journalisation qui sera vitale si vous devez auditer les choses plus tard. sudoa également une histoire de production beaucoup plus longue. Faire autre chose aura moins d'histoire et plus de changements de surprises désagréables.

Il y a d'autres choses que vous pouvez faire pour rendre cela plus sûr:

• serrer ssh
• n'autoriser les commandes de redémarrage que pour quelques utilisateurs spécifiques, dont un pour jenkins
• autoriser uniquement les connexions pour ces utilisateurs spécifiques à partir de toutes les adresses IP internes ou simplement de jenkins et de boîtes de saut IP
• stocker les journaux sur des boîtes distantes afin qu'ils ne puissent pas être détruits avec