Gestione dei segreti nelle tue toolchain

Le integrazioni degli strumenti nelle toolchain CI e CD richiedono segreti, ad esempio password, chiavi API, certificati o altri token. Ad esempio, una chiave API IBM Cloud® esegue le operazioni di base della pipeline, come l'accesso a IBM Cloud. Allo stesso modo, la chiave API dell'ID del servizio scrive la prova nel bucket nell'istanza dell'archivio oggetti cloud.

Per motivi di sicurezza, questi segreti non devono rivelare l'identit ... o l'account di una persona poichŠ le persone spesso dispongono di autorizzazioni di accesso maggiori rispetto al requisito di automazione della toolchain. L'affiliazione con l'identità o il conto di una persona violerebbe anche il principio di sicurezza di "minimo privilegio". Inoltre, le persone spesso cambiano ruoli o anche le società e le loro credenziali devono essere rimosse, il che potrebbe interrompere l'automazione della toolchain. Utilizzando un'identità che è affiliata specificamente per scopi di automazione, fornisce una separazione dei compiti tra l'automazione e le persone che utilizzano l'automazione.

Invece, i segreti utilizzati per le risorse nonIBM Cloud (come GitHub Enterprise) devono essere affiliati a un ID funzionale all'interno della tua azienda solo con l'accesso appropriato richiesto dalle toolchain. Allo stesso modo, i segreti per le risorse IBM Cloud devono essere affiliati a una chiave API ID servizio IAM affiliata a un ID servizio IAM. Le autorizzazioni di accesso dell'ID del servizio IAM devono essere limitate al minimo privilegio richiesto dalle toolchain.

La gestione di credenziali come queste deve essere eseguita in modo sicuro e in conformità con le procedure ottimali di gestione dei segreti. In particolare, si tratta di eseguire il vault dei segreti richiesti utilizzando un fornitore di vault approvato all'interno del confine, come IBM Cloud® Secrets Manager, IBM® Key Protect, o HashiCorp Vault e quindi collegare i segreti della propria toolchain a tali risorse.

Le funzionalità di gestione dei segreti fornite nelle interfacce utente della toolchain e della pipeline consentono di selezionare i segreti custoditi utilizzando le integrazioni dei segreti per IBM Cloud® Secrets Manager, IBM® Key Protect, o HashiCorp Vault. Utilizzando la finestra di dialogo Secrets Picker, un editor della toolchain o della pipeline può selezionare i segreti denominati da un'integrazione dei segreti associati che è configurata in base al CRN (Cloud Resource Name) o in base al nome, che viene quindi risolta in base al riferimento al runtime all'interno della toolchain e della pipeline. Dopo aver scelto un segreto, un CRN o un riferimento segreto canonico viene inserito nella proprietà protetta della toolchain o della pipeline corrispondente in cui il formato è crn:v1:...secret:<secret-guid> se si tratta di un'integrazione Secrets Manager configurata dal CRN o in alternativa {vault::integration-name.secret-name} se si tratta di un'integrazione vault che utilizza uno dei provider supportati e configurati per nome.

Il formato di riferimento canonico per nome attualmente non risolve un segreto che include il carattere punto nel nome del segreto perché questo carattere viene utilizzato per delimitare ogni sezione del percorso canonico.

Indipendentemente dal tipo di riferimento segreto utilizzato, dal CRN o dal nome, i componenti dell'interfaccia utente front-end e la finestra di dialogo Secrets Picker utilizzano solo un riferimento segreto. Il valore risolto di un riferimento segreto per CRN o per nome non viene mai esposto al front-end e viene sempre risolto dinamicamente al runtime all'interno di una toolchain e di una pipeline in base alla disponibilità di un' autorizzazione consentita (configurata utilizzando le politiche di accesso e le autorizzazioni IAM).

All'interno di IBM Cloud®, il processo dinamico di risoluzione per CRN e per nome dei riferimenti segreti nelle toolchain e nelle pipeline viene eseguito utilizzando endpoint privati virtuali (VPE) interni a tutte le istanze dei provider IBM Cloud® Secrets Manager e IBM® Key Protect in tutte le regioni. Questo garantisce che tutti i dati di richiesta e risposta tra le toolchain, le pipeline e le istanze dei provider IBM Cloud® Secrets Manager e IBM® Key Protect siano mantenuti all'interno della rete privata IBM Cloud e non viaggino su canali di rete pubblici.

Oltre a selezionare manualmente i segreti scelti uno per uno da qualsiasi integrazione di segreti associati in una toolchain, è anche disponibile l'opzione di utilizzare un Secret Hint. Questa opzione consente a un template della toolchain di essere predefinito con nomi di segreti suggeriti (noti anche come Hints) che sono un riferimento segreto di formato breve. Il formato di un suggerimento segreto è {vault::secret-name} per cui non è incluso alcun nome di integrazione segreto. Ciò fornisce flessibilità all'autore della toolchain in quanto tutti i nomi segreti richiesti possono essere prepopolati in un toolchain.yml e quindi questi nomi vengono automaticamente risolti rispetto a qualsiasi integrazione dei segreti configurata per la toolchain.

Come descritto in precedenza, puoi configurare Secrets Manager in modo che faccia riferimento ai segreti tramite CRN. Per ulteriori informazioni, vedere Nomi di risorse cloud(CRN). Questo formato consente una maggiore flessibilità perché puoi fare riferimento ai segreti da un'istanza Secrets Manager in un account diverso se è presente l'autorizzazione corretta. Per ulteriori informazioni, consultare Configurazione di Secrets Manager.

I segreti utilizzati in CI e CD sono descritti come segue:

Un Hint è un nome predefinito suggerito che viene automaticamente risolto rispetto al primo segreto corrispondente con lo stesso nome in tutte le integrazioni dei segreti per nome disponibili associate alla toolchain.

DevSecOps segreti dell'oleodotto

SegretiDevSecOps
Secret Suggerimento Informazioni
Chiave API IBM Cloud ibmcloud-api-key Obbligatorio: CI & CD Utilizzato per l'autenticazione con il cloud pubblico IBM ed eseguire una vasta gamma di operazioni
Chiave privata GPG signing_key Obbligatorio: solo CI Questo è il certificato utilizzato per firmare le immagini create dalla pipeline CI
Chiave API del servizio operatore privato IBM private-worker-service-api-key Obbligatorio: solo CI Una chiave API ID servizio utilizzata per eseguire i carichi di lavoro della delivery pipeline su un servizio di nodo di lavoro privato Tekton
Token di accesso GitHub git-token Facoltativo: CI & CD Utilizzato per l'autenticazione con GitHub e per fornire l'accesso ai repository
Token API Artifactory artifactory-token Obbligatorio: CI & CD Utilizzato per accedere alle immagini utilizzate dalle attività della pipeline
Webhook Slack slack-webhook Facoltativo: CI & CD Questo webhook è necessario se si sceglie di utilizzare l'integrazione dello strumento Slack per inviare notifiche di stato della toolchain
Token API ServiceNow servicenow-api-token Obbligatorio: solo CD Utilizzato per accedere a Service Now per le operazioni di gestione modifiche
HashiCorp Vault ID ruolo role-id Richiesto: CI e CD Utilizzato per l'autenticazione con il server HashiCorp Vault
HashiCorp Vault ID segreto secret-id Richiesto: CI e CD Utilizzato per l'autenticazione con il server HashiCorp Vault
Chiave API del programma di scrittura IBM Cloud Object Storage cos-api-key Obbligatorio: CI & CD Utilizzato per l'autenticazione con il servizio Object Storage- Questa chiave deve avere l' writer autorizzazione
IBM Cloud Object Storage Chiave API lettore backup-cos-api-key Obbligatorio: CI & CD Utilizzato per l'autenticazione con il servizio Object Storage- Questa chiave deve avere l' Reader autorizzazione
Password SonarQube o token di autenticazione sonarqube-password Facoltativo: CI Utilizzato per l'autenticazione con il programma di analisi del codice sorgente SonarQube

Se si utilizza un server HashiCorp Vault, assicurarsi che l'integrazione dello strumento HashiCorp Vault utilizzi il metodo AppRole Auth Method. Quando si usa il metodo di autenticazione AppRole, sono necessari role-id e secret-id per integrare correttamente il server HashiCorp Vault con la toolchain. Poiché role-id e secret-id sono segreti in sé, si consiglia di memorizzarli utilizzando un' integrazione dello strumentoIBM Key Protect in modo che possano essere richiamati e applicati in modo sicuro nel flusso di lavoro della toolchain. Tutti gli altri segreti della catena di strumenti devono essere memorizzati e recuperati utilizzando l'integrazione dello strumento HashiCorp Vault.

Se la proprietà dell'ambiente della pipeline git-token non è impostata, ibmcloud-api-key viene usato per recuperare il token di accesso Git Repos and Issue Tracking per impostazione predefinita. Tuttavia, se ibmcloud-api-key non ha accesso a git, è necessario impostare git-token.

Configurazione degli archivi segreti

Con IBM Cloud, puoi scegliere tra diverse offerte di gestione dei segreti e di protezione dei dati che ti aiutano a proteggere i tuoi dati sensibili e centralizzare i tuoi segreti. Puoi scegliere tra le integrazioni del vault a seconda dei tuoi requisiti, come spiegato in Gestione dei segreti IBM Cloud. Questa documentazione fornisce informazioni sui prerequisiti e su come utilizzare un elenco di nomi segreti prescritti altrimenti noti come suggerimenti. Utilizzando i suggerimenti in un template, una toolchain può essere popolata automaticamente con segreti preconfigurati senza la necessità di selezionarli manualmente da varie integrazioni vault collegate alla toolchain.

Utilizzare IBM Cloud® Secrets Manager per memorizzare e applicare in modo sicuro segreti come chiavi API, firme di immagini o credenziali HashiCorp Vault che fanno parte della vostra catena di strumenti.

Secrets Manager modulo di integrazione dello strumento
Integrazione dello strumentoIBM Secrets Manager

I modelli sono inoltre dotati di un'integrazione dello strumento HashiCorp Vault, come nell'esempio seguente:

HashiCorp Vault Modulo di integrazione degli strumenti con campi obbligatori e valori di esempio Modulo di integrazione degli strumenti con campi obbligatori e valori di esempio Integrazione degli strumenti
HashiCorp Vault

Per utilizzare HashiCorp Vault, è necessario fornire le seguenti informazioni:

  • Nome: un nome per questa integrazione dello strumento. Questo nome viene visualizzato nella catena degli strumenti.
  • Server URL: Il server URL per l'istanza HashiCorp Vault. Ad esempio, https://<vault-service>.<org>.com:8200.
  • Integrazione URL: Il sito URL a cui si desidera navigare quando si fa clic sulla piastrella Integrazione HashiCorp Vault.
  • Percorso dei segreti: Il percorso di montaggio in cui sono memorizzati i segreti nell'istanza HashiCorp Vault.
  • Metodo di autenticazione: Il metodo di autenticazione per l'istanza HashiCorp Vault. Utilizzare AppRole.
  • ID ruolo: l'identificativo che seleziona il AppRole rispetto al quale vengono valutate altre credenziali.
  • ID segreto: la credenziale richiesta per impostazione predefinita per qualsiasi accesso (con secret_id) e che deve essere sempre segreta.

I modelli vengono forniti anche con l'integrazione dello strumento IBM® Key Protect for IBM Cloud®:

Key Protect modulo di integrazione dello strumento con campi obbligatori e valori di esempio
IBM Key Protect tool integration

Se hai memorizzato role id e secret id in Key Protect in anticipo, puoi selezionare l'istanza Key Protect che contiene tali segreti nella scheda dello strumento come mostrato nella Figura 2. Dopo aver fatto ciò, è possibile fare clic sulle icone delle chiavi nei campi id ruolo e id segreto nella scheda degli strumenti di HashiCorp Vault e utilizzare il selezionatore per applicare i segreti a tali campi.

Allo stesso modo, tutti gli altri segreti utilizzati nella toolchain hanno un'icona chiave allegata al campo di testo. È possibile utilizzare lo stesso controllo picker per applicare i segreti di HashiCorp Vault a tutte le istanze rimanenti.

Recuperare i segreti da IBM Cloud Secrets Manager

Utilizzare il comando get_env per accedere al segreto in modo sicuro. Questo metodo recupera il segreto senza esporlo nei log.

Tipi di segreti supportati

Attualmente, supportiamo il recupero dei seguenti tipi di segreti dalle proprietà dell'ambiente in Secrets Manager:

  • Arbitrario

  • Credenziali IAM

  • Chiave-valore

Uso:

  export SECRET_VALUE=$(get_env "secret_key" "")

In questo esempio:

  • secret_key è il nome utilizzato per memorizzare il segreto.

  • SECRET_VALUE conserva il valore segreto recuperato per un uso successivo.

A seconda del tipo di segreto, get_env recupera valori specifici:

Recupero del segreto arbitrario
  {
    "name": "my-secret",
    "secret_type": "arbitrary",
    ...
    "payload": "The quick brown fox jumped over the lazy dog."
  }

Se get_env viene utilizzato con my-secret, recupera il valore payload.

Recupero del segreto iam_credentials
  {
    "name": "my-iam-credentials",
    "secret_type": "iam_credentials",
    ...
    "api_key": "RmnPBn6n1dzoo0v3kyznKEpg0WzdTpW9lW7FtKa017_u",
    "api_key_id": "ApiKey-dcd0b857-b590-4507-8c64-ae89a23e8d76",
    "service_id": "ServiceId-bb4ccc31-bd31-493a-bb58-52ec399800be"
  }

Se get_env è usato con my-iam-credentials, recupera api_key.

Recupero del segreto chiave-valore
  {
    "name": "my-kv-secret",
    "secret_type": "key-value",
    ...
    "data": "{\"key\":\"value\"}"
  }

Se get_env è usato con my-kv-secret, recupera value all'interno della coppia chiave-valore