Comme je le disais c'est très spécifique à mon client donc impossible à partager.
Dans l'idée on fait :
- installation de linux en auto (maintenant directement sur le cloud AWS, c'est ultra facile)
- durcissement de l'os (users, droits, sudo, installation/désinstallation de packages et de kernels, conf ssh ...) avec les reboots qui vont bien
- durcissement apache si besoin (droits, modules, ...)
- durcissement tomcat si besoin (tout pareil...)
Et au final on génère automatiquement un nouvelle image AMI sur Amazon et toutes les stacks applicatives sont configurées pour utiliser la nouvelle image.
Ça dépend aussi bien des règles à mettre en place que de l'OS et des applications utilisées (nous on fait uniquement du RHEL7, et pas Ubuntu ou Windows par exemple).
Globalement c'est à base de modules standards Ansible : lineinfile, file, ... et les modules spécifiques aux manipulations sur AWS.
AWS nous permettant de provisionner une VM à la demande uniquement pour ces opérations (setup, durcissement, tests, création de l'image). Elle est détruite une fois le processus fini.
Désormais, pour toute nouvelle règle de durcissement ou nouveau patch de sécurité à appliquer, on met à jour le playbook Ansible et on lance son exécution. Ça génère la nouvelle image et la met à disposition pour les nouvelles instances.
Il ne nous reste pour le moment plus qu'à automatiser (via un système de promotion automatique ?) les règles de redémarrage progressif des instances existantes sur la nouvelle image.
Pour ça on va devoir gérer les pools des loadbalancers pour que ça se fasse tout seul progressivement sans impacter le service rendu.
La seule difficulté ne vient pas du durcissement, mais de la mise à dispo de la nouvelle image et sa propagation dans l'"Organisation" (au sens AWS).
Message édité par nex84 le 20-02-2018 à 09:23:38
---------------
#TeamNoBidouille || Come to the Dark Side, we have cookies || Mangez 5 fruits et légumes par an ! || Le digital, c'est les doigts