Utilizzo dei bucket IBM Cloud Object Storage come locker delle prove

È possibile configurare i bucket IBM Cloud Object Storage (COS) per archiviare le prove generate dai controlli di conformità integrati nelle DevSecOps pipeline. La prova di conformità crea la traccia di controllo che i revisori cercano durante una verifica di conformità. Uno degli obiettivi di DevSecOps è la generazione automatizzata di prove e la loro archiviazione in archivi verificabili. Per ulteriori informazioni, consultare locker delle prove.

La pipeline di automazione della conformità memorizza le seguenti informazioni nel bucket COS:

Risorse utente attività
Risultati del test, risultati della scansione o qualsiasi output salvato dalle attività.
Log attività
Dopo l'esecuzione della pipeline, i log per tale esecuzione vengono inviati al locker delle prove.
Prova
Informazioni sulle attività e il relativo output di risultato, che può essere un errore o un esito positivo. Per ulteriori informazioni sul formato della prova inviata, vedi Riepilogo della prova.

Configurazione del bucket

Prima di impostare una toolchain di integrazione continua o di distribuzione continua, è necessario creare un'istanza cloud Object Storage dedicata. Questo bucket COS viene utilizzato per l'archivio correlato alla conformità poiché gli archivi delle prove devono essere creati in limite alle tue applicazioni. Questo aiuta a migliorare la resilienza della tua pipeline. Per ulteriori informazioni, vedi Resilienza.

Per configurare il tuo bucket Object Storage cloud per agire come un locker delle prove di conformità come parte di una pipeline di integrazione continua o di distribuzione continua, puoi utilizzare le seguenti informazioni come una guida. Gli script del template della pipeline o della toolchain non configurano il locker nel cloud Object Storage.

Fare riferimento a questa pagina per ulteriori informazioni sulle considerazioni (granularità, sicurezza,...) per l'utilizzo di Cloud Object Storage per le prove di conformità.

Politica di conservazione

Puoi impostare i bucket Object Storage cloud per applicare una politica di conservazione o un periodo per gli oggetti caricati, altrimenti noti come Immutable Object Storage. Immutable Object Storage preserva i record elettronici e mantiene l'integrità dei dati. Le politiche di conservazione garantiscono che i dati siano archiviati secondo il principio "Write-One-Read-Many" (WORM), in modo da renderli non cancellabili e non riscrivibili. Non è possibile modificare o eliminare gli oggetti nei bucket protetti entro il periodo di conservazione oppure eliminare i bucket protetti con gli oggetti fino al termine del periodo di conservazione. La politica rimane in vigore fino al termine del periodo di conservazione e alla revoca di eventuali blocchi legali.

Si consiglia ai team di impostare una politica di conservazione per i bucket utilizzati come locker delle prove che memorizza ogni oggetto per un minimo di 365 giorni.

Autorizzazioni di accesso bucket

Quando si utilizzano i Cloud Pipeline nell'ambiente dell' DevSecOps, oggetti come prove, riepiloghi di prove e artefatti vengono convogliati o letti dai Bucket nell' IBM Cloud Object Storage. Gli strumenti non creano, aggiornano, eliminano o modificano oggetti o bucket.

Per garantire un accesso sicuro ai vostri bucket di cloud- Object Storage, facilitando al contempo le necessarie operazioni di pipeline, seguite queste politiche di accesso:

  • Lettore.

    1. Questa autorizzazione garantisce che le pipeline CD ( Continuous Delivery ) possano verificare le impostazioni di ritenzione della benna senza modificare alcun dato.
    2. Necessario per leggere le prove generate dalla pipeline CI

  • Object Writer.

    1. Questa autorizzazione consente alle pipeline di integrazione continua (CI), CD e controllo della configurazione (CC) di caricare o scrivere nuovi oggetti nei bucket.

Procedura per la creazione delle credenziali di servizio

Per accedere al tuo bucket COS utilizzando Cloud Pipelines:

  1. Vai a Credenziali di servizio:
  2. Creare una nuova credenziale:
    • Fare clic su "Crea" e seguire le istruzioni per creare una nuova credenziale di servizio per il bucket COS.

Passaggi per assegnare l'accesso ai secchi COS

Per assegnare le autorizzazioni di accesso appropriate ai bucket COS:

  1. Vai a Autorizzazioni IAM per i bucket:
  2. Assegnare ruoli e politiche:
    • Assegna il ruolo di Lettore alle pipeline CD per il controllo delle politiche di conservazione.
    • Assegna il ruolo di Object Writer alle pipeline CI, CD e CC per la scrittura delle prove nei bucket.

Quando si utilizza il bucket Object Storage Cloud come archivio delle prove, le autorizzazioni consigliate sono Lettura e Scrittura oggetti. È opportuno evitare autorizzazioni con privilegi più elevati (ad esempio, accesso di livello amministrativo) per evitare modifiche accidentali o dolose dei propri oggetti.

Classi di archiviazione

I costi variano per i team con diverse configurazioni e frequenza di distribuzione. Non si consiglia di utilizzare il livello gratuito come bucket Cloud Object Storage perché il livello gratuito non può essere configurato per essere immutabile.

Stima campione

Se si sta utilizzando un'integrazione continua di riferimento o una pipeline di distribuzione continua con sei prove in ciascuna, una singola coppia di esecuzione di integrazione continua e distribuzione continua effettua 37 richieste di classe A e sei richieste di classe B.

  • L'integrazione continua scrive sei log, sei risorse utente e sei prove, che equivalgono a 18 PUT - Classe A.
  • La distribuzione continua legge sei prove (sei GET - Classe B), scrive sei prove, sei log, sei risorse utente e un riepilogo, che equivale a 19 PUT - Classe A.

Con una media di cinque microservizi (cinque x integrazione continua) e quattro regioni di distribuzione (quattro x distribuzione continua), una distribuzione completa equivale a 166 richieste di classe A e 24 di classe B.

Con una distribuzione completa alla settimana (quattro al mese), puoi calcolare 664 richieste di classe A e 96 richieste di classe B al mese.

La quantità di dati raccolti varia in base al caso di utilizzo. Con le dimensioni medie per le prove (1 kB), le risorse di test (100 kB) e i log (15 kB), è possibile calcolare 0.01 GByte di dati creati e trasferiti al mese.

Resilienza

Si consiglia di utilizzare la resilienza Cross-Region o Regional, se deve essere conservata in - boundary. Per ulteriori informazioni su queste regioni, vedi Endpoint e ubicazioni di memoria.

Nome bucket

I nomi bucket cloud Object Storage devono essere globalmente univoci e conformi a DNS. I nomi devono avere una lunghezza compresa tra 3 e 63 caratteri e devono contenere lettere minuscole, numeri e trattini. I nomi bucket devono iniziare e terminare con una lettera minuscola o un numero. I nomi che assomigliano agli indirizzi IP non sono consentiti. I nomi bucket sono univoci in tutto il sistema IBM Cloud Object Storage e non possono contenere alcuna informazione personale, come ad esempio qualsiasi parte di un nome o indirizzo, o finanziaria, account di sicurezza o SSN.

I nomi bucket devono essere univoci in quanto tutti i bucket nel cloud pubblico condividono uno spazio dei nomi globale. Questo requisito consente di accedere a un bucket senza dover fornire alcuna informazione relativa all'istanza del servizio o all'account. Non è inoltre possibile creare un bucket il cui nome inizi con " cosv1- " o "account-", poiché tali prefissi sono riservati dal sistema.

Endpoint

Utilizza gli endpoint private per la maggior parte delle richieste che hanno origine dall'interno di IBM Cloud® e utilizza gli endpoint public per la maggior parte delle richieste che hanno origine dall'esterno IBM Cloud®. Per ulteriori informazioni, consultare Tipi di endpoint.

Per le pipeline che sono in esecuzione nella regione di Londra, utilizza gli endpoint direct a causa dell'infrastruttura di lavoro gestita dalla pipeline.

Configurazione delle catene di utensili con la benna COS

Per archiviare prove, risorse e allegati, configura il bucket COS nelle tue pipeline. Poiché questa benna viene utilizzata per recuperare le informazioni esistenti, dovrebbe avere un accesso Reader e Object Writer. Per configurare questa benna nella pipeline.

Ambiente Proprietà per configurazione benna COS Nome Tipo Descrizione Richiesto o opzionale Bloccato o sbloccato |:----------|:------------------------------|:------------------|:----------|:----------| cos-api-key | SEGRETO | La chiave API dell' Cloud Object Storage. | Obbligatorio | Bloccato | | cos-access-key-id | SEGRETO | L' Cloud Object Storage Access Key ID dalle credenziali HMAC. (Fornito insieme a cos-secret-access-key invece di cos-api-key)| Obbligatorio | Sbloccato | | cos-secret-access-key | SEGRETO | La chiave di accesso segreta dell' Cloud Object Storage, proveniente dalle credenziali HMAC. (Fornito insieme a cos-access-key-id invece di cos-api-key) | Obbligatorio | Sbloccato | | cos-bucket-name | testo | Il nome della benna nel tuo esempio di Cloud Object Storage, che viene utilizzata come armadietto delle prove. | Obbligatorio | Sbloccato | | cos-endpoint | testo | L'endpoint che legge le prove dall'istanza di Cloud Object Storage, utilizzata come archivio delle prove. Per ulteriori informazioni, vedere Tipi di endpoint. | Obbligatorio | Sbloccato |

Configurare la stessa benna in tutte le tubazioni CI/CD/CC.

Migrazione da Git Evidence Locker a COS Evidence Locker

Per migliorare le prestazioni di compilazione, l'affidabilità e la scalabilità, il supporto per gli Evidence Locker Git basati su è stato deprecato. Il passaggio a Evidence Lockers Cloud Object Storage basati su (COS) contribuisce a ridurre la dipendenza dalle Git operazioni e evita problemi di limitazione della velocità da parte Git hosting dei provider.

Tutti gli utenti devono aggiornare le proprie toolchain e pipeline per utilizzare un COS Evidence Locker.

Quando la tua catena di strumenti utilizza solo un Git Evidence Locker

Segui questi passaggi per completare la migrazione:

Quando la tua toolchain utilizza sia Git che COS Evidence Lockers

Se hai già configurato entrambi:

  • Rimuovi la evidence-repo proprietà environment da tutte le pipeline.
  • Rimuovi GitHub/GitLab l'integrazione associata all'archivio delle prove nella tua toolchain.

Preparazione delle pipeline CD per la migrazione da Git a COS Evidence Locker

Se le pipeline CI e CD si basano su un Git Evidence Locker, le pipeline CD devono essere avviate per utilizzare il COS Evidence Locker. È possibile scegliere uno dei seguenti approcci.

Approccio 1: Bootstrap utilizzando entrambi gli Evidence Locker

In questo approccio, COS Evidence Locker è abilitato mentre Git Evidence Locker rimane configurato. L'esecuzione in parallelo di entrambi consente al COS Evidence Locker di essere avviato automaticamente utilizzando Git l'Evidence Locker.

  • Mantenere la configurazione Git dell'armadietto delle prove.
  • Abilita il COS Evidence Locker.
  • Eseguire la pipeline CD utilizzando una versione della definizione della pipeline precedente a v10.46.1 (consigliata: v10.45.0 ).
  • Al termine dell'esecuzione, rimuovere la Git configurazione di Evidence Locker come descritto in precedenza.

Approccio 2: Bootstrap senza Git Evidence Locker

Utilizza questo approccio se preferisci una migrazione pulita senza fare affidamento su Git.

  • Rimuovi la Git configurazione di Evidence Locker.
  • Esegui un'esecuzione una tantum della pipeline CD con il force-redeploy parametro impostato su true.
  • Al termine dell'esecuzione, reimpostare force-redeploy su false o rimuovere completamente il parametro.

L'esecuzione una tantum della pipeline CD garantisce che COS Evidence Locker sia popolato con tutte le risorse di inventario esistenti. È necessaria solo una singola esecuzione iniziale e potrai. Se preferisci non avviare un'implementazione effettiva, puoi saltare le fasi di implementazione e test di accettazione per eseguire la pipeline CD senza eseguire alcuna azione di implementazione.

È possibile scegliere di archiviare l'archivio Git delle prove dopo la rimozione, poiché potrebbe essere necessario a fini di revisione.

Migrazione da un bucket COS a un altro bucket COS

Migrazione da un bucket COS a un altro Se sei già un utente dell'armadietto delle prove COS e devi migrare da un bucket COS a un altro, è importante garantire una transizione fluida senza interrompere i flussi di lavoro. Di seguito sono riportati i passaggi e le considerazioni per la migrazione tra bucket COS.

Motivi della migrazione:

  • Ristrutturazione organizzativa: potresti voler smettere di usare un secchio COS e iniziare a usarne un altro.
  • Trasferimento della benna: la benna deve essere spostata da un conto a un altro, possibilmente a causa di cambiamenti organizzativi o requisiti di conformità.

Passaggi per la migrazione:

Configurare il bucket Backup-COS: se si sta migrando da un vecchio bucket COS a uno nuovo, assicurarsi che la pipeline sia configurata per utilizzare sia il vecchio che il nuovo bucket. Ciò consente una migrazione fluida senza interrompere i flussi di lavoro esistenti.

  • Creare la nuova benna COS come definito nei passaggi precedenti.
  • Configurare le politiche IAM: assicurarsi che il nuovo bucket COS abbia le politiche IAM necessarie per l'accesso Reader e Object Writer come richiesto dalle pipeline.
  • Aggiorna variabili di ambiente

In Toolchain di IBM, aggiornare le variabili di ambiente per includere sia i vecchi che i nuovi bucket COS. Per configurare il vecchio bucket, utilizzare il prefisso backup- in tutte le proprietà COS env e utilizzare le proprietà normali per configurare il nuovo bucket COS.

Nome Immettere Descrizione Obbligatoria o facoltativa Bloccato o sbloccato
backup-cos-api-key SEGRETO La chiave API di Backup Cloud Object Storage. Obbligatorio Bloccato
backup-cos-access-key-id SEGRETO Cloud Object Storage e di backup ID chiave di accesso dalle credenziali HMAC. (Fornito insieme a backup-cos-secret-access-key invece che a backup-cos-api-key) Obbligatorio Sbloccato
backup-cos-secret-access-key SEGRETO Cloud Object Storage e di backup Chiave di accesso segreta dalle credenziali HMAC. (Fornito insieme a backup-cos-access-key-id invece che a backup-cos-api-key) Obbligatorio Sbloccato
backup-cos-bucket-name text Il nome della benna di riserva nel tuo esempio di " Cloud Object Storage " che viene utilizzata come armadietto delle prove. Obbligatorio Sbloccato
backup-cos-endpoint text L'endpoint che legge le prove dall'istanza di backup dell' Cloud Object Storage, utilizzata come archivio delle prove. Per ulteriori informazioni, vedere Tipi di endpoint. Obbligatorio Sbloccato

Non eliminare il vecchio bucket per 365 giorni, perché sarebbe necessario per le verifiche.

Guida alla risoluzione dei problemi per pipeline che funzionano lentamente

  1. force-redeploy non deve essere impostato su true, a meno che non si tratti di una nuova distribuzione di tutte le voci.
  2. La pipeline di promozione deve essere utilizzata per promuovere l'insieme corretto di delta, in modo che il calcolo dei delta sia corretto.
  3. Se si vedono queste righe, significa che la pipeline CI non sta generando i riepiloghi corretti. Tornare alla pipeline CI e verificare se ci sono errori durante la creazione dei mini-sommari nel passaggio di finitura.