xlab-si/iac-scan-runnerService qui analyse votre Infrastructure en tant que Code pour les vulnérabilités courantes
| Aspect | Information |
|---|
| Nom de l'outil | IaC Scan Runner |
| Image Docker | xscanner/runner |
| Paquet PyPI | iac-scan-runner |
| Documentation | docs |
| Nous contacter | [email protected] |
IaC Scan Runner est un service d'API REST utilisé pour scanner un paquet IaC (Infrastructure en tant que Code) et effectuer différentes vérifications de code afin de trouver d'éventuelles vulnérabilités et améliorations. Consultez la documentation pour plus d'informations.
Cette section explique comment exécuter l'API REST.
Vous pouvez exécuter l'API REST en utilisant l'image Docker publique xscanner/runner comme suit :
# Exécuter l'API REST IaC Scan Runner dans un conteneur Docker et
# naviguer vers localhost:8080/swagger ou localhost:8080/redoc
$ docker run --name iac-scan-runner -p 8080:80 xscanner/runner
Ou vous pouvez construire l'image localement et l'exécuter ainsi :
# Construire le conteneur Docker (cela prendra du temps)
$ docker build -t iac-scan-runner .
# Exécuter l'API REST IaC Scan Runner dans un conteneur Docker et
# naviguer vers localhost:8080/swagger ou localhost:8080/redoc
$ docker run --name iac-scan-runner -p 8080:80 iac-scan-runner
Pour exécuter en utilisant la CLI IaC Scan Runner :
# Installer la CLI
$ python3 -m venv .venv && . .venv/bin/activate
(.venv) $ pip install iac-scan-runner
# Afficher la spécification OpenAPI
(.venv) $ iac-scan-runner openapi
# Installer les prérequis
(.venv) $ iac-scan-runner install
# Exécuter l'API REST IaC Scan Runner
(.venv) $ iac-scan-runner run
Pour exécuter localement depuis les sources :
# Exporter les variables d'environnement
export MONGODB_CONNECTION_STRING=mongodb://localhost:27017
export SCAN_PERSISTENCE=enabled
export USER_MANAGEMENT=enabled
# Configurer MongoDB
$ docker run --name mongodb -p 27017:27017 mongo
# Installer les prérequis
$ python3 -m venv .venv && . .venv/bin/activate
(.venv) $ pip install -r requirements.txt
(.venv) $ ./install-checks.sh
# Exécuter l'API REST IaC Scan Runner (ajouter le flag --reload pour appliquer les modifications de code à la volée)
(.venv) $ uvicorn src.iac_scan_runner.api:app
Cette partie montrera l'un des déploiements possibles et de courts exemples d'utilisation des appels API.
Nous allons d'abord cloner le dépôt iac scan runner et exécuter l'API.
$ git clone https://github.com/xlab-si/iac-scan-runner.git
$ docker compose up
Après cela, vous pouvez utiliser différents points de terminaison API en appelant localhost:8000. Vous pouvez également naviguer vers localhost:8000/swagger ou localhost:8000/redoc et tester tous les points de terminaison API là-bas. Dans cet exemple, nous utiliserons curl pour appeler les points de terminaison API.
curl -X 'POST' \
'http://0.0.0.0/project?creator_id=test' \
-H 'accept: application/json' \
-d ''
L'identifiant du projet nous sera retourné. Pour cet exemple, l'identifiant est 1e7b2a91-2896-40fd-8d53-83db56088026.
curl -X 'PUT' \
'http://0.0.0.0:8000/projects/1e7b2a91-2896-40fd-8d53-83db56088026/checks/ansible-lint/disable' \
-H 'accept: application/json'
curl -X 'POST' \
'http://0.0.0.0:8000/projects/1e7b2a91-2896-40fd-8d53-83db56088026/scan?scan_response_type=json' \
-H 'accept: application/json' \
-H 'Content-Type: multipart/form-data' \
-F '[email protected];type=application/zip'
C'est tout.
À un certain moment, il peut être nécessaire d'inclure de nouveaux outils de vérification dans le workflow de scan, afin de fournir une couverture plus large des normes IaC et des types de projets. Par conséquent, dans cette sous-section, une séquence d'étapes nécessaires à cette fin est identifiée et décrite. Cependant, les étapes doivent être effectuées manuellement comme décrit, mais il est prévu d'automatiser cette procédure à l'avenir via l'API et de fournir une interface conviviale qui aidera l'utilisateur lors de l'importation de nouveaux outils qui deviendront partie du catalogue disponible constituant le workflow de scan. La figure 16 illustre les étapes nécessaires pour étendre le workflow de scan avec un nouvel outil.
Étape 1 – Ajout d'une classe spécifique à l'outil dans le répertoire checks Tout d'abord, il est nécessaire d'ajouter une nouvelle classe Python spécifique à l'outil dans le répertoire checks du code source d'IaC Scan Runner : iac-scan-runner/src/iac_scan_runner/checks/new_tool.py La classe d'un nouvel outil hérite de la classe Check existante, qui fournit une généralisation des outils du workflow de scan. De plus, il est nécessaire de fournir une implémentation des méthodes suivantes :
Étape 2 – Ajout de l'instance de la classe d'outil de vérification dans le constructeur de ScanRunner Une fois la nouvelle classe dérivée de Check ajoutée au code source d'IaC Scan Runner, il est également nécessaire de modifier le code source de sa classe principale, appelée ScanRunner. En ce qui concerne les modifications de cette classe, il est d'abord nécessaire d'importer la classe spécifique à l'outil, de créer une nouvelle instance de classe d'outil de vérification et de l'ajouter au dictionnaire des vérifications IaC dans def init_checks(self). A. Importation de la classe d'outil de vérification from iac_scan_runner.checks.tfsec import TfsecCheck B. Création de la nouvelle instance de l'objet outil de vérification dans init_checks """Initiate predefined check objects""" new_tool = NewToolCheck() C. Ajout de celui-ci au dictionnaire self.iac_checks dans init_checks
self.iac_checks = {
new_tool.name: new_tool,
…
}
Étape 3 – Ajout de l'outil de vérification à la matrice de compatibilité dans la classe Compatibility D'autre part, dans le fichier src/iac_scan_runner/compatibility.py, le dictionnaire représentant la matrice de compatibilité doit également être étendu. Deux cas sont possibles : a) un nouveau type de fichier doit être ajouté comme clé, avec la liste des outils pertinents comme valeur ; b) un nouvel outil doit être ajouté à la liste de compatibilité pour le type de fichier existant.
compatibility_matrix = {
"new_type": ["new_tool_1", "new_tool_2"],
…
"old_typeK": ["tool_1", … "tool_N", "new_tool_3"]
}
Étape 4 – Prise en charge du résumé des résultats Enfin, la dernière étape de la séquence des modifications requises pour l'extension du workflow de scan consiste à modifier la classe ResultsSummary (src/iac_scan_runner/results_summary.py). Plus précisément, il est nécessaire d'ajouter une partie de code à sa méthode summarize_outcome qui recherchera des chaînes spécifiques, propres à l'outil, pouvant être utilisées pour identifier si la vérification a réussi ou échoué. Dans la boucle qui parcourt les vérifications compatibles, pour chaque nouvel outil, la structure if-else suivante doit être incluse :
if check == "new_tool":
if outcome.find("Check pass string") > -1:
self.outcomes[check]["status"] = "Passed"
return "Passed"
else:
self.outcomes[check]["status"] = "Problems"
return "Problems"
Ce travail est sous licence Apache License 2.0.
Vous pouvez contacter l'équipe xOpera en envoyant un e-mail à [email protected].
Ce projet a reçu un financement du programme de recherche et d'innovation Horizon 2020 de l'Union européenne dans le cadre de la convention de subvention n° 101000162 (PIACERE).