Déploiement GitLab¶
Déployer les scanners BoostSecurity au sein de GitLab nécessite une gestion attentive des limites de taux de Docker Hub et une configuration appropriée des runners auto-hébergés. Les travaux de GitLab doivent souvent tirer des images de conteneurs depuis Docker Hub, ce qui peut entraîner des échecs dus à la limitation de taux pour les utilisateurs anonymes. De plus, lors de l'utilisation de runners auto-hébergés, il est nécessaire de s'assurer que des paramètres corrects, tels que le mode privilégié, sont en place pour une exécution réussie. Ce document décrit les étapes nécessaires pour relever ces défis, y compris les méthodes d'authentification, les configurations de proxy de dépendances et la configuration des runners.
Limitation de Taux de Pull sur Docker Hub¶
Lorsqu'un travail GitLab Boost est exécuté, il a souvent besoin de tirer une image Docker depuis Docker Hub. Par défaut, cela se fait de manière anonyme, ce qui le rend sujet à la limitation de taux. Si la limite de taux est dépassée, le travail échouera car l'image de conteneur requise ne pourra pas être récupérée.
Pour éviter de dépasser la limite de taux de Docker Hub, il existe deux approches principales :
1. Authentification à Docker Hub¶
Les organisations disposant d'un compte Docker Hub peuvent configurer les travaux GitLab pour s'authentifier auprès du registre en utilisant les identifiants de leur compte. Cela peut être réalisé par les méthodes suivantes :
-
Utilisation de Runners Auto-Hébergés¶
Pour les runners auto-hébergés, modifiez la configuration du runner pour monter la configuration Docker dans chaque travail. Consultez la documentation officielle de GitLab pour plus de détails : Monter la configuration Docker.
-
Utilisation de GitLab SaaS sans Runners Auto-Hébergés¶
Si vous utilisez GitLab SaaS sans runners auto-hébergés, mettez à jour chaque projet où le scanner Boost est exécuté pour spécifier les identifiants nécessaires pour tirer depuis Docker Hub.
Étapes :
-
Créez un fichier
.config.gitlab-ci.ymldans votre dépôt Boost avec le contenu suivant :include: - .gitlab-ci.yml expose_docker_config: stage: .pre script: - echo "DOCKER_CONFIG=$(pwd)/.docker" > dotenv - . dotenv - mkdir -p $DOCKER_CONFIG - cp $DOCKERCONFIG $DOCKER_CONFIG/config.json artifacts: paths: - .docker/config.json reports: dotenv: dotenv -
Dans Paramètres du Projet → CI/CD → Variables, créez une variable de type fichier CI/CD :
-
Dans Paramètres du Projet → CI/CD → Pipeline général, définissez le fichier de configuration CI/CD sur
.config.gitlab-ci.yml.
2. Utiliser un Proxy de Conteneur Docker¶
Si vous ne disposez pas d'un compte Docker Hub, vous pouvez configurer un proxy de dépendances pour les images de conteneurs dans GitLab. Une fois activé pour le groupe parent du dépôt Boost, configurez le scanner Boost pour l'utiliser en définissant la variable CI/CD BOOST_DOCKER_PROXY avec la valeur définie sur group.
Étapes :
-
Dans Paramètres du Projet → CI/CD → Variables, créez une variable :
Runners Auto-Hébergés¶
Les scanners BoostSecurity peuvent être exécutés à l'aide de runners auto-hébergés GitLab. Cependant, une configuration supplémentaire peut être nécessaire pour assurer une exécution correcte.
Activation du Mode Privilégié¶
Pour exécuter le travail GitLab Boost, le runner GitLab doit être capable d'exécuter des conteneurs Docker. Cela nécessite d'activer le mode privilégié dans la configuration du runner.
La méthode de configuration dépend du type d'agent runner GitLab utilisé. Consultez la configuration avancée de GitLab pour des instructions détaillées.
Par exemple, lors de l'utilisation de l'agent Kubernetes GitLab déployé via le chart Helm GitLab, ajoutez ce qui suit au fichier values.yml :
runners:
config: |
[[runners]]
[runners.kubernetes]
# Exécutez tous les conteneurs avec le drapeau privilégié activé.
privileged = true
...


