Transfert sécurisé de fichiers : Utilisation des modules Ansible Copy et Fetch

Transfert de fichiers sécurisé : Utilisation des modules Ansible Copy et Fetch

Ansible est réputé pour ses capacités de gestion de configuration, mais le déplacement efficace de fichiers entre la machine de contrôle et les nœuds gérés est une exigence fondamentale pour toute stratégie de déploiement. Que vous ayez besoin de déployer un fichier de configuration personnalisé, de pousser un artefact de déploiement ou de récupérer des journaux système, le processus doit être rapide, fiable et sécurisé.

Cet article se concentre sur les deux modules principaux pour le transfert de fichiers : copy et fetch. Nous montrerons comment exploiter ces modules en utilisant la puissante structure de commandes ad-hoc d'Ansible, permettant des opérations de fichiers rapides et ponctuelles sans avoir besoin d'écrire un playbook complet. À la fin de ce guide, vous serez en mesure de pousser en toute sécurité des fichiers locaux vers des systèmes distants et de rapatrier les fichiers nécessaires vers votre nœud de contrôle Ansible.

Prérequis

Avant d'exécuter les exemples ci-dessous, assurez-vous de disposer des éléments suivants :

Nœud de contrôle Ansible : Une machine avec Ansible installé.
Fichier d'inventaire : Un fichier d'inventaire opérationnel (par exemple, /etc/ansible/hosts) définissant vos nœuds gérés.
Connectivité : Accès par clé SSH configuré pour vos hôtes distants.

Tous les exemples supposeront que le groupe cible est nommé webservers dans l'inventaire.

Comprendre les commandes ad-hoc pour le transfert de fichiers

Les commandes ad-hoc sont des commandes en une seule ligne exécutées directement depuis le terminal, idéales pour des tâches rapides qui ne justifient pas un playbook permanent. La structure de base est :

ansible <host-group> -m <module-name> -a "key=value key2=value2 ..."

Pour le transfert de fichiers, nous utilisons les noms de modules -m copy ou -m fetch, en passant les arguments requis via l'option -a.

Le module `copy` : Pousser des fichiers vers des nœuds distants

Le module copy est utilisé pour transférer un fichier situé sur la machine de contrôle Ansible vers un ou plusieurs nœuds gérés. C'est la méthode standard pour déployer des fichiers de configuration, des scripts ou de petits actifs.

Arguments clés pour `copy`

Le module copy nécessite deux arguments essentiels et accepte plusieurs arguments optionnels pour la gestion de configuration :

Argument	Description	Requis ?	Valeur d'exemple
`src`	Le chemin absolu du fichier sur la machine de contrôle Ansible.	Oui	`/tmp/config.conf`
`dest`	Le chemin absolu où le fichier sera placé sur le nœud géré distant.	Oui	`/etc/app/config.conf`
`owner`	Nom de l'utilisateur qui doit posséder le fichier sur le nœud distant.	Non	`nginx`
`group`	Nom du groupe qui doit posséder le fichier sur le nœud distant.	Non	`www-data`
`mode`	Permissions (octales) à définir sur le fichier de destination.	Non	`0644`
`backup`	Si `yes`, crée un fichier de sauvegarde avant d'écraser l'original.	Non	`yes`

Exemple 1 : Déploiement de fichier simple

Supposons que vous ayez un fichier Message of the Day (motd) personnalisé localement et que vous souhaitiez le pousser vers tous les serveurs web.

# Chemin du fichier local : /home/user/ansible/motd_banner
# Destination distante : /etc/motd

ansible webservers -m copy -a "src=/home/user/ansible/motd_banner dest=/etc/motd"

Exemple 2 : Définition des permissions et de la propriété

Si vous déployez un fichier de configuration sécurisé, vous devez spécifier le propriétaire, le groupe et des permissions restreintes (par exemple, seul le propriétaire peut lire/écrire).

# Déploiement d'un fichier de configuration d'application, appartenant à 'app_user', groupe 'devops',
# avec des permissions de lecture/écriture uniquement pour le propriétaire (0600).

ansible webservers -m copy -b -a "src=/tmp/app_settings.yaml dest=/etc/app/settings.yaml owner=app_user group=devops mode=0600"

Remarque sur -b : L'option -b (ou --become) est nécessaire lorsque la destination distante requiert des permissions élevées (comme l'écriture dans /etc).

Le module `fetch` : Récupérer des fichiers depuis des nœuds distants

Le module fetch effectue l'opération inverse de copy : il récupère un fichier du nœud géré vers la machine de contrôle Ansible. Ceci est utile pour sauvegarder des fichiers de configuration, récupérer des journaux ou collecter des informations de diagnostic.

Arguments clés pour `fetch`

Le module fetch nécessite le fichier source sur le nœud distant et un répertoire de destination sur la machine de contrôle.

Argument	Description	Requis ?	Valeur d'exemple
`src`	Le chemin absolu du fichier sur le nœud géré distant.	Oui	`/var/log/nginx/error.log`
`dest`	Le chemin absolu du répertoire sur la machine de contrôle où les fichiers seront enregistrés.	Oui	`/tmp/backups/logs`
`flat`	Si `yes`, le nom de fichier résultant ne contiendra pas la structure du nom d'hôte (non recommandé lors de la récupération depuis plusieurs hôtes).	Non	`no` (par défaut)

Différence critique : Structure de destination

Contrairement au module copy, le module fetch crée automatiquement un chemin de sous-répertoire structuré basé sur le nom d'hôte distant pour éviter les conflits de noms de fichiers lors de la récupération de fichiers depuis plusieurs serveurs.

Le chemin résultant sur la machine de contrôle ressemblera à ceci :

<dest>/<hostname>/<src>

Par exemple, la récupération de /etc/nginx/nginx.conf depuis host1 vers /tmp/backups donne :

/tmp/backups/host1/etc/nginx/nginx.conf

Exemple 3 : Récupération des sauvegardes de configuration distantes

Pour récupérer le fichier de configuration en cours d'exécution de tous les serveurs web vers un répertoire de sauvegarde local :

# Récupère nginx.conf de tous les serveurs web vers le répertoire local /tmp/config_backups

ansible webservers -m fetch -a "src=/etc/nginx/nginx.conf dest=/tmp/config_backups"

Après avoir exécuté cette commande, si vous avez ciblé webserver1 et webserver2, la structure de votre répertoire local serait :

/tmp/config_backups/
├── webserver1
│   └── etc
│       └── nginx
│           └── nginx.conf
└── webserver2
    └── etc
        └── nginx
            └── nginx.conf

Exemple 4 : Récupération d'un seul fichier sans structure d'hôte (`flat=yes`)

Si vous êtes absolument certain de ne récupérer un fichier que d'un seul hôte, ou si vous n'avez besoin que du contenu du fichier (pas de la structure d'origine), vous pouvez utiliser flat=yes. Cela a pour effet que le fichier est placé directement dans le dossier de destination, nommé d'après le fichier distant original.

# Récupérer un rapport d'état de santé local depuis un seul hôte, en l'enregistrant directement.

ansible webserver1 -m fetch -a "src=/tmp/health_status.txt dest=/tmp/reports flat=yes"

# Chemin résultant : /tmp/reports/health_status.txt

Attention : N'utilisez flat=yes que lorsque vous ciblez un seul hôte ou si vous avez l'intention d'écraser le fichier lors des exécutions ultérieures, car Ansible n'empêchera pas les conflits.

Bonnes pratiques et considérations de sécurité

Lors de la gestion de fichiers avec Ansible, la sécurité et l'idempotence sont primordiales :

1. Toujours définir les permissions avec `copy`

Ne poussez jamais un fichier de configuration sans définir explicitement le mode et l'owner. Si vous vous fiez au umask par défaut du système distant, des fichiers sensibles (comme les clés SSH ou les identifiants de base de données) pourraient se retrouver avec des droits d'accès trop permissifs.

# Mauvaise pratique (Mode dérivé de l'umask)
- name: Déployer une clé non sécurisée
  ansible.builtin.copy:
    src: private.key
    dest: /etc/app/private.key

# Bonne pratique (Restreindre l'accès explicitement)
- name: Déployer une clé sécurisée
  ansible.builtin.copy:
    src: private.key
    dest: /etc/app/private.key
    mode: '0600'
    owner: root

2. Utiliser `backup=yes` pour les changements critiques

Lorsque vous utilisez copy pour écraser un fichier existant et critique (par exemple, /etc/sudoers), incluez backup=yes. Ansible créera une copie de sauvegarde horodatée sur le nœud distant avant d'écraser le fichier, offrant une option de restauration facile.

3. Envisager le module `synchronize` pour les transferts importants

Bien que copy et fetch soient excellents pour les opérations ad-hoc rapides et les petits fichiers de configuration, si vous avez besoin de transférer de grandes structures de répertoires ou si vous avez besoin de transferts delta efficaces (ne transférant que les modifications), le module synchronize (qui utilise rsync) est l'outil recommandé pour des performances et une gestion supérieures.

Résumé

Les modules copy et fetch sont des outils indispensables dans la boîte à outils de l'administrateur Ansible, offrant des méthodes robustes et sécurisées pour manipuler des fichiers à travers une infrastructure. En maîtrisant la syntaxe des commandes ad-hoc et en comprenant les arguments clés, vous pouvez gérer efficacement les artefacts de déploiement et effectuer les opérations de récupération de données nécessaires sans avoir à créer des playbooks complets pour des tâches simples.

Module	Direction	Exemple de commande ad-hoc
`copy`	Nœud de contrôle -> Nœud géré	`ansible all -m copy -a "src=/local/file dest=/remote/path mode=0644"`
`fetch`	Nœud géré -> Nœud de contrôle	`ansible all -m fetch -a "src=/remote/file dest=/local/dir"`

Transfert de fichiers sécurisé : Utilisation des modules Ansible Copy et Fetch

Prérequis

Comprendre les commandes ad-hoc pour le transfert de fichiers

Le module copy : Pousser des fichiers vers des nœuds distants

Arguments clés pour copy