Comptes de service OVHcloud : création et gestion IAM via espace client

Table des matières :

1. IAM OVHcloud et comptes de service : ce que vous automatisez réellement
2. Modèle de séparation (humains vs machines) et périmètres : éviter la confusion des responsabilités
3. Création d’un compte de service OVHcloud dans l’espace client (Manager) : étapes et pièges
4. Attribution des permissions IAM : granularité, moindre privilège, et exemples concrets orientés e‑commerce
5. Intégration opérationnelle : Terraform, Kubernetes, rotation et révocation sans casser la prod
6. Check-list concrète : création et gestion IAM via espace client, sans se raconter d’histoires

IAM OVHcloud et comptes de service : ce que vous automatisez réellement

Un compte de service OVHcloud est une identité non humaine, conçue pour exécuter des actions via API ou via des intégrations (Terraform, scripts, opérateurs Kubernetes, pipelines CI/CD) sans réutiliser les identifiants d’un opérateur. Dans un contexte e‑commerce, c’est typiquement ce qui évite de “brancher” un token d’admin perso dans une pipeline qui redéploie un Ingress, tourne des snapshots ou modifie une zone DNS. Le bénéfice n’est pas cosmétique : vous isolez le risque, vous rendez la rotation possible, et vous rétablissez la traçabilité (qui a fait quoi, depuis quel périmètre).

Chez OVHcloud, IAM sert à modéliser des identités (utilisateurs, comptes de service), à les rattacher à un périmètre (organisation/projet/ressource selon les produits) et à leur associer des droits. Attention : OVHcloud a historiquement un modèle d’autorisations très orienté API (application key/secret + consumer key avec règles sur des endpoints). IAM apporte une couche plus lisible côté “espace client”, mais vous retrouvez encore, selon les services, des mécaniques différentes. En pratique, vous devez toujours valider : (1) quelle ressource est réellement couverte par IAM, (2) quelle action est vraiment restreinte, (3) comment se fait l’audit.

Pour éviter les malentendus, gardez en tête ce que vous automatisez vraiment avec un compte de service :

• Un périmètre (ex. un projet, une zone DNS, un bucket, un cluster) : l’identité n’est qu’un “porte-clés”, pas une stratégie.
• Un ensemble d’actions (read/write/delete/administration) : la surface d’attaque est souvent plus large que l’action “métier” (ex. “mettre à jour DNS” implique parfois lecture des zones, listing, etc.).
• Un canal d’exécution (CI, Cron, contrôleur K8s) : c’est souvent là que fuit le secret (logs, artefacts, variables, backups).
• Un modèle d’audit : si vous ne pouvez pas attribuer une action à un identifiant précis, la promesse IAM est incomplète.

Le point que beaucoup ratent : un compte de service n’est pas “plus sécurisé” par magie. Il est sécurisé si vous appliquez le principe du moindre privilège et si vous traitez ses secrets comme des secrets (stockage chiffré, rotation, révocation). La formulation canonique du principe du moindre privilège n’a pas bougé depuis 1975 : « Every program and every user of the system should operate using the least set of privileges necessary to complete the job. » (Saltzer & Schroeder, The Protection of Information in Computer Systems, 1975). Tout le reste (IAM, policies, UI) n’est qu’une implémentation de ce principe.

Dernier détail “terrain” : si vous hébergez un shop avec des contraintes de résidence (données clients UE, exigences internes, contrats), IAM fait partie de l’architecture de conformité. OVHcloud opère des régions/datacenters en France (ex. Gravelines/Roubaix/Strasbourg selon les offres et régions), et vos ressources peuvent être réparties. Le compte de service, lui, doit être pensé pour suivre cette réalité : une identité “globale” avec des droits partout rend l’audit et la preuve de conformité beaucoup plus difficiles.

Modèle de séparation (humains vs machines) et périmètres : éviter la confusion des responsabilités

Pour une stack typique PrestaShop 9.x (ex. 9.0/9.1) sur PHP 8.2 (ou 8.3 selon votre runtime), l’erreur classique est d’utiliser un seul “admin OVH” qui fait tout : DNS, Managed Kubernetes, Object Storage, bases managées, serveurs dédiés. Sur le papier c’est rapide ; en production c’est un cauchemar : vous ne pouvez ni segmenter prod/staging, ni auditer les opérations, ni révoquer proprement un accès. Le bon pattern : des comptes humains (avec MFA, accès interactif) + des comptes de service (sans MFA, accès programmatique), et des périmètres séparés.

Concrètement, définissez au minimum :

• un périmètre production (projet OVHcloud dédié ou au moins regroupement strict des ressources),
• un périmètre staging/recette,
• un compte “break-glass” humain (accès d’urgence),
• un compte de service par usage : ci-deploy-prod, dns-sync-prod, backup-operator, etc.

Ce découpage vous évite de surdoter un compte “machine” parce qu’il “sert à tout”. Dans une agence ou une équipe multi‑produits, ça vous évite aussi de mélanger les responsabilités : un intégrateur front n’a rien à faire avec des droits de gestion de clés KMS ; un module maker n’a pas besoin du droit de redémarrer un cluster.

Mini-scénario (très courant en e‑commerce) : vous préparez une opération commerciale (pics de trafic, freeze applicatif, surveillance renforcée). Le vendredi 18h, une pipeline doit basculer un enregistrement www vers un nouveau load balancer (blue/green). Si vous utilisez le même accès “admin” que le reste de l’équipe, le moindre leak de ce secret (un log CI trop bavard, un export de variables, un partage de projet) donne potentiellement accès à tout : DNS, stockage, clusters, et parfois même la facturation. En séparant dns-sync-prod de ci-deploy-prod, vous réduisez immédiatement l’impact : un incident DNS reste un incident DNS, pas une compromission d’organisation.

Si vous avez déjà dû faire du containment après compromission (webskimmer, token leak, etc.), vous savez que réduire le blast radius fait gagner des heures. Sur ce sujet, votre playbook d’urgence doit être prêt avant l’incident (voir aussi : plan de réponse à incident PrestaShop et containment immédiat).

Deux pratiques simples améliorent beaucoup la séparation :

• Un registre d’identités (même un simple tableau interne au départ) : Nom du compte, usage, périmètre, propriétaire, date de création, dernier usage constaté, date de rotation, lien vers repo/pipeline.
• Des dates de péremption (ou au minimum une revue trimestrielle) : un compte “provisoire” non supprimé finit statistiquement par devenir un compte “oublié” — et les comptes oubliés sont ceux qui tombent.

Création d’un compte de service OVHcloud dans l’espace client (Manager) : étapes et pièges

Pré-requis côté organisation : vous devez disposer d’un accès permettant d’administrer IAM dans l’espace client OVHcloud (souvent un rôle d’admin au niveau de l’organisation/du compte de facturation, selon votre configuration). Pré-requis côté pratique : préparez une convention de nommage et un registre interne. Un compte de service n’est pas un “user jetable” ; c’est un objet d’architecture. Un bon nom encode l’usage + l’environnement + la portée : tf-k8s-prod-readwrite, eso-okms-prod-read, etc.

Avant même de cliquer dans le Manager, posez-vous ces questions (ça évite 80% des “comptes trop puissants”) :

• Quel workflow exact appelle l’API ? (pipeline GitLab, job GitHub Actions, Cron sur un bastion, opérateur K8s…)
• Quelle ressource exacte est ciblée ? (nom de zone DNS, bucket, projet, cluster)
• Quelles actions sont réellement nécessaires ? (liste/read, create/update, delete, admin)
• Quel est le plan de rotation ? (date, responsable, procédure de double-run)
• Quelle est la stratégie de secours si le secret est révoqué par erreur ? (break-glass + runbook)

Dans l’espace client OVHcloud, la création se fait généralement depuis la zone IAM / Identités (l’intitulé exact peut varier). Vous créez une nouvelle identité de type compte de service, vous lui associez : (1) un nom, (2) une description exploitable (inclure l’équipe, le repo, le pipeline), (3) éventuellement des tags/labels si l’UI le permet, puis vous l’ajoutez à un groupe (recommandé) ou vous lui affectez directement des droits.

Quelques pièges (et comment les éviter) :

• Description vide ou inutilisable → incluez le repo, le chemin de pipeline, et un contact (équipe ou personne). Exemple : “Déploiement prod / repo infra-shop / job deploy-prod / owner platform@”.
• Droits ajoutés “en direct” sur l’identité → privilégiez un groupe/policy réutilisable, sinon vous ne saurez plus “où” sont les permissions.
• “Temporairement admin” → ajoutez une étape obligatoire “réduction des droits” dans votre ticket de changement (change request), avec validation après test.
• Un compte par environnement mais secrets partagés → évitez : le secret doit suivre l’environnement. Un secret de staging qui marche en prod est un anti-pattern.

Ensuite vient la partie sensible : les informations d’authentification associées au compte de service (token, clé, secret, ou délégation vers un mécanisme d’API keys selon les produits). À ce stade, vous devez décider où va vivre ce secret.

• Pour une app serveur (ex. microservice Symfony/Laravel autour de PrestaShop), évitez le .env en clair sur disque : utilisez un secret manager ou au minimum une injection via variables d’environnement au runtime.
• Pour Kubernetes, utilisez un opérateur de synchronisation de secrets depuis une source chiffrée. Si vous êtes sur OVHcloud, vous pouvez combiner External Secrets Operator et OVHcloud OKMS (voir : synchroniser des secrets Kubernetes avec OVHcloud OKMS via External Secrets Operator).
• Pour CI/CD, stockez le secret dans le coffre du provider (GitLab CI variables protégées, GitHub Actions secrets, etc.) et limitez l’exposition (masked + protected + environnements).

Une recommandation transversale utile (et vérifiable) côté bonnes pratiques : le guide OWASP sur la gestion des secrets synthétise très bien les risques classiques (fuite dans le code, journaux, artefacts, backups) et les mesures (rotation, séparation des environnements, contrôle d’accès). Référence : Guide OWASP — gestion des secrets

Attribution des permissions IAM : granularité, moindre privilège, et exemples concrets orientés e‑commerce

Le cœur de la gestion IAM n’est pas “créer l’identité” mais définir la permission minimale. Selon les services OVHcloud, vous aurez des rôles prédéfinis (lecture seule, opérateur, admin) et/ou des politiques plus fines. Ne partez jamais d’“Admin” si votre usage est de faire une action répétitive. Mesurez ce que vous voulez réellement autoriser : lecture de métriques, écriture sur un bucket précis, modification d’enregistrements DNS dans une zone spécifique, redéploiement d’un composant dans un namespace Kubernetes, etc.

Une manière pragmatique de construire la permission minimale (sans passer 2 jours à deviner) :

1. Listez l’action métier (ex. “mettre à jour www et api en DNS”).
2. Cartographiez les appels (endpoints API, opérations UI, ressources touchées).
3. Appliquez une policy restrictive (périmètre + verbes).
4. Testez en conditions réelles (pipeline ou script).
5. Retirez tout ce qui ne sert pas, puis re-testez.

Table de départ (exemples typiques e‑commerce) — à adapter selon votre catalogue de services OVHcloud et ce que l’IAM couvre réellement dans votre compte :

Usage	Compte de service	Périmètre	Droits attendus	Stockage du secret
Blue/green DNS	dns-sync-prod	Zone example.com	Lire/mettre à jour certains records	Coffre CI + rotation
Déploiement K8s	ci-deploy-prod	Cluster/namespace prod	Déclencher déploiement (via votre tooling), pas d’admin global	Coffre CI + scoping
Sauvegarde DB → Object Storage	backup-operator	Projet DB + bucket backups-prod	Lire/exporter backup + écrire dans 1 bucket	OKMS + ESO
Observabilité (lecture)	monitoring-readonly	Projet prod	Lecture métriques/logs	Secret manager, accès restreint

Exemple réaliste (stack PrestaShop 9 + PHP 8.2, hébergée derrière un reverse‑proxy et un CDN) : vous avez besoin d’un compte de service pour mettre à jour des enregistrements DNS lors d’un blue/green (nouvel IP/LoadBalancer). Ici, le compte de service ne doit pas gérer tout le compte OVHcloud ; il doit pouvoir modifier une zone DNS (et idéalement un sous‑ensemble de records : A, AAAA, CNAME pour www et api). Tout le reste (facturation, tickets support, autres zones) doit être hors périmètre.

Point d’attention concret : dans beaucoup d’API DNS, “modifier un record” implique aussi lister et parfois lire la zone. Anticipez-le : si vous ne donnez que “write” sans “read/list”, votre automation échoue et vous serez tenté de “mettre admin pour que ça marche”. C’est exactement ce glissement qui détruit le moindre privilège.

Autre exemple : un compte de service backup-operator pour déclencher des opérations de sauvegarde et exporter des dumps chiffrés vers Object Storage. Dans ce cas, le compte doit avoir : (1) droit de lecture sur la base concernée (ou sur l’API de backup), (2) droit d’écriture sur un bucket dédié backups-prod avec une politique de rétention, (3) aucun droit de suppression si vous voulez limiter les effacements malveillants. Et côté bucket, segmentez aussi : un bucket “backups” ne doit pas être celui qui sert aux assets front (images produits), sinon une fuite de clés a un impact double (disponibilité + intégrité).

Si vous gérez des secrets/API keys côté application, la même logique s’applique : mettez en place la rotation, la limitation de débit et la séparation des scopes (voir : sécuriser une API : apikey, rate limiting et conformité).

Dernier point souvent négligé : l’alignement IAM ↔ audit. Un compte de service doit permettre de répondre à “qui a modifié quoi ?” en moins de 10 minutes, sans fouiller 4 systèmes. Si les logs OVHcloud ne suffisent pas pour votre exigence (ou si l’UI est trop pauvre), centralisez : export des logs, corrélation avec vos pipelines, et journalisation applicative (ex. votre orchestrateur de déploiement écrit un event horodaté). C’est exactement le même raisonnement que pour déboguer des erreurs 503 : sans traces, vous n’avez pas d’incident, vous avez une rumeur (voir : diagnostiquer une erreur HTTP 503 avec les logs et la capacité serveur).

Intégration opérationnelle : Terraform, Kubernetes, rotation et révocation sans casser la prod

Une fois le compte de service créé et correctement scindé par usage, vous voulez l’exploiter dans des outils d’infra. Pour Terraform, le bout est d’éviter les accès “humains” dans le state et de pouvoir invalider un accès sans immobiliser les devs.

Deux points opérationnels qui évitent des incidents :

• Ne mélangez pas provisioning et exploitation : un compte Terraform qui crée des ressources (projet, réseau, DNS, buckets) n’est pas le même que celui qui fait du “day‑2” (déploiements applicatifs, rotations de secrets). Sinon, une compromission CI devient une compromission d’infra.
• Protégez le state : le state Terraform est une source de vérité… et parfois une fuite de secrets si vos variables/outputs sont mal gérés. Le compte de service qui accède au backend state doit être restreint et surveillé.

Même si votre provisioning inclut des opérations bas niveau (réinstallation, partitionnement), vous pouvez isoler ce pouvoir dans un compte très spécifique, activé seulement lors des fenêtres de maintenance. Un exemple typique côté OVH : gérer une réinstallation et son schéma disque via API nécessite des autorisations élevées, donc ne mélangez pas ça avec un compte qui ne fait que manipuler DNS (voir : réinstaller un serveur via API OVHcloud avec LVM/ZFS).

Pour Kubernetes, ne confondez pas le ServiceAccount Kubernetes et le compte de service OVHcloud : ce sont deux identités distinctes. Côté Kubernetes, un ServiceAccount fournit une identité aux processus qui tournent dans un Pod (documentation officielle : https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). Le pattern robuste en 2026 consiste à :

1. attribuer au Pod une identité Kubernetes minimale (RBAC),
2. éviter de monter des secrets statiques quand un mécanisme de fédération existe,
3. si vous devez utiliser un secret OVHcloud, le livrer via un contrôleur (External Secrets Operator) depuis une source chiffrée (OKMS) et le limiter au namespace,
4. documenter la chaîne d’accès : Pod → Secret K8s → source de vérité (OKMS/CI vault) → compte de service OVHcloud → ressource OVHcloud.

La rotation/révocation est le vrai test de maturité. Définissez une politique simple et exécutable :

1. Rotation périodique (par ex. 60–90 jours) + rotation immédiate si fuite soupçonnée.
2. Double-run : durant une fenêtre courte, votre application/pipeline accepte ancien + nouveau secret (ou vous déployez en canary), puis vous révoquez l’ancien.
3. Révocation automatisée en sortie d’équipe ou suppression d’un pipeline.

Exemple concret de “rotation sans casser la prod” sur un shop : vous faites tourner la clé dns-sync-prod. Vous déployez d’abord la nouvelle clé dans le coffre CI, vous lancez un job “dry-run” qui vérifie qu’il peut lister la zone et calculer le diff attendu (sans appliquer), puis vous basculez le job réel sur la nouvelle clé. Une fois un déploiement réussi, vous révoquez l’ancienne clé. Ce simple enchaînement évite le scénario classique : “on a révoqué, et maintenant plus personne ne peut déployer un hotfix”.

Sans ça, IAM devient une base de dettes : vous accumulez des comptes et des clés actives “au cas où”. Le résultat est prévisible : un secret finit dans un log, un artefact CI ou un dépôt privé mal protégé, et vous perdez le contrôle.

Check-list concrète : création et gestion IAM via espace client, sans se raconter d’histoires

Avant de créer un compte de service OVHcloud dans le Manager, figez 3 décisions : (1) quel est l’usage exact, (2) quel est le périmètre exact (prod/staging, projet, ressource), (3) où vivra le secret (OKMS/secret manager/CI vault). Si vous ne pouvez pas répondre en une phrase à chacun de ces points, vous êtes en train de créer un futur “super compte” dangereux.

Pendant la création, appliquez une discipline “runbook-ready” : nommage stable, description qui pointe vers un repo/pipeline, et droits attribués via un groupe/policy réutilisable (pas via du clic ad hoc sur l’identité). Si votre UI IAM permet d’ajouter des métadonnées (tags), utilisez-les pour pouvoir lister et nettoyer. Et gardez un compte humain break-glass indépendant, avec MFA, stocké hors SSO si besoin : l’anti-pattern ici c’est de se lock‑out en révoquant le mauvais accès.

Après création, validez techniquement : exécutez les opérations attendues (et uniquement elles) via un script de test, puis écrivez une preuve reproductible (commande, pipeline, job). Mesurez ensuite ce que vous avez réellement gagné :

• réduction du nombre de secrets “humains” en CI,
• réduction du périmètre de droits par pipeline,
• temps de révocation (objectif : minutes, pas heures),
• capacité d’audit (quel compte, quelle action, quel timestamp).

Ajoutez une revue “hygiène IAM” simple (mensuelle ou trimestrielle) :

• lister les comptes de service,
• identifier ceux sans propriétaire (à corriger immédiatement),
• identifier ceux sans usage récent (à désactiver puis supprimer),
• vérifier les dates de rotation,
• vérifier qu’aucun compte de service n’a des droits transverses “organisation entière” sans justification.

Si vous n’obtenez pas ces gains, le problème n’est pas OVHcloud IAM : c’est votre modèle d’accès. Et ça se corrige… mais pas en ajoutant “un compte de service de plus”.