Workspace Isolation CI

devsecops

Définition

La Workspace Isolation CI (isolation des espaces de travail CI/CD) désigne les pratiques et mécanismes garantissant que les jobs CI/CD de différents projets, branches, ou utilisateurs s'exécutent dans des environnements isolés, empêchant les fuites d'informations entre builds (secrets d'un projet A accédés par un job de projet B), les contaminations de l'environnement (dépendances résiduelles d'un build affectant le suivant), et les exécutions malveillantes profitant de la proximité avec d'autres workloads CI/CD. L'isolation des workspaces CI est particulièrement critique dans les environnements multi-tenants (runners GitHub Actions partagés, agents GitLab CI mutualisés) où plusieurs organisations ou projets partagent la même infrastructure d'exécution. Un job malveillant ou compromis dans un tel environnement pourrait tenter d'accéder aux fichiers temporaires des autres jobs, aux credentials en cache, ou aux processus d'autres jobs exécutés en parallèle sur le même runner. Les niveaux d'isolation disponibles dans les systèmes CI/CD modernes incluent : l'isolation par processus (isolation minimale — les jobs s'exécutent comme des processus séparés mais sur le même OS, partageant le kernel et le filesystem), l'isolation par container (chaque job s'exécute dans un container Docker dédié avec son propre filesystem et réseau, plus d'isolation mais partage du kernel hôte), l'isolation par VM éphémère (GitHub Actions "just-in-time runners" ou Buildkite elastic agents sur VMs dédiées — isolation maximale, la VM est créée pour le job et détruite à la fin, aucune persistance entre builds), et l'isolation par namespace Kubernetes (jobs CI s'exécutant dans des Pods Kubernetes avec Network Policies et RBAC limitant la communication). Les runners éphémères (une VM ou un container par job, détruits après le job) sont la solution de référence pour la sécurité maximale des pipelines CI/CD : l'absence de persistance entre builds élimine les contaminations résiduelles et les attaques basées sur les artefacts laissés par des builds précédents.

GitHub Actions : runners éphémères just-in-time

GitHub Actions juste-in-time (JIT) runners offrent une isolation maximale : chaque workflow job crée un nouveau runner (VM ou container), récupère et exécute le job, puis le runner est définitivement détruit. Configuration : Organization Settings → Actions → Runners → New self-hosted runner → Generate registration token, puis utiliser actions-runner-controller (Kubernetes) ou une solution cloud (AWS CodeBuild, Azure Container Apps) pour provisionner des runners éphémères à la demande. Les runners éphémères éliminent le risque de persistence entre builds (pas de fichiers temporaires résiduels, pas de credentials cachés).

Sécuriser les runners partagés

Mesures de sécurité pour les runners partagés inévitables : 1) Runner isolation (ne jamais partager des runners entre organisations différentes), 2) Nettoyage strict post-job (rm -rf ${RUNNER_TEMP}/*), 3) Pas de credentials persistants dans les runners (utiliser OIDC pour l'authentification cloud au lieu de credentials statiques), 4) Audit des jobs exécutés (logging de toutes les commandes exécutées), 5) Network policy stricte (les runners ne peuvent pas accéder à d'autres runners ou aux systèmes internes non nécessaires). GitHub hosted runners offrent une isolation par VM (chaque job = nouvelle VM Ubuntu/Windows) — utiliser des runners hébergés GitHub quand possible.

OIDC : éliminer les credentials dans les pipelines

L'OIDC (OpenID Connect) pour l'authentification cloud depuis CI/CD élimine le besoin de stocker des credentials AWS/GCP/Azure dans les secrets CI/CD : le runner CI obtient un token OIDC signé (GitHub Actions OIDC token, GitLab CI/CD JWT), échange ce token contre des credentials cloud temporaires (via AWS STS AssumeRoleWithWebIdentity, GCP Workload Identity Federation), et ces credentials temporaires expirent automatiquement après 1h. Plus de secrets AWS_ACCESS_KEY_ID stockés dans GitHub Secrets — seulement la configuration d'identité dans le provider cloud. Cette approche améliore l'isolation en éliminant la surface d'attaque des credentials persistants dans les runners.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis