AvanzateDevSecOps personalizzazione della pipeline

Scoprite le caratteristiche avanzate dell'adozione di DevSecOps dopo l'avvio della vostra prima applicazione o microservizio.

Assicurati di rivedere il basi diDevSecOps personalizzazione della pipeline. Lì puoi conoscere i diversi modelli disponibili, le opzioni di supporto e altre informazioni importanti per iniziareDevSecOps.

Scelte di progettazione

Durante l'onboarding di più applicazioni e microservizi suDevSecOps, potresti avere le seguenti domande sulla progettazione:

Ho bisogno di una toolchain per microservizio?
Ho bisogno di una pipeline per microservizio?
Devo usare un file sharedDevSecOps repository per inventario e problemi o ho bisogno di repository separati?

Le seguenti informazioni e best practice sono pensate per aiutarti a fare queste scelte di progettazione.

Considerazioni su toolchain e pipeline

La maggior parte delle applicazioni sono composte da più microservizi con diversi repository di origine. Generalmente, una singola toolchain viene utilizzata per ospitare i microservizi raggruppati logicamente. In generale, utilizza una toolchain e una pipeline, o il minor numero di pipeline possibile, ma più trigger. All'interno di ogni pipeline, puoi duplicare e configurare tutti i trigger di cui hai bisogno, fino a 1024 trigger per pipeline. Questa strategia consente di applicare processi, script e file di configurazione comuni. Per ulteriori informazioni, vedi Configurazione di più applicazioni su una toolchain CI.

Questo approccio presenta i seguenti vantaggi:

L'utilizzo di un numero inferiore di pipeline evita la duplicazione e riduce gli errori. Gli aggiornamenti sono anche più semplici da gestire, ad esempio, quando una proprietà dell'ambiente o un segreto viene aggiunto, modificato o eliminato.
L'onboarding di un servizio è più rapido con questo approccio. Aggiungi un'integrazione Git per il tuo microservizio, duplica il Git e i trigger manuali e modificali come necessario. Quindi, assicurati che i tuoi file e script .pipeline-config.yaml siano implementati per il tuo microservizio.

Questo approccio presenta i seguenti svantaggi:

Una modifica può avere un impatto su ogni team che utilizza la stessa pipeline.
L'accesso utente viene gestito utilizzando Identity and Access Management e viene impostato a livello di toolchain, non a livello di pipeline. Quindi, se stai utilizzando una singola toolchain per più servizi, ogni membro del team può visualizzare le pipeline di altri team. A seconda dell'accesso dell'utente in IAM, potrebbe essere in grado di modificare, eliminare o attivare una pipeline.

Considerazioni sulla fatturazione

Il servizio Continuous Delivery determina la fatturazione in base al numero di utenti autorizzati per istanza CD e al numero di gruppi di risorse utilizzati per le catene di strumenti. Anche gli utenti che hanno accesso ai repository sono considerati utenti autorizzati. Per ulteriori informazioni, vedi Utenti autorizzati. Per ridurre i costi, è necessario organizzare tutte le catene di strumenti nello stesso gruppo di risorse oppure configurare la fatturazione consolidata Continuous Delivery all'interno di una gerarchia di account aziendali. Per ulteriori informazioni, vedere Fatturazione consolidata.

DevSecOps considerazioni sui repository

Se stai creando un'applicazione composta da più microservizi, la maggior parteDevSecOps i repository, ad eccezione del repository delle prove, possono essere condivisi tra i microservizi.

Per ulteriori informazioni, vedere ComeDevSecOps le pipeline utilizzano repository.

Considerazioni sul repository di configurazioni condiviso

ILDevSecOps le applicazioni di esempio vengono fornite con un file .pipeline-config.yaml file di configurazione e script corrispondenti. Quando si eseguono l'onboarding di più microservizi, è consigliabile separare i repository del codice sorgente daDevSecOps file di configurazione e script. Memorizzarli in un repository di configurazione comune separato e dedicato che può essere utilizzato dalle pipeline CI, CD o CC.

Si tratta di:

Un repository Git dedicato per ospitare una libreria di script comune e.pipeline-config.yaml file.
Un singolo file.pipeline-config.yaml comune a tutti i servizi. Se è troppo complesso o non è possibile, utilizzare filepipeline-config.yaml differenti.
Personalizzazione per cartella. Implementa i file.pipeline-config.yaml per puntare a diverse cartelle di script nel tuo repository di configurazione. Organizzare gli script in cartelle CI, CD e CC separate o in base al linguaggio del servizio (Go, Python, NodeJS), al servizio, al nome dell'applicazione o a quello più adatto alle proprie esigenze.

Modifica la/e pipeline per utilizzare questo repository di configurazione condiviso impostando il valore della proprietà pipeline pipeline-config-repo (facoltativamente, pipeline-config-branch ) sul repository di configurazione condiviso URL.

Considerazioni sul repository dell'inventario

Un singolo repository di inventario può essere condiviso tra molte pipeline e toolchain. Diverse toolchain CI, pipeline e trigger possono contribuire allo stesso repository di inventario. Le pipeline CI inseriscono gli aggiornamenti nel repository di inventario, di norma durante la fase di rilascio. Il repository di inventario viene quindi utilizzato come input di origine per la pipeline CD. In generale, è consigliabile raggruppare i repository di inventario nella stessa toolchain per ridurre il numero di richieste di modifica eventualmente create.

L'utilizzo di un repository di inventario condiviso è una decisione architetturale che deve essere presa prima di avviare l'onboarding dei microservizi perché questa decisione influisce sul numero di richieste di modifica create quando viene eseguita una pipeline. Ad esempio, supponiamo che tu voglia integrare 10 microservizi inDevSecOps. È possibile avere 10 diverse toolchain CD, con 10 diversi repository di inventario, che si traduce in 10 diverse richieste di modifica ogni volta che viene eseguita una pipeline CD. È più facile gestire questi 10 diversi microservizi se condividono un repository di inventario comune e una toolchain CD comune. Ciò risulta in una sola richiesta di modifica anche se effettui aggiornamenti a più microservizi perché condividono tutti il repository di inventario e la toolchain.

Considerazioni sul repository dei problemi

Il tuo repository di problemi è dove vengono tracciati tutti i problemi di vulnerabilità per i tuoi microservizi. Se si decide di utilizzare un repository di inventario condiviso, è possibile utilizzare anche un repository di problemi condivisi.

L'impostazione di incident-assigness e incident-labels a livello di pipeline o trigger consente di assegnare automaticamente issus al team corretto. Per ulteriori informazioni, vedi Parametri di distribuzione continua.

Considerazioni su IBM Cloud Object Storage

Se si utilizza un repository di inventario condiviso, si può utilizzare anche un'istanza condivisa di IBM Cloud® Object Storage. Completa i seguenti passi:

Crea un'istanza di IBM Cloud Object Storage da utilizzare tra toolchain e pipeline.
Configura le pipeline e i trigger, se applicabili, per utilizzare il bucket IBM Cloud Object Storage impostando la proprietà di ambiente cos-bucket-name.

Tutti i microservizi all'interno delle stesse pipeline CI, CD e CC condividono un unico bucket Object Storage, indipendentemente dall'ambiente di distribuzione. Il bucket Object Storage funziona in modo simile al deposito di prove, ma senza i problemi di prestazioni che possono verificarsi con un deposito di prove sostanziale. Dato che i problemi di prestazioni non si verificano con un bucket Object Storage consistente, non è necessario eliminare le prove dai bucket Object Storage.

Object Storage granularità del secchio

DevSecOps non si preoccupa della granularità dei bucket Object Storage. Tecnicamente, si potrebbe utilizzare un unico bucket Object Storage per tutta l'organizzazione. Tuttavia, la granularità non dovrebbe essere inferiore a quella di un inventario, poiché l'inventario è il più piccolo raggruppamento logico di microservizi che possono muoversi insieme.

In pratica, la granularità dipende dal modello operativo che il team di conformità desidera per la gestione dei dati di conformità:

Se il team di conformità è in grado di gestire più bucket Object Storage con dati compartimentati, si tratta di un modello valido.
Se si preferisce gestire un unico bucket Object Storage più grande con dati non suddivisi, è possibile farlo.

Una considerazione fondamentale: il bucket Object Storage (armadietto delle prove) è destinato a essere leggibile dal sistema, non dall'uomo. Non supporta, e per il prossimo futuro non supporterà, strutture di cartelle organizzate per repository, microservizi, prodotti o organizzazioni. Rimane una struttura appiattita di beni ed evidenze.

Considerazioni sulla sicurezza e sull'accesso

I bucket Object Storage meno granulari aumentano il raggio d'azione in caso di violazione della sicurezza (ad esempio, l'esposizione di una chiave API Object Storage ). Può anche creare problemi di visibilità incrociata, in cui un prodotto verticale potrebbe potenzialmente leggere i dati di conformità di un altro se condividono lo stesso bucket.

Considerazioni sulla migrazione

Esistono modi per migrare tra i bucket di Object Storage, se necessario. In genere si tratta di configurare alcune proprietà dell'ambiente per un bucket di backup Object Storage e di ricostruire i componenti del CI. Per ulteriori informazioni, consultare la presente documentazione. Tuttavia, queste operazioni sono intese come attività di migrazione una tantum, non come parte dei flussi di lavoro operativi quotidiani.

Approccio consigliato

Utilizzate un bucket Object Storage per ogni gruppo logico di prodotti i cui dati di conformità devono essere spostati insieme. Ad esempio:

La squadra di servizio A (comprese tutte le squadre al suo interno) condivide Object Storage Secchio A
La squadra di servizio B (comprese tutte le squadre al suo interno) condivide Object Storage Bucket B

Questo approccio bilancia la semplicità operativa con i requisiti di sicurezza e controllo degli accessi.

Distribuzione in più ambienti

La distribuzione in più ambienti di destinazione con la pipeline CD può essere eseguita in diversi modi.

Ogni targeted environment deve avere un ramo corrispondente nel repository di inventario, in cui le modifiche vengono promosse da un ramo source a un ramo target.

Le seguenti progettazioni facoltative potrebbero adattarsi alla tua architettura:

Utilizzare un trigger manuale per ambiente di destinazione. Duplicare un trigger, quindi modificare le proprietà dell'ambiente per adattarle al nuovo ambiente.
Utilizzare un repository di configurazione Git con una cartella per ambiente di destinazione, in cui le impostazioni di configurazione specifiche sono memorizzate in file.

Utilizzo degli script predefiniti e personalizzati

La maggior parte degli script di sicurezza e conformità vengono forniti con script predefiniti eseguiti se non vengono forniti script personalizzati per uno stage. A volte può essere difficile determinare quale script viene eseguito, dove trovare lo script di origine corrispondente e come sovrascrivere gli script predefiniti.

Identificare lo script da eseguire

Per identificare quale script viene eseguito per una fase, aprire l'esecuzione della pipeline (preferibilmente una pipeline CI). Espandere un'attività, quindi fare clic su run-stage per aprire i log. L'inizio dei file di log run-stage fornisce informazioni sugli script utilizzati nello stage, incluso il repository in cui si trova lo script. Nei log, è possibile scorrere per trovare ulteriori dettagli sugli script eseguiti. Ad esempio, l'attività code-compliance-checks potrebbe avere le seguenti informazioni nel log run-stage, che include le proprietà di ambiente per lo stage:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

In questo esempio, lo script eseguito è /opt/commons/compliance-checks/run.sh, che si trova nella libreria commons. Utilizzare questa libreria comune come origine per copiare il codice che può essere personalizzato per casi limite specifici. Nell'esempio, compliance-checks/run.sh si trova nella libreria compliance - commons.

Sovrascrittura degli script predefiniti

Per sovrascrivere gli script predefiniti, completare la seguente procedura:

Nel log della fase, copiare lo snippet che identifica uno script predefinito:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script:
    #!/bin/sh

    "/opt/commons/compliance-checks/run.sh"

Incollare il frammento nel file .pipeline-config.yaml.
Aggiungere il codice personalizzato prima o dopo il richiamo dello script. Questo frammento richiama lo script di controllo della conformità predefinito
Modificare, eliminare o aggiungere le proprietà in base alle necessità.

Il seguente esempio mostra lo script aggiornato nel file .pipeline-config.yaml:

compliance-checks:
  image: icr.io/continuous-delivery/pipeline/pipeline-base-ubi:3.18
  dind: true
  abort_on_failure: false
  image_pull_policy: IfNotPresent
  script: |
    #!/bin/sh
    # run some custom script here
    ./scripts/my-custom-script1.sh

    "/opt/commons/compliance-checks/run.sh"

    # then some additional work
    ./scripts/my-custom-script2.sh

Per ulteriori informazioni, consultare Script personalizzati.

Modelli Terraform da utilizzareDevSecOps toolchain-come-codice

Le seguenti toolchain forniscono il codice da creareDevSecOps Toolchain CI, CD e CC utilizzando Terraform:

L'accesso anticipato a queste toolchain Terraform è stato fornito così com' è. Queste toolchain sono in fase di sviluppo attivo, quindi le variabili e i nomi delle variabili potrebbero cambiare.