Lo standard della regola " allow "

Come prassi standard, il file della polizza Rego deve includere una regola “ allow ”. Nel contesto di questa pipeline, non si tratta solo di un suggerimento, ma di un requisito inderogabile.

Il motore della pipeline interroga specificatamente il valore booleano “ allow ” per prendere la decisione finale sull’esecuzione o meno della distribuzione. Se si sta fornendo una politica Rego personalizzata, è necessario definire esplicitamente questa regola. Se la regola " allow " non è presente, oppure se il suo risultato è " false", la pipeline si interrompe immediatamente, blocca la distribuzione e visualizza i messaggi di rifiuto definiti dall'utente.

Per garantire la massima sicurezza, OPA opera secondo un rigoroso modello “fail-closed”. La tua politica dovrebbe sempre essere impostata di default su “ false ” e diventare “ true ” solo se tutte le condizioni di conformità richieste sono soddisfatte.

package one_pipeline.config
# Default deny
default allow := false
# Allow only if your custom checks pass
allow {
    check_sast_scans_passed
    check_secrets_scans_passed
}

File delle politiche e file di convalida dei dati

Il file di policy (.rego)- La logica

Qui è dove si inseriscono le regole e le condizioni vere e proprie. Ad esempio, la vostra politica potrebbe stabilire: "Non autorizzare questa implementazione a meno che non sia stata completata una scansione delle vulnerabilità e i risultati non indichino l'assenza di problemi critici". È possibile specificare il proprio file di policy personalizzato utilizzando la proprietà dell'ambiente della pipeline policy-path . Se non viene specificato alcun file di policy, la pipeline utilizza il file di policy predefinito.

Il file di convalida dei dati (.json)- I fatti

Questo file funge da elenco di riferimento statico. Anziché inserire i dati in modo statico direttamente nelle regole Rego, questo file serve a gestire gli elenchi delle variabili approvate, come i registri di immagini consentiti (us.icr.io o eu.icr.io) o repository specifici esenti da determinati controlli. È possibile fornire il file di convalida dei dati utilizzando la proprietà dell'ambiente della pipeline “ evidence-checks-config-path ”. Se non viene fornito alcun file di convalida dei dati, la pipeline utilizza il file di convalida dei dati predefinito.

File di esempio per la convalida dei dati:

        package one_pipeline.config
        pre_deployment := {
            "com.ibm.prod_change_request": {
                "asset_type": [
                "*",
                "image"
                ],
                "source": [
                "prod",
                "stage"
                ],
                "target": [
                "prod",
                "stage"
                ],
                "recommended": [
                "*"
                ]
            }
        }
        post_deployment := {
            "com.ibm.prod_change_request": {
                "asset_type": [
                "*",
                "image"
                ],
                "source": [
                "prod",
                "stage"
                ],
                "target": [
                "prod",
                "stage"
                ],
                "recommended": [
                "*"
                ]
            }
        }

Ogni blocco della configurazione definisce esattamente quali prove sono richieste, da dove provengono e con quale rigore devono essere applicate.

• ID del tipo di prova (com.ibm.prod_change_request): la chiave di primo livello indica la categoria specifica della prova oggetto di valutazione. Tra gli esempi più comuni figurano com.ibm.static-scan, com.ibm.unit-tests o com.ibm.image_signing.
• asset_type: Definisce il tipo di artefatto a cui si applica questa regola. Ad esempio, potrebbe applicarsi solo a un image o a un repo. Utilizzando ["*"] , la regola viene applicata a tutti i tipi di asset.
• source (Ambienti di origine): Indica da dove provengono gli elementi di prova. Potrebbe trattarsi di un ramo specifico o di un ambiente di pipeline (ad esempio, ci-pipeline, stage, prod).
• target (Ambienti di destinazione): definisce l'ambiente di destinazione in cui questa prova viene convalidata in vista della distribuzione (ad es., stage, prod). Maggiori dettagli sull'ambiente di origine e su quello di destinazione sono disponibili qui.
• gating mode: Gli ultimi campi indicano la modalità di gating che si desidera applicare al tipo di prova. Maggiori informazioni sulle modalità di gating supportate sono disponibili qui.

Nota: tutti i controlli pre-distribuzione devono essere definiti nell'array pre_deployment :{}, mentre tutti i controlli post-distribuzione devono essere definiti nell'array post_deployment :{}. Inoltre, se si utilizza il percorso predefinito per i criteri, è necessario includere l'importazione del pacchetto " one_pipeline.config " nel file di registro per la convalida dei dati.

Lo script di conversione da JSON a Rego

Sebbene la pipeline supporti nativamente i file di convalida dei dati JSON legacy, potresti decidere in futuro di modernizzare le tue configurazioni passando al linguaggio nativo Rego, per adottare pienamente lo standard “policy-as-code”.

Per facilitare questa operazione, mettiamo a disposizione uno script di utilità autonomo che converte automaticamente i file di validazione dei dati JSON esistenti nel nuovo formato Rego.

Ubicazione script: /opt/one-pipeline/polyglot/polyglot/translate-pipeline-config.sh

Come utilizzare lo script di conversione

È possibile eseguire questo script localmente o nell'ambito di un'esecuzione della pipeline. Quando si esegue lo script in locale, è necessario specificare esplicitamente gli ambienti di destinazione e di origine.

# Convert a JSON config to Rego using named parameters
/opt/one-pipeline/polyglot/polyglot/translate-pipeline-config.sh \
  --input ./legacy-evidence-config.json \
  --output ./new-evidence-config.rego \
  --target-env prod \
  --source-env master

Configurazione flessibile: più file di convalida

Gli ambienti complessi richiedono spesso insiemi di regole modulari. A tal fine, la pipeline di convalida delle promozioni consente di valutare i dati a confronto con più configurazioni contemporaneamente.

È possibile fornire più file di convalida dei dati passando i relativi percorsi come elenco separato da virgole al parametro evidence-checks-config-path . In questo caso, la pipeline valuterà il payload delle prove rispetto a ciascun file di configurazione e genererà una tabella di valutazione separata per ogni file. Nella sezione dei commenti di PR vedrai le tabelle di valutazione relative a ciascun file sotto forma di commenti separati.

Feedback automatico sulle relazioni pubbliche

Per garantire la massima trasparenza, la pipeline valuta il payload delle prove correnti rispetto a ciascun file di configurazione fornito dall'utente. Una volta completata la valutazione, la pipeline genera automaticamente tabelle riassuntive e di valutazione dettagliate, aggiungendole direttamente alla PR.

Se si configurano più file di convalida dei dati, la pipeline pubblica i risultati relativi a ciascun file come commento separato alla richiesta di pull. Ciò offre ai revisori una panoramica chiara ed esaustiva dello stato di conformità nei diversi contesti, senza confondere i risultati.

All'interno di ogni commento PR, puoi trovare:

• Tre tabelle di valutazione: un'analisi dettagliata dei risultati della validazione. Per ulteriori informazioni su come interpretare queste tabelle, consultare la sezione “Come interpretare la tabella di verifica delle prove ”.
• Collegamenti alla configurazione: collegamenti diretti al file di convalida dei dati e al file delle politiche specifici utilizzati per eseguire quella precisa valutazione, che facilitano la verifica e la risoluzione dei problemi relativi alle regole.

Durante la fase di convalida della promozione, questa verifica di conformità OPA è finalizzata a garantire trasparenza e feedback. Se vengono rilevate violazioni delle tue regole, la pipeline non si interrompe né fallisce. La pipeline, invece, completa il proprio ciclo e pubblica i risultati dettagliati nel PR. Ciò garantisce che gli sviluppatori ricevano un rapporto completo su tutte le lacune di conformità e possano porvi rimedio senza che la compilazione si interrompa a metà del processo.

L'oggetto " table_results " (per feedback sulle relazioni pubbliche)

Per generare le tabelle dettagliate di Markdown nei commenti delle richieste di pull, la pipeline cerca una struttura dati specifica denominata table_results.

Se la tua policy restituisce un oggetto res all'interno di table_results contenente esattamente questi otto campi, la pipeline subentra. Analizza in modo sicuro i tuoi dati di output e li trasforma automaticamente nella tabella pulita e dettagliata Markdown che vedi nel PR:

table_results contains res if {
    # ... your custom evaluation logic goes here ...
    
    # Map your findings to the contract structure
    res := {
        "RuleType":       "Required",       
        "AssetType":      "image",          
        "AssetId":        "12345678",      
        "EvidenceTypeId": "com.ibm.scan",   
        "Tool":           "zap",         
        "Status":         "failure",        
        "Source":         "ci-pipeline",    
        "Target":         "prod",           
    }
}

La regola " allow " (per l'esecuzione in pipeline)

Come accennato in precedenza, la seconda parte obbligatoria del presente contratto è la regola “ allow ”.

Perché è necessario?

Mentre table_results gestisce la segnalazione dei controlli di conformità, la regola allow costituisce l'effettivo "kill switch" della pipeline. Il motore della pipeline è programmato in modo rigido per interrogare il valore booleano " allow " al fine di determinare la decisione finale "Go/No-Go".

Se si fornisce un file di policy personalizzato ma si dimentica di includere la regola " allow ", la pipeline non sa come procedere. Operando secondo un rigoroso modello di sicurezza “fail-closed”, per impostazione predefinita interrompe l'esecuzione della pipeline e blocca la distribuzione.

Abilitazione di OPA

Per abilitare il controllo di conformità basato su OPA nelle pipeline CD e CC, è necessario attivare esplicitamente il flag “ opt-in-rego-translation ” (impostandolo su true o 1).

Vincoli di configurazione

Proprio come nella pipeline di promozione, è possibile fornire sia un file di policy (la propria logica) sia un file di convalida dei dati (i propri dati). Tuttavia, c'è una differenza fondamentale: le pipeline CD e CC attualmente accettano solo un file di convalida dei dati alla volta, anziché un elenco separato da virgole.

Allegati alle richieste di modifica (CR) e fasi finali della pipeline

Quando si esegue la pipeline CD, il motore elabora il file di convalida dei dati e lo allega alla richiesta di modifica a fini di audit. Il comportamento degli allegati dipende interamente dal formato che si specifica:

• Se si fornisce un file di convalida dei dati JSON di vecchia generazione: la pipeline lo converte automaticamente in background. Sia il file JSON originale che il file di configurazione Rego generato sono allegati alla fase "Richiesta di modifica".
• Se si fornisce un file di convalida dei dati Rego nativo: la pipeline allega direttamente solo il file Rego fornito.

Questo stesso comportamento di associazione si applica anche al processo di ricostruzione della configurazione che avviene durante la fase "CD Finish", proprio alla fine della pipeline.