Gestion sécurisée des secrets et des API‑keys dans les pipelines Workflow v6

Introduction

La sécurisation des secrets (tokens, clés d’API, certificats) est un point de friction fréquent lorsqu’on industrialise le développement d’IA avec Workflow v6. Le moindre éclairage accidentel d’un secret peut entraîner des violations de données, des coûts inattendus ou une compromission de la chaîne d’approvisionnement. Cet article décrit une méthode rigoureuse pour injecter, stocker et auditer les secrets dans les pipelines Workflow v6 en s’appuyant sur HashiCorp Vault (ou tout autre KMS compatible) et sur les mécanismes de contrôle d’accès de la plateforme.

1. Architecture de la chaîne de confiance

Le schéma suivant illustre le flux de secrets :

• Vault : coffre‑fort centralisé, chiffré au repos, accessible via TLS mutual.
• Workflow v6 : moteur d’orchestration qui récupère les secrets au moment de l’exécution via le secret provider.
• Agents : workers Kubernetes ou VM qui exécutent les tâches. Ils ne contiennent jamais de secrets en clair dans le Dockerfile ou le repo.

Cette architecture garantit que les secrets ne circulent jamais en clair et qu’ils sont audités à chaque requête.

2. Configuration du secret provider dans Workflow v6

Workflow v6 supporte un secret provider configurable via le fichier workflow.yaml. Exemple minimal :

secret_providers:
  vault:
    address: https://vault.my‑corp.local:8200
    auth_method: kubernetes
    role: workflow-v6-role
    ttl: 15m

• address : point d’accès du serveur Vault.
• auth_method : nous utilisons l’authentification Kubernetes, qui repose sur le ServiceAccount du pod.
• role : le rôle Vault doit être pré‑créé avec les politiques nécessaires.
• ttl : durée de vie du token d’accès, limitant la fenêtre d’exposition.

3. Définition des politiques d’accès fine‑grained

Dans Vault, créez une politique qui restreint l’accès aux chemins requis par le pipeline :

path "secret/data/{{ .Job.Namespace }}/{{ .Job.Name }}/*" {
  capabilities = ["read"]
}

Cette politique utilise les variables d’environnement du job ({{ .Job.Namespace }} et {{ .Job.Name }}) afin que chaque pipeline ne puisse lire que les secrets qui lui sont explicitement assignés. Ainsi, même si un job compromis tente de lire d’autres secrets, la requête sera rejetée.

4. Injection des secrets dans les tâches

Dans le workflow.yaml du projet, les secrets sont référencés via la syntaxe {{ secret:<path> }}. Exemple :

jobs:
  train_model:
    image: myregistry/ai‑trainer:latest
    env:
      OPENAI_API_KEY: "{{ secret:secret/data/ml/keys/openai }}"
      DB_PASSWORD: "{{ secret:secret/data/ml/db/password }}"
    command: ["python", "train.py"]

Lors de l’exécution, le moteur résout les placeholders, récupère les valeurs depuis Vault et les injecte uniquement dans le conteneur du job, en tant que variables d’environnement. Les valeurs ne sont jamais écrites sur le disque du worker.

5. Rotation automatique des secrets

La rotation périodique minimise le risque de compromission à long terme. Workflow v6 propose un cron job dédié :

jobs:
  rotate_secrets:
    schedule: "0 3 * * 0"  # chaque dimanche 03:00
    image: hashicorp/vault:latest
    command: ["vault", "kv", "rotate", "secret/data/ml/keys/openai"]

Le job utilise le même rôle Vault, mais avec la permission update. La rotation est combinée à un redeploy des pipelines dépendants afin que les nouvelles valeurs soient prises en compte dès le prochain run.

6. Audits et traçabilité

Vault génère un log d’audit JSON pour chaque requête d’accès. Il est recommandé de le répliquer dans un système SIEM (ex. : Elastic Stack). Un filtre typique :

{
  "type": "audit",
  "request_path": "secret/data/ml/keys/openai",
  "operation": "read",
  "auth": {
    "entity_id": "{{service_account_id}}",
    "policies": ["workflow-v6-role"]
  },
  "timestamp": "{{timestamp}}"
}

Les alertes peuvent être déclenchées sur des accès inhabituels (ex. : lecture hors heures ouvrées ou depuis une zone géographique inattendue).

7. Bonnes pratiques résumées

• Isolation des comptes : chaque pipeline possède son propre ServiceAccount et son rôle Vault dédié.
• TTL court : limitez la durée de vie des tokens d’accès pour réduire la surface d’attaque.
• Éviction du secret du code : jamais de secret en clair dans le repo ou le Dockerfile.
• Rotation programmée : combinez rotation et redéploiement automatisé.
• Audit continu : intégrez les logs Vault à votre chaîne SIEM et définissez des seuils d’alerte.

En appliquant ces principes, les équipes produit et les ingénieurs peuvent exploiter la puissance de Workflow v6 tout en maintenant un niveau de sécurité conforme aux exigences réglementaires modernes.