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 attività della pipeline di base, 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, ciò significa eseguire il vault dei segreti richiesti utilizzando un provider del vault in - boundary approvato, come IBM Cloud® Secrets Manager, IBM® Key Protecto HashiCorp Vault e quindi collegare i segreti della toolchain a queste risorse.
Le funzionalità di gestione dei segreti fornite nelle interfacce utente di configurazione e pipeline della toolchain abilitano la selezione dei segreti protetti utilizzando le integrazioni dei segreti per IBM Cloud® Secrets Manager, IBM® Key Protecto
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).
In IBM Cloud®, il processo dinamico di risoluzione dei riferimenti segreti by CRN e by name nelle toolchain e nelle pipeline viene eseguito utilizzando i VPE (virtual private endpoint) interni a tutte le istanze del 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 del provider IBM Cloud® Secrets Manager e IBM® Key Protect siano conservati all'interno della rete IBM Cloud privata e non viaggiano attraverso i canali della rete pubblica.
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
| 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 |
| ID ruolo HashiCorp Vault | role-id |
Obbligatorio: CI & CD Utilizzato per l'autenticazione con il server HashiCorp Vault |
| ID segreto vault HashiCorp | secret-id |
Obbligatorio: CI & 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 Vault HashiCorp, assicurarsi che l'integrazione dello strumento Vault HashiCorp utilizzi il metodo AppRole Auth Method.
Quando utilizzi il metodo di autenticazione AppRole, hai bisogno di role-id e secret-id per integrare correttamente il server Vault HashiCorp 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 toolchain devono essere archiviati e recuperati utilizzando l'integrazione dello strumento HashiCorp Vault.
Se la proprietà dell'ambiente della pipeline git-token non è impostata, ibmcloud-api-key viene utilizzato per richiamare 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.
Utilizza IBM Cloud® Secrets Manager per archiviare e applicare in modo sicuro i segreti come le chiavi API, la firma dell'immagine o le credenziali HashiCorp Vault che fanno parte della tua toolchain.
I template vengono forniti anche con un'integrazione dello strumento HashiCorp Vault come nel seguente esempio:
Per utilizzare HashiCorp Vault, devi fornire le seguenti informazioni:
- Nome: un nome per questa integrazione dello strumento. Questo nome viene visualizzato nella catena degli strumenti.
- Server URL: L' URL e server per la tua istanza Vault di HashiCorp. Ad esempio,
https://<vault-service>.<org>.com:8200. - Integrazione URL: l' URL e a cui si desidera accedere quando si fa clic sul riquadro Integrazione Vault di HashiCorp.
- Percorso dei segreti: il percorso di montaggio in cui sono archiviati i tuoi segreti nella tua istanza del vault HashiCorp.
- Metodo di autenticazione: il metodo di autenticazione per la tua istanza del vault HashiCorp. 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®:
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ò, puoi
fare clic sulle icone chiave nei campi role id e secret id nella scheda dello strumento HashiCorp Vault e utilizzare il selettore per applicare i segreti a questi 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 del selettore per applicare i segreti del vault HashiCorp a tutte le istanze restanti.
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_VALUEconserva 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