📘 Documentation technique – Infrastructure Ansible moderne¶

1. Objectif du document¶

Ce document décrit la mise en place d’une infrastructure Ansible moderne, sécurisée et maintenable, utilisée pour :

• l’administration système Linux (Debian / Ubuntu / RHEL-like)
• la gestion de la sécurité (Fail2ban)
• la découverte automatique de l’infrastructure via vCenter OVH
• la génération d’une cartographie dynamique des machines virtuelles
• la préparation à une migration progressive vers CrowdSec

---

2. Périmètre couvert¶

Inclus¶

• Ansible Core 2.20+
• Inventaires statiques (infra)
• Inventaire dynamique vCenter (OVH)
• Rôle Fail2ban
• Gestion des secrets avec Ansible Vault
• Python virtual environment dédié

Exclusions volontaires¶

• Certains serveurs legacy (ex : SIPO)

Raisons : Python < 3.9, dépendances sensibles, risques de régression
Toute intervention y est réalisée manuellement

---

3. Architecture générale¶

3.1 Principe directeur¶

Séparation stricte des responsabilités

• code Ansible ≠ secrets
• inventaires ≠ rôles
• legacy ≠ production
• statique ≠ dynamique

---

4. Arborescence finale¶

/etc/ansible/
├── ansible.cfg
├── inventories/
│   ├── infra/
│   │   └── hosts.yml
│   └── vcenter/
│       ├── vmware.yml
│       └── vault/
│           └── vcenter.yml
├── playbooks/
│   └── fail2ban.yml
├── roles/
│   └── fail2ban/
│       ├── tasks/
│       ├── handlers/
│       ├── templates/
│       └── defaults/
├── legacy/
│   └── (anciens playbooks – lecture seule)
└── README.md

---

5. Environnement d’exécution Ansible¶

5.1 Python Virtual Environment¶

Ansible s’exécute dans un venv dédié, garantissant l’isolation des dépendances.

python3 -m venv /opt/ansible-venv
source /opt/ansible-venv/bin/activate
pip install ansible pyvmomi requests

Vérification :

ansible --version
python -c "import pyVmomi; print('pyvmomi OK')"

---

6. Configuration Ansible globale¶

/etc/ansible/ansible.cfg¶

[defaults]
inventory = /etc/ansible/inventories
host_key_checking = False
deprecation_warnings = False
retry_files_enabled = False

[inventory]
enable_plugins = host_list, script, auto, yaml, ini, community.vmware.vmware_vm_inventory

---

7. Inventaire statique – Infrastructure interne¶

/etc/ansible/inventories/infra/hosts.yml¶

Usage :

• serveurs critiques
• machines administrées manuellement
• exclusions du vCenter

Exemple :

all:
  children:
    infra:
      hosts:
        kevazingo:
          ansible_host: 172.23.2.45
        zammad:
          ansible_host: 172.23.2.102
        pommier:
          ansible_host: 172.23.1.5

Test de connectivité¶

ansible -i inventories/infra/hosts.yml infra -m ping

---

8. Inventaire dynamique vCenter (OVH)¶

8.1 Objectif¶

• découverte automatique des VMs
• regroupement par OS, état, tags
• base de cartographie infra

---

8.2 Secrets vCenter (Vault)¶

Création¶

ansible-vault create /etc/ansible/inventories/vcenter/vault/vcenter.yml

Contenu :

vault_vcenter_password: "********"

---

8.3 Configuration inventory vCenter¶

/etc/ansible/inventories/vcenter/vmware.yml¶

plugin: community.vmware.vmware_vm_inventory

hostname: pcc-51-210-115-58.ovh.com
username: patrick
password: "{{ vault_vcenter_password }}"
validate_certs: false

properties:
  - config.name
  - guest.ipAddress
  - guest.guestFullName
  - runtime.powerState

hostnames:
  - config.name

compose:
  ansible_host: guest.ipAddress
  ansible_connection: "'ssh'"
  ansible_user: "'ansible'"

keyed_groups:
  - key: guest.guestFullName
    prefix: os
    separator: "_"

  - key: runtime.powerState
    prefix: state

filters:
  - runtime.powerState == "poweredOn"

---

8.4 Test inventaire dynamique¶

ansible-inventory \
  -i /etc/ansible/inventories/vcenter/vmware.yml \
  --ask-vault-pass \
  --graph

👉 Résultat :

• groupes dynamiques par OS
• groupes par état (poweredOn)
• inventaire auto à jour

---

9. Cartographie infrastructure automatisée¶

Génération lisible¶

ansible-inventory \
  -i inventories/vcenter/vmware.yml \
  --ask-vault-pass \
  --graph > cartographie-infra.txt

Usages¶

• audit infra
• documentation DSI
• analyse d’exposition
• préparation SOC / sécurité

---

10. Rôle Fail2ban (standardisé)¶

10.1 Objectif¶

• homogénéiser la protection SSH
• respecter les différences Debian / RHEL
• ne pas écraser les configs existantes

---

10.2 Template jail.local¶

[DEFAULT]
ignoreip = 127.0.0.1
findtime = 10m
bantime = 24h
maxretry = 3

[sshd]
enabled = true
{% if ansible_os_family == "RedHat" %}
logpath = /var/log/secure
{% else %}
logpath = /var/log/auth.log
{% endif %}
port = ssh
backend = %(sshd_backend)s

---

10.3 Playbook Fail2ban¶

- name: Apply Fail2ban baseline
  hosts: infra
  become: true
  roles:
    - fail2ban

Dry-run obligatoire¶

ansible-playbook \
  -i inventories/infra/hosts.yml \
  playbooks/fail2ban.yml \
  --check

---

11. Gestion du legacy¶

Le dossier legacy/ contient :

• anciens playbooks fonctionnels
• scripts historiques
• références techniques

Ils ne sont plus utilisés en production.
Ils sont conservés uniquement à titre documentaire.

---

12. Décisions techniques clés (justifiées)¶

Décision	Justification
Exclusion de SIPO	Python 3.8, risque applicatif
vCenter dynamique	Réduction de la dette documentaire
Vault séparé	Sécurité & audit
venv Python	Stabilité Ansible
Fail2ban conservé	Transition maîtrisée vers CrowdSec

---

13. Évolutions prévues¶

• migration progressive vers CrowdSec
• tagging vCenter pour ciblage Ansible
• génération automatique de rapports Markdown
• intégration SOC (logs / conformité)

---

14. Conclusion¶

Cette architecture :

• est alignée Ansible moderne
• est audit-ready
• est scalable
• évite le chaos documentaire
• prépare l’avenir sans casser l’existant

---