Azure DevOps Integración: Resumen técnico
Seguridad de acceso a los servicios de integración
Utilizamos OAuth2 para asegurar nuestras API internas, cada llamada de servicio debe contener un token OAuth con un conjunto especial de ámbitos solicitados por el servicio.
Aislamiento de datos
La integración nativa utiliza Postgres como almacenamiento subyacente. Cada tabla Postgres tiene una columna de cuenta. Esta columna de cuenta se utiliza para separar los datos de una cuenta de otra durante la operación. Un conjunto de pruebas de integración verifica que los datos se aíslan de forma periódica. Nota: no real para instancias de Nube Privada.
Métodos de autenticación admitidos
- Autenticación básica mediante token de acceso personal
Formato de almacenamiento de datos
Utilizamos Postgres DB como almacenamiento principal para la integración.
Qué se almacena en Postgres :
- Perfil de integración
- Credenciales. Las credenciales se cifran con el algoritmo AES-256 (véanse los detalles en el apartado 5)
- Rutas. Proyectos Targetprocess y ADO (sus ID y nombres)
- Asignaciones de tipos, identificadores y nombres de tipos, campos de tipos y nombres de campos
- Acciones de la entidad. Par de entidad Targetprocess y elemento de trabajo relacionado en Azure DevOps. Para las entidades no almacenamos ningún dato excepto su clave de emisión / ID de entidad y su tipo de entidad.
La base de datos se aloja en el mismo nodo dentro del cluster Kuberntes.
Utilizamos la caché en memoria para cierta información casi estática (hasta 30min ):
- Azure DevOps tipos de elementos de trabajo
- Azure DevOps campos de elementos de trabajo
- Información sobre perfiles configurados
Utilizamos Elastic Cloud para el registro, no se almacena ningún dato sensible en los registros. Elastic Cloud en Irlanda y se puede desactivar el registro por petición.
Utilizamos rabbit MQ para la comunicación del servicio subyacente. Los mensajes Rabbit contienen cambios realizados en una herramienta y cambios que deben aplicarse a la herramienta de destino.
Rabbit se encuentra en los mismos nodos Kubernetes que Azure DevOps Integration service.
Cifrado de credenciales
Todas las credenciales se almacenan en la base de datos PostgreSQL junto con otros datos de integración de forma encriptada con el algoritmo AES-256. Diagrama general y flujo detallado a continuación:
- Par de claves pública/privada generado durante la creación del clúster, clave privada almacenada localmente. (usando PKCS#7 con RSA 2048 bit)
- Hay un repositorio git "secrets" creado por cluster que contiene secretos encriptados o no encriptados dependiendo de la sensibilidad de los datos.
- Azure DevOps la clave de cifrado de los tokens de integración (que utilizará el algoritmo AES256 ) se genera automáticamente (servicio de cifrado) o manualmente ( DevOps Team en nuestro caso) y se cifra con la parte pública de la clave del clúster.
- Azure DevOps el servicio de integración invoca los servicios Secrets / Encryptor y envía la "Clave de cifrado de datos"
- La clave de cifrado de datos se descifra utilizando la parte privada de la clave de clúster, se devuelve y se utiliza para cifrar el token de integración ADO.
- Mismo proceso para la recuperación de claves: los servicios de integración Azure DevOps invocan a los servicios Secrets / Encryptor para recuperar la clave de descifrado del token de integración Azure DevOps y la almacenan en caché durante el ciclo de vida del contenedor.
Flujo de procesamiento
Genérico para todas las integraciones nativas, cada integración de herramientas utiliza su propio adaptador
Azure DevOps el servicio de adaptador recibe webhooks de la cuenta Azure DevOps. Cuando se produce una actualización en Azure DevOps, el adaptador ADO la convierte a formato genérico. Puede poner en cola algunos datos adicionales a través de api si es necesario para la conversión. Cuando se convierte un evento, lo envía a la cola de eventos genéricos.
El servicio de sincronización de entidades está a la escucha de eventos genéricos. Cuando se recibe un evento genérico, si tiene algunas reglas configuradas que coinciden con ese evento (por ejemplo ítem de trabajo actualizado en Azure DevOps, y este ítem ya está compartido con algún asunto de Targetprocess) la sincronización de entidades aplica las reglas configuradas y genera 1 o muchos comandos que necesitan ser aplicados a la entidad objetivo. Entity sync publica estos comandos en una cola específica de comandos de adaptador RabbitMQ queue. Durante los mapeos aplicar la sincronización de entidades podría ir a herramientas específicas a través de adaptadores api para proceder a algunas conversiones como (archivo adjunto, comentario, usuario, estado, etc.)
Adaptador Targetprocess - recibe comandos que deben aplicarse a la entidad de destino y aplica los cambios a través de la api de la herramienta. Si un comando contiene varias actualizaciones de campo pero no todas son válidas, el adaptador divide la actualización inicial en pocas actualizaciones pequeñas y aplica todas las actualizaciones válidas ignorando las no válidas.
El flujo desde Targetprocess a Azure DevOps refleja el flujo inverso descrito en el párrafo anterior. Las actualizaciones se generan en el lado Targetprocess y se aplican a Azure DevOps mediante las mismas reglas.
Los flujos también son similares, no dependen de la herramienta. Veamos el flujo de acciones desde Targetprocess a Azure DevOps.
Cuando intente compartir alguna entidad toAzure DevOps:
- La sincronización de entidades comprueba a través de la API del adaptador Targetprocess si la entidad coincide con la ruta configurada: es una incidencia en el proyecto adecuado, asignada al equipo adecuado, coincide con los filtros WIQL, etc. Si lo hace, resuelve la entidad compartir destino (proyecto destino)
- La sincronización de entidades comprueba si el perfil tiene una correspondencia de tipos para la entidad de origen y resuelve el tipo de entidad de destino.
- Si el ámbito de destino (proyecto) y el tipo están resueltos, el adaptador crea un stub de entidad de destino en Azure DevOps. Intenta rellenar todos los campos obligatorios con algunos talones.
- Si se ha creado una entidad de destino, la sincronización de entidades establece reglas de sincronización entre la entidad de origen y la entidad de destino.
- La sincronización de entidades transfiere el estado de la entidad Targetprocess. (Valores de todos los campos configurados en el perfil)
- La sincronización de entidades aplica las asignaciones configuradas para calcular el estado de la entidad de destino y enviarlo como uno o varios comandos de actualización al adaptador ADO.
- Azure DevOps adaptador aplica comandos a Azure DevOps elemento de trabajo haciendo que sea como se esperaba a las asignaciones configuradas.
Existen dos conjuntos de ACL's y Grupos de Seguridad utilizados para limitar el acceso a las instancias Targetprocess desde Internet:
- Para la aplicación - de entrada para permitir únicamente el acceso a HTTPS al proxy que, a continuación, enruta los datos al servidor o servicio correspondiente, como Azure DevOps integración
- Para la gestión - el acceso al host Bastion para la gestión sólo se permite desde la oficina Targetprocess o sólo si está conectado a la oficina a través de VPN.
DevOpsAzure Webhooks
Para recibir actualizaciones de Azure DevOps targetprocess utiliza webhooks. Los webhooks pueden configurarse manual o automáticamente.
Para recibir todas las actualizaciones necesarias de Azure DevOps, la integración necesita al menos 5 webhooks en cada proyecto para los siguientes eventos:
- Elemento de trabajo creado
- Elemento de trabajo restablecido
- Elemento de trabajo actualizado
- Elemento de trabajo eliminado
- Punto de trabajo comentado
Teniendo en cuenta el rendimiento y la gran cantidad de proyectos, los webhooks se crean sin filtros adicionales por Ruta de Área, Tipo de Elemento de Trabajo, etc.
En caso de que haya actualizado los webhooks manualmente para respetar algunos filtros, debe cambiar los webhooks al modo de configuración manual, de lo contrario todos los filtros se restablecerán en cada guardado de perfil.
Azure DevOps Permisos de usuario del servicio
Personal Access Token debe tener el siguiente nivel de acceso:
Work Items (Read, write & manage), Project and Teams (Read), Identity (Read)
En caso de que desee iniciar la sincronización unidireccional y extraer datos de AzureDevops a Targetprocess, seleccione sólo el acceso de ámbito "Lectura".
Azure DevOps APIs utilizadas por 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