MindPointGroup.amazon2_cis
Amazon 2 Linux
Configurer une machine Amazon Linux 2 pour être conforme au CIS Non testé sur OEL
Basé sur CIS Amazon Linux 2 Benchmark v3.0.0 - 22-12-2023
Rejoignez-nous
Sur notre Serveur Discord pour poser des questions, discuter des fonctionnalités ou simplement discuter avec d'autres utilisateurs d'Ansible-Lockdown.
Précautions
Ce rôle fera des modifications au système qui peuvent avoir des conséquences imprévues. Ce n'est pas un outil d'audit mais plutôt un outil de remédiation à utiliser après qu'un audit a été effectué.
Le mode de vérification n'est pas pris en charge ! Le rôle se terminera en mode vérification sans erreurs, mais il n'est pas pris en charge et doit être utilisé avec précaution. Le rôle AMAZON2-CIS-Audit ou un scanner de conformité devrait être utilisé pour le contrôle de conformité au lieu du mode vérification.
Ce rôle a été développé sur une installation propre du système d'exploitation. Si vous l'appliquez à un système existant, veuillez examiner ce rôle pour tout changement spécifique au site qui pourrait être nécessaire.
Pour utiliser la version de release, veuillez vous diriger vers la branche principale et la release pertinente pour le benchmark cis auquel vous souhaitez travailler.
Provenant d'une version précédente
Une release CIS contient toujours des changements, il est fortement recommandé de revoir les nouvelles références et variables disponibles. Celles-ci ont changé considérablement depuis la release initiale d'ansible-lockdown. Cela est maintenant compatible avec python3 s'il est trouvé comme l'interpréteur par défaut. Cela vient avec des prérequis qui configurent le système en conséquence.
Des détails supplémentaires peuvent être trouvés dans le Changelog
Documentation
- Commencer
- Personnalisation des Rôles
- Configuration par Hôte
- Tirer le Meilleur Parti du Rôle
- Wiki
- Page GitHub du Repo
Exigences
Général :
Connaissances de base d'Ansible, voici quelques liens vers la documentation d'Ansible pour vous aider à démarrer si vous n'êtes pas familier avec Ansible
Ansible et/ou Tower fonctionnels installés, configurés et en cours d'exécution. Cela inclut toutes les configurations de base d'Ansible/Tower, les packages nécessaires installés et l'infrastructure mise en place.
Veuillez lire les tâches dans ce rôle pour comprendre ce que chaque contrôle fait. Certaines des tâches sont perturbatrices et peuvent avoir des conséquences imprévues dans un système de production en direct. Familiarisez-vous également avec les variables dans le fichier defaults/main.yml ou la Page Wiki des Variables Principales.
Dépendances Techniques :
- Configuration d'exécution d'Ansible/Tower (ce rôle est testé avec Ansible version 2.11.1 et plus)
- Environnement d'exécution Ansible Python3
- python-def - La première tâche configure les prérequis (Tag pre-reqs) pour python3 et python2 (là où c'est nécessaire)
- libselinux-python
- python3-rpm (package utilisé par py3 pour utiliser le paquet rpm)
- jmespath
Variables de Rôle
Ce rôle est conçu de manière à ce que l'utilisateur final n'ait pas à modifier les tâches lui-même. Toute personnalisation doit se faire via le fichier defaults/main.yml ou avec des variables supplémentaires dans le projet, le job, le workflow, etc. Ces variables peuvent être trouvées ici dans la page Wiki des Variables Principales. Toutes les variables y sont listées avec des descriptions.
Tags
Il existe de nombreux tags disponibles pour un contrôle plus précis. Chaque contrôle a son propre ensemble de tags indiquant quel niveau, s'il est noté/non noté, quel élément du système d'exploitation il concerne, s'il s'agit d'un correctif ou d'un audit, et le numéro de règle.
Voici un exemple de section de tags d'un contrôle dans ce rôle. En utilisant cet exemple, si vous définissez votre exécution pour ignorer tous les contrôles avec le tag services, cette tâche sera ignorée. L'inverse peut également se produire où vous exécutez uniquement les contrôles étiquetés avec services.
tags:
- level1
- scored
- avahi
- services
- patch
- rule_2.2.4
Branches
- devel - C'est la branche par défaut et la branche de développement active. Les demandes de tirage de la communauté seront tirées dans cette branche.
- main - C'est la branche de release.
- toutes les autres branches - Branches individuelles des membres de la communauté.
Contribution de la Communauté
Nous encourageons les contributions de la communauté à ce rôle. Veuillez lire les règles ci-dessous.
- Votre travail se fait dans votre propre branche individuelle. Assurez-vous de signer et de signer tous les commits que vous souhaitez fusionner avec GPG.
- Toutes les demandes de tirage de la communauté sont tirées dans la branche de développement.
- Les demandes de tirage dans le développement confirmeront que vos commits ont une signature GPG, qu'ils sont signés et qu'un test fonctionnel a été effectué avant d'être approuvés.
- Une fois vos changements fusionnés et un examen plus détaillé terminé, un membre autorisé fusionnera vos changements dans la branche principale pour une nouvelle release.
Test de Pipeline
utilise :
- ansible-core 2.12+
- collections Ansible - tire la dernière version en fonction du fichier de requirements
- exécute l'audit en utilisant la branche de développement
- Il s'agit d'un test automatisé qui se produit lors des demandes de tirage dans le développement
Support
Il s'agit essentiellement d'un projet communautaire et sera géré en tant que tel.
Si vous êtes intéressé par un support dédié pour aider ou fournir des configurations sur mesure
Crédits et Remerciements
Un grand merci à la fantastique communauté et à tous ses membres.
Apply the Amazon Linux 2 CIS controls
ansible-galaxy install MindPointGroup.amazon2_cis