Des variables aux intrants de pipeline pour une sécurité renforcée

Les variables de pipeline ont longtemps été un moyen pratique de personnaliser les pipelines CI/CD de GitLab dans l'environnement d'exécution. Toutefois, avec l'évolution des bonnes pratiques en matière de sécurité CI/CD, nous avons constaté qu'il était nécessaire de renforcer les contrôles liés à la personnalisation des pipelines. En l'absence de restrictions, les variables de pipeline permettent à tout utilisateur autorisé à déclencher un pipeline d'en modifier les valeurs sans validation ni vérification de type.

Au-delà des considérations de sécurité, les variables de pipeline présentent une documentation insuffisante et ne possèdent aucune déclaration explicite, ce qui rend difficile la compréhension des intrants attendus et la manière dont ces derniers sont utilisés tout au long du pipeline. Cette situation peut compliquer la maintenance et la mise en place d'une gouvernance appropriée de vos processus CI/CD.

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.

Découvrez les intrants de pipeline

Au lieu de vous fier aux variables de pipeline, nous recommandons vivement d'utiliser la fonctionnalité des intrants de pipeline de GitLab, qui offrent les avantages suivants :

• Déclaration explicite : les intrants doivent être déclarés explicitement dans le fichier .gitlab-ci.yml et sont documentés de manière autonome.

• Sécurité des types : différents types d'intrants (chaîne, valeur booléenne, nombre, tableau) sont pris en charge.

• Validation intégrée : les valeurs d'intrants sont validées automatiquement.

• Sécurité renforcée : aucun risque d'attaques par injection de variables, car seuls les intrants déclarés peuvent être transmis de l'extérieur.

Exemple

spec:
  inputs:
    deployment_env:
      description: "Target deployment environment"
      type: string
      options: ["staging", "production"]
      default: "staging"
    enable_tests:
      description: "Run test suite"
      type: boolean
      default: true

test:
  script:
    - echo "Running tests"
  rules:
    - if: $[[ inputs.enable_tests ]] == true

deploy:
  script:
    - echo "Deploying to $[[ inputs.deployment_env ]]"

Découvrez comment les intrants CI/CD sécurisent la transmission des paramètres typés dans ce tutoriel.

Restreignez les variables de pipeline

Pour effectuer une transition efficace vers les intrants de pipeline et abandonner les variables de pipeline, vous devez configurer le paramètre « Rôle minimum autorisé à utiliser les variables de pipeline ». Ce paramètre offre un contrôle précis sur les rôles autorisés à utiliser les variables de pipeline lors du déclenchement des pipelines.

Au niveau du projet : accédez à Paramètres > CI/CD > Variables > Rôle minimum autorisé à utiliser les variables de pipeline de votre projet pour configurer ce paramètre.

Voici les options disponibles :

• Aucun rôle autorisé (no_one_allowed) : il s'agit de l'option recommandée et la plus sécurisée, car elle empêche toute modification de variable.

• Développeur (developer) : cette option autorise les développeurs et les rôles supérieurs à modifier les variables

• Chargé de maintenance (maintainer) : cette option requiert le rôle de chargé de maintenance ou supérieur.

• Propriétaire (owner) : seuls les propriétaires de projet peuvent modifier les variables.

Au niveau du groupe : les chargés de maintenance de groupe peuvent accéder à Paramètres > CI/CD > Variables > Rôle autorisé par défaut à utiliser les variables de pipeline afin d'établir des valeurs par défaut sécurisées pour tous les nouveaux projets au sein de leur groupe et de garantir des politiques de sécurité cohérentes dans toute l'organisation. Nous recommandons là encore de sélectionner Aucun rôle autorisé comme valeur par défaut. Ainsi, les nouveaux projets de ce groupe seront créés avec un paramètre sécurisé par défaut, mais les propriétaires de projet pourront toujours le modifier.

Lorsque les variables de pipeline sont totalement restreintes (en raison du paramètre « Aucun rôle autorisé »), les variables préremplies n'apparaîtront pas dans le formulaire « Nouveau pipeline UI ».

Migration des variables de pipeline

Vérifiez vos projets en cours

Votre groupe peut comporter des projets pour lesquels les variables de pipeline sont activées par défaut alors qu'elles n'ont jamais été utilisées. Ces projets peuvent être migrés vers un paramètre plus sécurisé sans risque d'interruption. GitLab fournit une fonctionnalité de migration via les paramètres de groupe :

• Accédez à Paramètres > CI/CD > Variables

• Dans Désactiver les variables de pipeline dans les projets qui ne les utilisent pas, sélectionnez Démarrer la migration.

Cette action désactive de manière sécurisée les variables de pipeline via les paramètres de projet pour tous les projets qui ne les ont pas utilisés depuis leur création.

Transformez les variables de pipeline en intrants

Pour chaque variable de pipeline identifiée, créez un intrant de pipeline correspondant.

Avant (avec des variables de pipeline)

variables:
  DEPLOY_ENV:
    description: "Deployment environment"
    value: "staging"
  ENABLE_CACHE:
    description: "Enable deployment cache"
    value: "true"
  VERSION:
    description: "Application version"
    value: "1.0.0"

deploy:
  script:
    - echo "Deploying version $VERSION to $DEPLOY_ENV"
    - |
      if [ "$ENABLE_CACHE" = "true" ]; then
        echo "Cache enabled"
      fi

Après (avec des intrants de pipeline)

spec:
  inputs:
    deploy_env:
      description: "Deployment environment"
      type: string
      default: "staging"
      options: ["dev", "staging", "production"]

    enable_cache:
      description: "Enable deployment cache"
      type: boolean
      default: true
    
    version:
      description: "Application version"
      type: string
      default: "1.0.0"
      regex: '^[0-9]+\.[0-9]+\.[0-9]+$'

deploy:
  script:
    - echo "Deploying version $[[ inputs.version ]] to $[[ inputs.deploy_env ]]"
    - |
      if [ "$[[ inputs.enable_cache ]]" = "true" ]; then
        echo "Cache enabled"
      fi

Migrez les jobs de déclenchement

Si vous utilisez des jobs de déclenchement avec le mot-clé trigger, assurez-vous qu'ils ne définissent pas de variables au niveau du job ou ne désactivent pas des variables héritées depuis un groupe principal comme variables, extends ou include, car elles pourraient être transmises implicitement en aval en tant que variables de pipeline. Si les variables de pipeline sont restreintes sur le projet en aval, la création du pipeline échouera.

Envisagez de mettre à jour votre configuration CI pour utiliser des intrants de pipeline plutôt que des variables de pipeline.

variables:
  FOO: bar

deploy-staging:
  inherit:
    variables: false # otherwise FOO would be sent downstream as a pipeline variable
  trigger:
    project: myorg/deployer
    inputs:
      deployment_env: staging
      enable_tests: true

Résumé

La migration des variables de pipeline vers des intrants de pipeline représente une amélioration de sécurité qui protège votre infrastructure CI/CD contre les injections de variables tout en offrant une documentation, une sécurité des types et une validation renforcées. Avec ces restrictions et les intrants de pipeline, vous améliorez non seulement la sécurité, mais aussi la maintenance, la documentation autonome et la robustesse de vos pipelines.

Cette transition nécessite un effort initial, mais les bénéfices à long terme dépassent largement les coûts de migration. Commencez par restreindre les variables de pipeline au niveau du groupe pour les nouveaux projets, puis migrez systématiquement les pipelines existants en suivant l'approche étape par étape décrite ci-dessus.

La sécurité est un processus continu. Les intrants de pipeline représentent une étape importante dans la création d'un environnement CI/CD plus sécurisé et viennent compléter d'autres fonctionnalités de sécurité de GitLab telles que les branches protégées, les listes d'autorisation de tokens de job et les protections du registre de conteneurs.

Commencez à utiliser les intrants de pipeline dès maintenant !

→ Essayez GitLab Ultimate et GitLab Duo Enterprise gratuitement.