Durcissez vos rôles Ansible avec OpenScap
Cet article est la suite de celui consacrer à la maintenance des collections et des rôles Ansible avec Renovate. Aujourd’hui, nous allons voir comment durcir vos rôles avec l’aide d’OpenScap.
Si on analyse les rôles présents sur Ansible Galaxy, c’est assez rare de
trouver des rôles permettant de configurer des services, des middlewares qui
intègrent les quelques bonnes pratiques de sécurité. Et c’est bien dommage. La
sécurisation de nos assets
devraient la priorité de Tous !
Pour vous aider à réaliser cette tâche, j’ai écrit un simple rôle Ansible chargé
d’installer et de lancer un scan de sécurité avec OpenScap. OpenScap est
un produit RedHat Open-Source qui propose des outils d’audits permettant de
sécuriser vos assets
.
Ecriture du role d’installation d’OpenScap
OpenScap est normalement fourni sous forme de packages, mais pour les dernières versions de certaines Distributions Linux (comme les debian) ce n’est pas le cas. Et plutôt que d’installer le package, nous allons tout simplement builder le produit à partir de son code source. Comme cela nous profiterons de la dernière version stable.
Le code de ce rôle est disponible sur mon compte GitHub ↗.
Comme pour tous mes rôles, j’utilise Molecule
pour la partie tests. Là ce role
n’en intègre pas pour le moment de tests, mais il utilise cette fois non pas le
driver docker
, mais celui de vagrant
. En effet, j’ai constaté que dans
certains cas les images Docker officiels n’intégraient pas forcément les mêmes
packages et les mêmes configurations que ceux que l’on rencontre dans une
installation classique avec une image ISO.
Installation et utilisation du driver molecule-vagrant
Pour installer le driver vagrant
c’est assez simple via la commande pip :
Pour créer le scénario utiliser ce driver, il faut ensuite utiliser cette commande :
Ensuite dans le fichier molecule.yml
de ce scenario
il faut utiliser cette
configuration de plateforme :
Pour le moment, je ne travaille que des distributions Debian, mais dans les
prochaines versions de ce role, j’ajouterai le support de plusieurs distributions
via un système de variables. Si vous voulez l’utiliser pour d’autres, il faut
simplement changer le paramètre box
.
Quelques explications sur le role
Les tâches principales sont les suivantes :
Vous voyez ! Rien de bien compliqué. Pour ajouter une distribution, il faut dupliquer une existante, ubuntu22.yml par exemple et éditer son contenu pour qu’il installe les dépendances de compilation. La liste des packages se trouve dans le dépôt officiel d’OpenScap ↗.
Ah oui le plus important, pour le moment, j’ai codé en dure les paramètres du
choix du profil et la security policy
pour chaque distribs.
Pour retrouver le profile qui est fonction du profil de la distribution :
Pour lancer les commandes, comme le converge d’un autre scenario, il faut
ajouter son nom derrière l’option --scenario-name
. Ce qui donne :
Utilisation du role OpenScap dans notre collection de base
Comme dit plus haut, je reprends la suite du précédent article sur la construction d’une collection de base.
Je modifie simplement le fichier requirements.yml
pour intégrer mon rôle OpenScap :
J’ajoute un playbook
permettant l’installation d’OpenScap :
A l’installation d’OpenScap et des contents (sa configuration), je demande à lancer un scan.
Allez, on lance notre converge :
Au de quelques instants, vous devriez voir apparaître un fichier nommé
report-debian-11.html
(j’utilise cette fois une box Debian) dans le dossier
playbooks.
Pour afficher ce rapport dans Vscode j’utilise l’extension Live Preview ↗.
Il suffit de faire un clic droit dans l’explorateur de Vscode sur le nom de ce fichier et de sélectionner le menu [Afficher l’aperçu].
Sécurisation du service SSHD
Pour mon exemple, je vais sécuriser le service sshd
. Si vous descendez dans ce
fichier, vous devriez voir une zone de recherche dans lequel vous pouvez taper
ssh
.
On voit que nous avons cinq règles qui ne sont pas respectées. Comment les sécuriser ? Très simple. Cliquez sur [Show all results Details] puis sur le titre de la règle en échec que vous voulez résoudre. Cliquez sur [Remediation Ansible snippet].
Oh la solution toute prête. Plus qu’à l’intégrer dans votre rôle. Pour tester la
remédiation sur la collection, il suffit d’ajouter une tache dans le fichier
converge.yml
avant le scan. Ce qui donne :
On copie le contenu de la remédiation dans le fichier playbooks/securing.yml
:
On relance le converge et on check le rapport. Et ????
YOUPPPPPIIIIII !!!
Plus loin
Bon ce n’est pas encore parfait, mais les grands principes sont là. Par exemple
le role openscap
pourrait être optimisé pour éviter de réinstaller les
contents d’OpenScap. Il pourrait aussi compiler les packages RPM et DEB. Je n’ai
pas pris le temps, car j’étais pressé de vous présenter ce tutoriel. Ça sera
fait dans les prochains temps. Donc il y a encore du taf.
Openscap possède une commande oscap-ssh
qui permet de lancer le scan sur des
machines distantes. Les seules contraintes openscap doit être installé sur les
machines et le content sur le manager ansible. On peut produire des fichiers
xml
(peut être json
) qui sont exploitables pour faire des audits de contrôle.
Je regarde comment lancer les rapports oval
pour lister les cve
et je mets
le billet à jour. Je recherche d’autres outils d’audits open-source à intégrer.
Pour ceux que ça intéresse la documentation complète se trouve
ici ↗.
Je vais aussi changer le driver utilisé dans la CI pour poper des VM sur AWS. C’est plus simple à mettre en œuvre et on a à disposition la plupart des distributions via les AMI.
Le code source du rôle est ici ↗. N’hésitez à forker voir à déposer des PR.