Azure DevOps Integrazione: Panoramica tecnica
Sicurezza dell'accesso al servizio di integrazione
Utilizziamo OAuth2 per proteggere le nostre API interne; ogni chiamata di servizio deve contenere un token OAuth con una serie speciale di ambiti richiesti dal servizio.
Isolamento dei dati
L'integrazione nativa utilizza Postgres come storage sottostante. Ogni tabella Postgres ha una colonna di conto. Questa colonna del conto viene utilizzata per dividere i dati di un conto da quelli di un altro durante l'operazione. Una serie di test di integrazione verifica che i dati siano isolati regolarmente. Nota: non è effettivo per le istanze Private Cloud.
Metodi di autenticazione supportati
- Autenticazione di base tramite token di accesso personale
Formato di memorizzazione dei dati
Utilizziamo Postgres DB come archivio principale per l'integrazione.
Cosa viene memorizzato in Postgres :
- Profilo di integrazione
- Credenziali. Le credenziali sono crittografate con l'algoritmo AES-256 (si vedano i dettagli al paragrafo 5)
- Percorsi. Progetti Targetprocess e ADO (i loro ID e nomi)
- Mappature dei tipi, id e nomi dei tipi, campi dei tipi e nomi dei campi
- Azioni dell'entità. Coppia di entità Targetprocess e relativa voce di lavoro in Azure DevOps. Per le entità non memorizziamo alcun dato, tranne la loro chiave di emissione / ID entità e il loro tipo di entità.
I database sono ospitati sullo stesso nodo all'interno del cluster Kuberntes.
Utilizziamo la cache in-memory per alcune informazioni quasi statiche (fino a 30min ):
- Azure DevOps tipi di voci di lavoro
- Azure DevOps campi dell'elemento di lavoro
- Info sui profili configurati
Per la registrazione utilizziamo il sito Elastic Cloud; nessun dato sensibile viene memorizzato nei log. Elastic Cloud in Irlanda e la registrazione può essere disabilitata su richiesta.
Utilizziamo rabbit MQ per la comunicazione del servizio sottostante. I messaggi Rabbit contengono le modifiche effettuate in uno strumento e quelle che devono essere applicate allo strumento di destinazione.
Rabbit si trova sugli stessi nodi Kubernetes in cui si trova il servizio di integrazione Azure DevOps.
Crittografia delle credenziali
Tutte le credenziali sono memorizzate nel database PostgreSQL insieme ad altri dati di integrazione in forma crittografata con l'algoritmo AES-256. Diagramma generale e flusso dettagliato di seguito:
- Coppia di chiavi pubbliche/private generate durante la creazione del cluster, chiave privata memorizzata localmente. (utilizzando PKCS#7 con RSA 2048 bit)
- Per ogni cluster viene creato un repository git "secrets" che contiene segreti crittografati o non crittografati, a seconda della sensibilità dei dati.
- Azure DevOps la chiave di crittografia dei token di integrazione (che verrà utilizzata dall'algoritmo AES256 ) viene generata automaticamente (servizio di crittografia) o manualmente ( DevOps Team nel nostro caso) e crittografata con la parte pubblica della chiave del cluster.
- Azure DevOps il servizio di integrazione invoca i servizi Secrets / Encryptor e invia la "chiave di crittografia dei dati"
- La chiave di crittografia dei dati viene decifrata utilizzando la parte privata della chiave del cluster, restituita e utilizzata per crittografare il token di integrazione ADO.
- Stesso processo per il recupero della chiave - Azure DevOps servizi di integrazione invoca i servizi Secrets / Encryptor per recuperare Azure DevOps la chiave di decrittazione del token di integrazione e la memorizza nella cache per la durata del ciclo di vita del contenitore.
Flusso di elaborazione
Generico per tutte le integrazioni native, ogni integrazione di strumenti usa il proprio adattatore
Il servizio adattatore Azure DevOps ascolta i webhook dall'account Azure DevOps. Quando si verifica un aggiornamento in Azure DevOps, l'adattatore ADO lo converte in formato generico. Può accodare alcuni dati aggiuntivi tramite API, se necessari per la conversione. Quando un evento viene convertito, lo invia alla coda degli eventi generici.
Il servizio di sincronizzazione delle entità ascolta gli eventi generici. Quando viene ricevuto un evento generico, se sono state configurate alcune regole che corrispondono a quell'evento (ad esempio, l'elemento di lavoro aggiornato in Azure DevOps, e questo elemento è già condiviso con una questione di Targetprocess), la sincronizzazione delle entità applica le regole configurate e genera 1 o molti comandi che devono essere applicati all'entità di destinazione. L'Entity sync pubblica questi comandi in una coda specifica di comandi dell'adattatore RabbitMQ. Durante le mappature applicare la sincronizzazione delle entità potrebbe andare a strumenti specifici tramite gli adattatori api per procedere ad alcune conversioni come (allegato, commento, utente, stato, ecc.)
Adattatore Targetprocess - riceve i comandi che devono essere applicati all'entità di destinazione e applica le modifiche tramite l'API dello strumento. Se un comando contiene più aggiornamenti di campo ma non tutti sono validi, l'adattatore divide l'aggiornamento iniziale in pochi piccoli aggiornamenti e applica tutti gli aggiornamenti validi ignorando quelli non validi.
Il flusso da Targetprocess a Azure DevOps rispecchia il flusso inverso descritto nel paragrafo precedente. Gli aggiornamenti vengono generati sul lato Targetprocess e applicati a Azure DevOps secondo le stesse regole.
Anche i flussi sono simili, non dipendono dallo strumento. Vediamo il flusso di azioni da Targetprocess a Azure DevOps.
Quando si prova a condividere qualche entità toAzure DevOps:
- La sincronizzazione delle entità controlla tramite l'adattatore API di Targetprocess se l'entità corrisponde al percorso configurato: è un problema nel progetto corretto, assegnato al team corretto, corrisponde ai filtri WIQL, ecc. Se lo fa, risolve la destinazione della condivisione di entità (progetto di destinazione)
- La sincronizzazione delle entità controlla se il profilo ha una mappatura del tipo per l'entità di origine e risolve il tipo di entità di destinazione.
- Se l'ambito di destinazione (progetto) e il tipo sono stati risolti, l'adattatore crea uno stub dell'entità di destinazione in Azure DevOps. Cerca di riempire tutti i campi obbligatori con alcuni stub.
- Se l'entità di destinazione è stata creata, la sincronizzazione delle entità imposta le regole di sincronizzazione tra l'entità di origine e quella di destinazione.
- La sincronizzazione delle entità trasferisce lo stato dell'entità Targetprocess. (Valori di tutti i campi configurati nel profilo)
- Entity sync applica le mappature configurate per calcolare lo stato dell'entità di destinazione e inviarlo come uno o più comandi di aggiornamento all'adattatore ADO.
- Azure DevOps l'adattatore applica i comandi all'elemento di lavoro Azure DevOps in modo che sia conforme alle mappature configurate.
Esistono due serie di ACL e gruppi di sicurezza utilizzati per limitare l'accesso alle istanze di Targetprocess da Internet:
- Per l'applicazione - in entrata per consentire solo l'accesso di HTTPS al proxy che poi instrada i dati al server o al servizio corrispondente, ad esempio Azure DevOps integrazione
- Per la gestione - l'accesso all'host Bastion per la gestione è consentito solo dall'ufficio Targetprocess o solo se collegato all'ufficio tramite VPN.
Azure DevOps Ganci web
Per ricevere gli aggiornamenti da Azure DevOps targetprocess utilizza i webhook. I webhook possono essere impostati manualmente o automaticamente.
Per ricevere tutti gli aggiornamenti necessari da Azure DevOps, ha bisogno di almeno 5 webhook in ogni progetto per i seguenti eventi:
- Voce di lavoro creata
- Voce di lavoro ripristinata
- Voce di lavoro aggiornata
- Voce di lavoro eliminata
- Voce di lavoro commentata
Considerando le prestazioni e la grande quantità di progetti, i webhook vengono creati senza filtri aggiuntivi per percorso dell'area, tipo di elemento di lavoro, ecc.
Nel caso in cui si siano aggiornati manualmente i webhook per rispettare alcuni filtri, è necessario passare i webhook in modalità di impostazione manuale, altrimenti tutti i filtri verranno ripristinati a ogni salvataggio del profilo.
Azure DevOps Autorizzazioni per gli utenti del servizio
Al token di accesso personale deve essere concesso il seguente livello di accesso:
Work Items (Read, write & manage), Project and Teams (Read), Identity (Read)
Se si desidera avviare una sincronizzazione unidirezionale e prelevare i dati da AzureDevops a Targetprocess, selezionare solo l'accesso all'ambito 'Read'.
Azure DevOps API utilizzate da Targetprocess
GET /_apis/identities
POST/DELETE /_apis/hooks/subscriptionsQuery
GET /_apis/work/processes/lists/{listId}
GET /_apis/ConnectionData
GET /_apis/projects
GET /_apis/projects/{projectName}
GET /_apis/wit/fields
POST /_apis/wit/wiql
GET /_apis/wit/workItemRelationTypes
POST /_apis/wit/workItemsBatch
GET /_apis/wit/workItems
GET/DELETE/PATCH /_apis/wit/workItems/{workItemId}
POST /{projectName}/_apis/wit/workItems/$
GET /_apis/wit/workItems/{workItemId}/updates/{udpateId}
GET /{projectName}/_apis/wit/workItems/{workItemId}/comments
GET/DELETE/PATCH /{projectName}/_apis/wit/workItems/{workItemId}/comments/{commentId}
POST /{projectName}/_apis/wit/workItems/{workItemId}/comments
GET /{projectName}/_apis/wit/workitemtypes/states
GET /{projectName}/_apis/wit/workItemTypes