xlab-si/iac-scan-runnerServizio che scansiona la tua Infrastructure as Code per vulnerabilità comuni.
| Aspetto | Informazioni |
|---|
| Nome strumento | IaC Scan Runner |
| Immagine Docker | xscanner/runner |
| Pacchetto PyPI | iac-scan-runner |
| Documentazione | docs |
| Contattaci | [email protected] |
IaC Scan Runner è un servizio API REST utilizzato per scansionare pacchetti IaC (Infrastructure as Code) ed eseguire vari controlli del codice al fine di individuare possibili vulnerabilità e miglioramenti. Esplora la [documentazione] per maggiori informazioni.
Questa sezione spiega come eseguire l'API REST.
Puoi eseguire l'API REST utilizzando l'immagine Docker pubblica xscanner/runner come segue:
# run IaC Scan Runner REST API in a Docker container and
# navigate to localhost:8080/swagger or localhost:8080/redoc
$ docker run --name iac-scan-runner -p 8080:80 xscanner/runner
Oppure puoi creare l'immagine localmente ed eseguirla come segue:
# build Docker container (it will take some time)
$ docker build -t iac-scan-runner .
# run IaC Scan Runner REST API in a Docker container and
# navigate to localhost:8080/swagger or localhost:8080/redoc
$ docker run --name iac-scan-runner -p 8080:80 iac-scan-runner
Per eseguire utilizzando la CLI di IaC Scan Runner:
# install the CLI
$ python3 -m venv .venv && . .venv/bin/activate
(.venv) $ pip install iac-scan-runner
# print OpenAPI specification
(.venv) $ iac-scan-runner openapi
# install prerequisites
(.venv) $ iac-scan-runner install
# run IaC Scan Runner REST API
(.venv) $ iac-scan-runner run
Per eseguire localmente dal sorgente:
# Export env variables
export MONGODB_CONNECTION_STRING=mongodb://localhost:27017
export SCAN_PERSISTENCE=enabled
export USER_MANAGEMENT=enabled
# Setup MongoDB
$ docker run --name mongodb -p 27017:27017 mongo
# install prerequisites
$ python3 -m venv .venv && . .venv/bin/activate
(.venv) $ pip install -r requirements.txt
(.venv) $ ./install-checks.sh
# run IaC Scan Runner REST API (add --reload flag to apply code changes on the way)
(.venv) $ uvicorn src.iac_scan_runner.api:app
Questa parte mostrerà uno dei possibili deployment e brevi esempi su come utilizzare le chiamate API.
Per prima cosa cloneremo il repository iac scan runner ed eseguiremo l'API.
$ git clone https://github.com/xlab-si/iac-scan-runner.git
$ docker compose up
Dopo di che puoi utilizzare diversi endpoint API chiamando localhost:8000. Puoi anche navigare su localhost:8000/swagger o localhost:8000/redoc e testare tutti gli endpoint API lì. In questo esempio, useremo curl per chiamare gli endpoint API.
curl -X 'POST' \
'http://0.0.0.0/project?creator_id=test' \
-H 'accept: application/json' \
-d ''
Ci verrà restituito l'ID del progetto. Per questo esempio l'ID del progetto è 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'
Questo è tutto.
A un certo punto, potrebbe essere necessario includere nuovi strumenti di controllo nel workflow di scansione, con l'obiettivo di fornire una copertura più ampia degli standard IaC e dei tipi di progetto. Pertanto, in questa sottosezione, viene identificata e descritta una sequenza di passaggi necessari a tale scopo. Tuttavia, i passaggi devono essere eseguiti manualmente come descritto, ma si prevede di automatizzare questa procedura in futuro tramite API e fornire un'interfaccia user-friendly che assisterà l'utente durante l'importazione di nuovi strumenti che entreranno a far parte del catalogo disponibile che compone il workflow di scansione. La Figura 16 illustra i passaggi necessari da seguire per estendere il workflow di scansione con un nuovo strumento.
Step 1 – Aggiunta di una classe specifica per lo strumento nella directory checks
Innanzitutto, è necessario aggiungere una nuova classe Python specifica per lo strumento nella directory checks all'interno del codice sorgente di IaC Scan Runner:
iac-scan-runner/src/iac_scan_runner/checks/new_tool.py
La classe di un nuovo strumento eredita la classe Check esistente, che fornisce una generalizzazione degli strumenti del workflow di scansione. Inoltre, è necessario fornire l'implementazione dei seguenti metodi:
Step 2 – Aggiunta dell'istanza della classe dello strumento di controllo nel costruttore di ScanRunner Una volta che la nuova classe derivata da Check è stata aggiunta al codice sorgente di IaC Scan Runner, è necessario anche modificare il codice sorgente della sua classe principale, chiamata ScanRunner. Per quanto riguarda le modifiche di questa classe, è necessario prima importare la classe specifica dello strumento, creare una nuova istanza della classe dello strumento di controllo e aggiungerla al dizionario dei controlli IaC all'interno di def init_checks(self). A. Importazione della classe dello strumento di controllo from iac_scan_runner.checks.tfsec import TfsecCheck B. Creazione di una nuova istanza dell'oggetto strumento di controllo all'interno di init_checks """Initiate predefined check objects""" new_tool = NewToolCheck() C. Aggiunta al dizionario self.iac_checks all'interno di init_checks
self.iac_checks = {
new_tool.name: new_tool,
…
}
Step 3 – Aggiunta dello strumento di controllo alla matrice di compatibilità all'interno della classe Compatibility Dall'altra parte, all'interno del file src/iac_scan_runner/compatibility.py, anche il dizionario che rappresenta la matrice di compatibilità deve essere esteso. Ci sono due casi possibili: a) un nuovo tipo di file deve essere aggiunto come chiave, insieme alla lista degli strumenti rilevanti come valore; b) un nuovo strumento deve essere aggiunto alla lista di compatibilità per il tipo di file esistente.
compatibility_matrix = {
"new_type": ["new_tool_1", "new_tool_2"],
…
"old_typeK": ["tool_1", … "tool_N", "new_tool_3"]
}
Step 4 – Fornire il supporto per il riepilogo dei risultati Infine, l'ultimo passo nella sequenza di modifiche necessarie per l'estensione del workflow di scansione è modificare la classe ResultsSummary (src/iac_scan_runner/results_summary.py). Precisamente, è necessario aggiungere una parte di codice al suo metodo summarize_outcome che cercherà stringhe specifiche, tipiche dello strumento, che possono essere utilizzate per identificare se il controllo è stato superato o fallito. All'interno del ciclo che attraversa i controlli compatibili, per ogni nuovo strumento dovrebbe essere inclusa la seguente struttura if-else:
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"
Questo lavoro è concesso in licenza secondo i termini della Apache License 2.0.
Puoi contattare il team xOpera inviando un'email a [email protected].
Questo progetto ha ricevuto finanziamenti dal programma di ricerca e innovazione Horizon 2020 dell'Unione Europea nell'ambito del Grant Agreement No. 101000162 (PIACERE).