Industrialiser le déploiement via GitHub Actions (whitelist SSH dynamique o2switch)

[ronan-develop]

Description

Le déploiement en production est actuellement 100% manuel : bin/deploy.sh --update (ou bin/deploy-all.sh pour toutes les instances) est lancé à la main depuis un poste dev, en SSH vers o2switch. Le webhook GitHub existant (public/deploy.php, déclenché par un webhook repo GitHub sur push) est cassé depuis plusieurs jours (401 "Invalid signature" sur les 87 dernières livraisons observées) et n'est de toute façon plus utilisé — les vrais déploiements passent par les scripts bin/.

Objectif : industrialiser via GitHub Actions plutôt que de dépendre d'une exécution manuelle du script (risque d'oubli d'étape, pas de trace centralisée, dépendant de la présence de quelqu'un pour lancer le script).

Cause

Le blocage principal identifié : o2switch restreint l'accès SSH à une liste d'IP whitelistées (cPanel → Outils → Autorisation SSH). Un runner GitHub-hosted classique (runs-on: ubuntu-latest) change d'IP à chaque exécution et ne peut pas être whitelisté durablement — d'où l'abandon initial de cette piste (absence d'IP fixe côté FAI pour un éventuel runner self-hosted local).

Piste de correction

o2switch expose une micro-API dédiée à ce cas d'usage CI/CD : SshWhitelist (endpoint https://<serveur>:2083/execute/SshWhitelist/), permettant d'ajouter/retirer dynamiquement l'IP éphémère d'un runner avant/après un déploiement (max 5 exceptions simultanées, opération quasi-bloquante ~35s). Workflow envisagé :

1. Récupérer l'IP publique du runner GitHub-hosted (curl ifconfig.me)
2. SshWhitelist/add?address=<IP>&port=22
3. Déploiement via SSH (bin/deploy-all.sh, déjà compatible mode non-interactif via les variables *_PRESET)
4. SshWhitelist/remove (step if: always(), pour ne jamais laisser une IP éphémère whitelistée en permanence)

Secrets nécessaires en GitHub Encrypted Secrets : clé SSH dédiée au déploiement, credentials pour l'API SshWhitelist.

Blocage en cours : l'authentification recommandée par o2switch pour SshWhitelist est un token API cPanel ("Manage API Tokens"), mais cette page apparaît vide dans le cPanel de l'instance ron2cuba malgré une offre (Unique Cloud) qui y donne théoriquement droit. Ticket ouvert auprès du support o2switch (prioritaire 24/7 N2) — en attente de réponse.

Repli possible si le token reste indisponible : authentification par identifiants cPanel classiques (login/mot de passe cPanel) auprès de l'API SshWhitelist — dépréciée par o2switch mais fonctionnelle, avec un niveau de sécurité moindre (mot de passe cPanel entier en secret GitHub plutôt qu'un token scopé/révocable individuellement).

Critères d'acceptation

• Réponse du support o2switch obtenue sur la disponibilité de "Manage API Tokens"
• .github/workflows/deploy.yml créé : whitelist dynamique → déploiement SSH → dé-whitelist, déclenché sur push main (après CI verte) et/ou workflow_dispatch
• Secrets configurés côté GitHub (clé SSH dédiée + credentials SshWhitelist), jamais committés
• Le webhook public/deploy.php cassé/inutilisé est soit réparé soit retiré (éviter la confusion entre deux mécanismes de déploiement)
• Documentation mise à jour (.claude/cicd.md, .claude/deploiement.md) pour refléter le nouveau mécanisme

Zone concernée

CI/CD + Déploiement

Effort estimé

M — dépend de la réponse du support o2switch (token vs repli credentials classiques)

[ronan-develop]

Réponse du support o2switch reçue : la fonctionnalité "Manage API Tokens" est actuellement bloquée à des fins de sécurité (indisponible, pas de date de retour annoncée), malgré une offre (Unique Cloud) qui y donnerait théoriquement droit.

Ça écarte l'option token API cPanel pour authentifier l'API SshWhitelist. Deux pistes restent ouvertes :

1. Authentification par identifiants cPanel classiques (login/mot de passe) auprès de l'API SshWhitelist — dépréciée par o2switch mais fonctionnelle, secret GitHub = mot de passe cPanel entier (moins bien qu'un token scopé/révocable)
2. Revenir sur l'option VPS self-hosted runner avec IP statique (abandon initial, mais applicable indépendamment de ce blocage)

[ronan-develop]

Décision : on reste sur le déploiement manuel via bin/deploy-all.sh pour le moment (pas d'automatisation GitHub Actions dans l'immédiat). Ticket laissé ouvert pour référence si le contexte change (offre o2switch supérieure débloquant les tokens, ou besoin de fréquence de déploiement plus élevée).

[ronan-develop]

Mise à jour 2026-07-21 — blocage confirmé côté agent Claude Code

Tenté aujourd'hui d'automatiser un whitelist ponctuel via l'API SshWhitelist (repli credentials cPanel classiques, faute de token API toujours indisponible) depuis l'agent Claude Code utilisé pour le développement/déploiement de ce repo.

Constat : la commande curl -u "<user_cpanel>:<mdp_cpanel>" "https://.../execute/SshWhitelist/add?..." a été bloquée par le classifier de sécurité de l'outil (mot de passe en clair dans une commande shell vers un service externe — comportement attendu et voulu de l'outil, pas un bug).

Implication pour ce ticket : même le repli "credentials cPanel classiques" documenté plus haut n'est pas automatisable de façon fiable par un agent IA — la commande doit être lancée manuellement par un humain depuis sa propre CLI à chaque fois. Ça ne change rien à la faisabilité d'un futur deploy.yml piloté par GitHub Actions (qui n'a pas cette contrainte, le secret y est géré nativement), mais confirme qu'on ne peut pas déléguer ce contournement à un assistant IA en attendant.

Statut actuel : ticket support o2switch toujours en attente sur la disponibilité de "Manage API Tokens" (cf. description). Rien à faire de plus tant que cette réponse n'arrive pas — on reste sur le déploiement 100% manuel via bin/deploy-all.sh.