Environnement du TP 15 : CI/CD & Firewall-as-Code
Ce TP réutilise exactement la même VM FortiGate que le TP 6 (voir tp6-environnement.md) : aucune nouvelle VM à créer. Il ajoute un runner CI auto-hébergé sur le poste hôte.
1. Prérequis
- la VM FortiGate du TP 6 démarrée et accessible en API REST,
- un compte GitHub et le dépôt du TP 6 (ou un nouveau dépôt dédié),
- Git installé sur le poste hôte.
2. Pourquoi un runner auto-hébergé ?
Les runners GitHub Actions hébergés dans le cloud ne peuvent pas atteindre la VM FortiGate, isolée sur un réseau privé (host-only) accessible uniquement depuis le poste hôte. Un runner self-hosted, installé sur ce même poste, résout le problème.
3. Installation du runner GitHub Actions
- Sur GitHub : Settings du dépôt → Actions → Runners → New self-hosted runner.
- Choisissez votre OS (Linux/Windows/macOS) ; GitHub affiche des commandes personnalisées, par exemple sous Linux :
mkdir actions-runner && cd actions-runner
curl -o actions-runner.tar.gz -L https://github.com/actions/runner/releases/download/vX.X.X/actions-runner-linux-x64-X.X.X.tar.gz
tar xzf actions-runner.tar.gz
./config.sh --url https://github.com/<vous>/<depot> --token <token-affiché-par-github>
./run.sh- Vérifiez que le runner apparaît Idle dans l’interface GitHub.
Note : laissez ./run.sh actif dans un terminal (ou installez-le comme service avec ./svc.sh install && ./svc.sh start) pendant toute la durée du TP.
4. Secret CI
Dans Settings → Secrets and variables → Actions, ajoutez FORTIGATE_TOKEN avec la clé API générée au TP 6.
5. Vérification de la connectivité runner → FortiGate
Depuis le poste hôte (là où tourne le runner) :
curl -k -H "Authorization: Bearer $FORTIGATE_TOKEN" https://192.168.1.99/api/v2/cmdb/firewall/addressVérification finale
- Le runner self-hosted est actif et visible dans GitHub.
- Le secret
FORTIGATE_TOKENest configuré (jamais en clair dans le dépôt). - Le runner peut atteindre la VM FortiGate (test
curlréussi).