FAQ per DevSecOps

Trova le risposte alle domande più frequenti sull'utilizzo di DevSecOps.

Qual è la differenza tra pipeline CI e CC?

Si può notare che la pipeline CI e CC hanno dei passaggi comuni. Le scansioni e i controlli eseguiti sono simili per natura e dettagli. La tabella seguente illustra le differenze tra le pipeline CI e CC.

Differenze nelle pipeline CI e CC
Conduttura CI Conduttura CC
Fa parte della catena di strumenti CI. Fa parte della catena di strumenti CC.
Viene attivata dopo che una richiesta di fusione viene unita al ramo master Può essere attivata manualmente o a intervalli predefiniti, indipendenti da un programma di distribuzione.
L'applicazione URL e i dettagli del repository del codice dell'applicazione vengono inseriti come parte del processo di configurazione. Un'applicazione URL e i dettagli del codice applicativo sono forniti dopo la configurazione della catena di strumenti CC e prima dell'avvio della prima esecuzione della pipeline.
I problemi di incidente che vengono creati come parte di varie scansioni e verifiche durante i controlli di conformità non hanno una data di scadenza. I problemi di incidente creati nell'ambito delle varie scansioni e verifiche durante i controlli di conformità hanno una data di scadenza.
I problemi di incidenti creati vengono rilevati durante la compilazione. Gli incidenti creati vengono rilevati durante le scansioni periodiche dell'ambiente di staging o di produzione.
Il file summary.json non viene generato alla fine di ogni esecuzione della pipeline CI. Il file summary.json non viene generato alla fine di ogni esecuzione della pipeline CI.
Include fasi come la creazione di artefatti applicativi, la firma degli artefatti e il deploy sul cluster di sviluppo. Questo crea a sua volta gli input per la pipeline CD. Esegue solo le scansioni e i controlli necessari per i test di conformità.

Come può un utente personalizzare la pipeline?

Una pipeline viene personalizzata con l'uso di script personalizzati. Gli script personalizzati sono punti di estensione nella pipeline in cui gli adottanti, i team e gli utenti possono fornire script per eseguire attività personalizzate per le loro strategie CI/CD.

Gli script personalizzati controllano le fasi della pipeline. Si può usare un file di configurazione (pipeline-config.yaml) per configurare il comportamento degli stage, il contenuto degli script e l'artefatto di base che esegue gli script. Gli script e la configurazione delle fasi della pipeline vengono caricati da un repository dell'applicazione simile a .travis.yml o Jenkinsfile o da un repository personalizzato.

Per ulteriori informazioni, vedere Personalizzazione delle pipeline mediante script personalizzati.

Immagine multi-arch per le limitazioni delle piattaforme s390x e Power

One-Pipeline fornisce il supporto nativo per le piattaforme s390x e Power utilizzando runtimeClassName (una stringa che indica il profilo di runtime) nel file di configurazione di One-Pipeline. Tuttavia, questo supporto nativo comporta alcune limitazioni e raccomandazioni:

  • Limitazioni:
    • Questa funzione è disponibile solo su v11.
    • Il tempo di avvio del pod è superiore a quello della classe runtime x86.
    • È necessario utilizzare podman con i carichi di lavoro s390x o Power. Docker non è disponibile.
      • Gli script utente devono essere aggiornati per funzionare con il comando podman invece che con il comando docker
      • L'immagine dello stage dovrebbe avere podman installato.
  • Raccomandazioni: utilizzare le classi di runtime di x86 per
    • scansione, poiché le immagini dei vari strumenti di scansione potrebbero non supportare il multiarco.
    • firma dell'immagine, poiché non è disponibile il supporto multi-arch (lavoro in corso).

Come posso creare un'immagine di base personalizzata per più architetture?

One Pipeline fornisce un'immagine di base ufficiale multi-architettura che supporta le seguenti piattaforme:

  • linux/amd64
  • linux/ppc64le
  • linux/s390x

Per la maggior parte dei casi d'uso, consigliamo di utilizzare direttamente l'immagine di base ufficiale:

icr.io/continuous-delivery/toolchains/devsecops/baseimage:<version>

Se la tua applicazione richiede pacchetti aggiuntivi del sistema operativo, runtime linguistici o altre dipendenze personalizzate, puoi creare la tua immagine di base multi-architettura personalizzata nell'ambito della tua pipeline di CI.

Utilizza Docker Buildx con l'opzione --platform nel tuo passaggio build-artifact :

docker buildx build \
  --platform linux/amd64,linux/ppc64le,linux/s390x \
  -t <registry>/<namespace>/<image>:<tag> \
  --push .

Questo processo crea immagini specifiche per ciascuna architettura e le pubblica sotto forma di un unico manifesto di immagini multi-architettura. I runtime dei container scaricano automaticamente l'immagine appropriata per la piattaforma di destinazione.

Approccio consigliato

  1. Utilizza l'immagine di base One Pipeline come immagine " FROM " nel tuo Dockerfile.
  2. Aggiungi solo i pacchetti o le dipendenze aggiuntive richiesti dalla tua applicazione.
  3. Compila e pubblica l'immagine utilizzando Buildx di Docker nella tua pipeline di CI.
  4. Verifica l'immagine pubblicata utilizzando docker buildx imagetools inspect o skopeo inspect.

Per ulteriori informazioni sul supporto multi-architettura e sulle limitazioni, consultare la sezione " Limitazioni delle immagini multi-architettura per le piattaforme s390x e e Power ".

Avvio della pipeline tramite CLI

Una pipeline può essere attivata utilizzando la CLI di IBM Cloud o un'API. Con la CLI è possibile avviare una pipeline fornendo gli ID della toolchain e della pipeline. Utilizzando l'API, è possibile inviare una richiesta POST con l'autenticazione e le intestazioni corrette per attivare la pipeline.

Per ulteriori informazioni, vedere Uso dei trigger

Quale proprietà dell'ambiente viene utilizzata per la clonazione dei repository Git?

Le pipeline di DevSecOps utilizzano un sistema di token gerarchico per autenticare le operazioni sul repository di Git, compresa la clonazione. La proprietà di ambiente git-token funge da token predefinito, ma è possibile sovrascriverla con token più specifici per garantire una maggiore sicurezza e un controllo degli accessi più efficace.

Ordine di priorità dei token

La pipeline risolve i token di autenticazione Git secondo il seguente ordine di priorità (dal più alto al più basso):

  1. Token di accesso personale (PAT) specificato nell'integrazione della toolchain per un repository specifico
  2. Token specifico del repository: git-token-[repo_name]-[repo_org]
  3. Token specifico dell'organizzazione: git-token-[repo_org]
  4. Token predefinito: git-token
  5. OAuth token derivante dall'integrazione della toolchain (se si utilizza l' OAuth e anziché il PAT)

Esempi di denominazione dei token

Per un repository all'indirizzo https://github.com/my-org/my-app:

  • Specifico per il repository: git-token-my-app-my-org
  • Specifico per l'organizzazione: git-token-my-org

Considerazioni importanti

  • Se lo stesso git-token viene utilizzato sia per le operazioni di lettura dei repository (clonazione) che per quelle di scrittura (impostazione dello stato PR/CI, aggiornamento dell'inventario), l'accesso in sola lettura non è sufficiente. Il token deve disporre dei diritti di scrittura.
  • L'uso di token specifici per il repository o per l'organizzazione consente di applicare il principio del privilegio minimo, concedendo solo le autorizzazioni necessarie per ciascun repository.

Per ulteriori informazioni sulle funzioni dei token del repository, consultare la sezione " Recupero delle informazioni e dei token del repository ".

Come verificare le modifiche apportate alla configurazione di OnePipeline?

Per testare le modifiche apportate alla configurazione di OnePipeline è necessario adottare un approccio sistematico, al fine di evitare di compromettere le pipeline di produzione durante la verifica delle personalizzazioni.

Comprendere i componenti dell' OnePipeline

OnePipeline è composto da due componenti principali personalizzabili:

  • Definizioni delle pipeline Tekton: definizioni delle pipeline gestite centralmente per i flussi di lavoro PR, CI, CD e CC, disponibili nel repository compliance-pipelines. Le nuove versioni vengono pubblicate ogni due settimane.

    • v10: Versione stabile con concorrenza limitata
    • v11: versione di nuova generazione con massima personalizzazione e capacità di gestione del carico di lavoro

  • Configurazione della pipeline (.pipeline-config.yaml): file di configurazione personalizzato che sovrascrive i comportamenti predefiniti della pipeline, incluse immagini, script, architetture e proprietà della pipeline. Questo file può essere salvato nel repository dell'applicazione o in un repository di configurazione centralizzato.

Metodo di test 1: utilizzo di un file di configurazione di test

Questo è l'approccio consigliato per testare le modifiche alla configurazione senza influire sulle pipeline di produzione.

  1. Crea un ramo di test

    • Crea un ramo nel repository contenente il tuo file .pipeline-config.yaml
    • Apporta le modifiche alla configurazione in questo ramo

  2. Configurare un trigger di prova

    • Duplica il trigger della pipeline esistente nella tua catena di strumenti
    • Assegnagli un nome chiaro (ad esempio, Manual-Test-Config)
    • Aggiorna le proprietà del trigger in modo che rimandino alla tua configurazione di test:
      • pipeline-config: Nome del file di configurazione
      • pipeline-config-branch: Il nome del tuo ramo di test
      • pipeline-config-repo: Repository URL contenente la configurazione

  3. Prova in modalità di sviluppo

    • Attiva la modalità di sviluppo nelle proprietà del trigger
    • Esegui la pipeline per verificare i tuoi script personalizzati
    • La modalità di sviluppo salta le fasi di raccolta delle prove, creazione dei problemi di conformità e aggiornamento dell'inventario, rendendola ideale per iterazioni rapide
    • Importante: la modalità di sviluppo non è adatta ai carichi di lavoro di produzione

  4. Test con verifiche di conformità

    • Dopo aver verificato gli script in modalità sviluppo, disattivare dev-mode
    • Disattivare gli aggiornamenti dell'inventario durante i test
    • Eseguire un processo completo che comprenda la raccolta delle prove e la gestione dei problemi
    • Verificare che tutti i controlli di conformità abbiano esito positivo come previsto

  5. Promozione alla produzione

    • Una volta che i test hanno dato esito positivo, crea una pull request per integrare le tue modifiche nel ramo principale
    • Le modifiche verranno applicate automaticamente ai trigger di produzione
    • In caso di problemi, è possibile annullare rapidamente le modifiche

Metodo di verifica 2: Modifica della struttura della pipeline

Definizioni delle pipeline di biforcazione (livello avanzato)

  • (Crea un fork del repository compliance-pipelines )
  • Sviluppa e testa le modifiche nel tuo fork
  • Aggiungi il repository forkato come integrazione di Git nella tua catena di strumenti
  • Modifica temporaneamente la definizione della pipeline in modo che faccia riferimento al tuo fork
  • Configurare un trigger in modalità di sviluppo per testare la nuova definizione della pipeline
  • Seguire la procedura di verifica descritta nell'approccio 1

Procedure consigliate

  • Prova sempre prima in modalità di sviluppo per individuare rapidamente eventuali errori negli script
  • Utilizza nomi descrittivi per i trigger di test per evitare confusione
  • Documenta le modifiche apportate alla configurazione nei messaggi di commit
  • Disattiva i trigger di test oppure eliminali al termine dei test per evitare esecuzioni accidentali
  • Si consiglia di creare una catena di strumenti di test dedicata per le modifiche significative alla pipeline
  • Esaminare attentamente i log della pipeline per assicurarsi che tutte le fasi vengano eseguite come previsto

Per ulteriori informazioni sulla personalizzazione delle pipeline, consultare la sezione " Script personalizzati " e