Azure DevOps Intégration : Aperçu technique
Sécurité d'accès au service d'intégration
Nous utilisons OAuth2 pour sécuriser nos API internes, chaque appel de service doit contenir un jeton OAuth avec un ensemble spécial de champs d'application demandés par le service.
Isolation des données
L'intégration native utilise Postgres comme stockage sous-jacent. Chaque tableau Postgres comporte une colonne "compte". Cette colonne de compte est utilisée pour séparer les données d'un compte de celles d'un autre au cours de l'opération. Une série de tests d'intégration permet de vérifier que les données sont régulièrement isolées. Remarque : cette option n'est pas disponible pour les instances de Cloud privé.
Méthodes d'authentification prises en charge
- Authentification de base par jeton d'accès personnel
Format de stockage des données
Nous utilisons Postgres DB comme stockage principal pour l'intégration.
Ce qui est stocké dans Postgres :
- Profil d'intégration
- Références. Les données d'identification sont cryptées à l'aide de l'algorithme AES-256 (voir détails ci-dessous au paragraphe 5)
- Routages. Projets Targetprocess et ADO (leurs identifiants et noms)
- Mappages de types, identifiants et noms de types, champs de types et noms de champs
- Actions de l'entité. Paire d'entités Targetprocess et d'éléments de travail connexes dans Azure DevOps. Pour les entités, nous ne stockons aucune donnée, à l'exception de leur clé d'émission/identifiant d'entité et de leur type d'entité.
Les bases de données sont hébergées sur le même nœud à l'intérieur du cluster Kuberntes.
Nous utilisons le cache en mémoire pour certaines informations presque statiques (jusqu'à 30min ) :
- Azure DevOps types d'éléments de travail
- Azure DevOps champs de l'élément de travail
- Informations sur les profils configurés
Nous utilisons Elastic Cloud pour l'enregistrement, aucune donnée sensible n'est stockée dans les journaux. Elastic Cloud en Irlande est utilisé et la journalisation peut être désactivée à la demande.
Nous utilisons rabbit MQ pour la communication des services sous-jacents. Les messages en lapin contiennent des modifications effectuées dans un outil et des modifications qui doivent être appliquées à l'outil cible.
Rabbit est situé sur les mêmes nœuds Kubernetes que le service d'intégration Azure DevOps.
Cryptage des données d'identification
Toutes les informations d'identification sont stockées dans la base de données PostgreSQL avec d'autres données d'intégration sous une forme cryptée à l'aide de l'algorithme AES-256. Schéma d'ensemble et flux détaillé ci-dessous :
- Paire de clés publique/privée générée lors de la création du cluster, clé privée stockée localement. (en utilisant PKCS#7 avec RSA 2048 bit)
- Il y a un dépôt git "secrets" créé par cluster qui contient des secrets cryptés ou non cryptés en fonction de la sensibilité des données.
- Azure DevOps la clé de cryptage des jetons d'intégration (à utiliser par l'algorithme AES256 ) est générée automatiquement (service de cryptage) ou manuellement (équipe DevOps dans notre cas) et cryptée avec la partie publique de la clé de la grappe.
- Azure DevOps le service d'intégration invoque les services Secrets / Encryptor et envoie la "clé de cryptage des données"
- La clé de cryptage des données est décryptée à l'aide de la partie privée de la clé de cluster, renvoyée et utilisée pour crypter le jeton d'intégration ADO.
- Même processus pour la récupération des clés - Azure DevOps integration services invoque les services Secrets / Encryptor pour récupérer Azure DevOps integration token decryption key and caches for the duration of the container lifecycle.
Flux de traitement
Générique pour toutes les intégrations natives, chaque intégration d'outil utilise son propre adaptateur
Azure DevOps le service de l'adaptateur est à l'écoute des webhooks du compte Azure DevOps. Lorsqu'une mise à jour se produit dans Azure DevOps,, l'adaptateur ADO la convertit au format générique. Il peut mettre en file d'attente des données supplémentaires via l'API si elles sont nécessaires à la conversion. Lorsqu'un événement est converti, il est envoyé dans la file d'attente des événements génériques.
Le service de synchronisation des entités est à l'écoute des événements génériques. Lorsqu'un événement générique est reçu, si certaines règles configurées correspondent à cet événement (par exemple, un élément de travail mis à jour sur Azure DevOps, et cet élément est déjà partagé avec une question Targetprocess), la synchronisation de l'entité applique les règles configurées et génère une ou plusieurs commandes qui doivent être appliquées à l'entité cible. L'entité sync publie ces commandes dans la file d'attente des commandes d'adaptateurs spécifiques RabbitMQ. Lors des mappages, l'application de la synchronisation des entités pourrait passer par des outils spécifiques via l'api des adaptateurs pour effectuer certaines conversions comme (pièce jointe, commentaire, utilisateur, état, etc.)
Adaptateur Targetprocess - reçoit les commandes qui doivent être appliquées à l'entité cible et applique les changements via l'API de l'outil. Si une commande contient plusieurs mises à jour de champs mais que toutes ne sont pas valides, l'adaptateur divise la mise à jour initiale en quelques petites mises à jour et applique toutes les mises à jour valides en ignorant celles qui ne le sont pas.
Le flux qui va de Targetprocess à Azure DevOps reflète le flux inverse décrit dans le paragraphe précédent. Les mises à jour sont générées du côté de Targetprocess et appliquées à Azure DevOps selon les mêmes règles.
Les flux sont également similaires et ne dépendent pas de l'outil. Examinons le flux d'actions de Targetprocess à Azure DevOps.
Lorsque vous essayez de partager une entité toAzure DevOps:
- La synchronisation des entités vérifie via l'API de l'adaptateur Targetprocess si l'entité correspond à l'itinéraire configuré - il s'agit d'un problème dans le bon projet, assigné à la bonne équipe, correspondant aux filtres WIQL, etc. Si c'est le cas, il résout la destination cible du partage de l'entité (projet cible)
- La synchronisation des entités vérifie si le profil a une correspondance de type pour l'entité source et résout le type d'entité cible.
- Si le champ d'application cible (projet) et le type sont résolus, l'adaptateur crée une entité cible (stub) dans Azure DevOps. Il tente de remplir tous les champs obligatoires avec quelques erreurs.
- Si l'entité cible est créée, la synchronisation des entités établit des règles de synchronisation entre l'entité source et l'entité cible.
- La synchronisation des entités transfère l'état des entités du processus cible. (Valeurs de tous les champs configurés dans le profil)
- La synchronisation des entités applique les correspondances configurées pour calculer l'état de l'entité cible et l'envoyer sous la forme d'une ou plusieurs commandes de mise à jour à l'adaptateur ADO.
- Azure DevOps l'adaptateur applique des commandes à l'élément de travail Azure DevOps pour qu'il soit conforme aux correspondances configurées.
Il existe deux ensembles d'ACL et de groupes de sécurité utilisés pour limiter l'accès aux instances de Targetprocess à partir d'Internet :
- Pour l'application - en entrée pour autoriser uniquement l'accès de HTTPS au proxy qui achemine ensuite les données vers le serveur ou le service correspondant, par exemple Azure DevOps intégration
- Pour la gestion - l'accès à l'hôte Bastion pour la gestion n'est autorisé qu'à partir du bureau de Targetprocess ou seulement s'il est connecté au bureau via VPN.
Azure DevOps Crochets Web
Pour recevoir des mises à jour de Azure DevOps targetprocess utilise des webhooks. Les webhooks peuvent être configurés manuellement ou automatiquement.
Pour recevoir toutes les mises à jour nécessaires de Azure DevOps, integration a besoin d'au moins 5 webhooks dans chaque projet pour les événements suivants :
- Travail créé
- Projet de travail restauré
- Mise à jour des travaux
- Travail supprimé
- Point de travail commenté
Compte tenu des performances et du grand nombre de projets, les webhooks sont créés sans filtres supplémentaires par chemin de zone, type d'élément de travail, etc.
Si vous avez mis à jour les webhooks manuellement pour respecter certains filtres, vous devez passer les webhooks en mode de configuration manuelle, sinon tous les filtres seront réinitialisés à chaque enregistrement de profil.
Azure DevOps Permissions des utilisateurs de services
Le jeton d'accès personnel doit bénéficier du niveau d'accès suivant :
Work Items (Read, write & manage), Project and Teams (Read), Identity (Read)
Si vous souhaitez commencer par une synchronisation à sens unique et extraire des données de AzureDevops vers Targetprocess, sélectionnez uniquement l'accès à l'étendue "Read".
Azure DevOps APIs utilisées par 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