Configure un espacio de datos mínimo viable para compartir datos entre organizaciones

Creada por Ramy Hcini (Think-it), Ismail Abdellaoui (Think-it), Malte Gasseling (Think-it), Jorge Hernandez Suarez (AWS) y Michael Miller (AWS)

Entorno: PoC o piloto	Tecnologías: análisis; contenedores y microservicios; lagos de datos; bases de datos; infraestructura	Carga de trabajo: código abierto
Servicios de AWS: Amazon Aurora; AWS Certificate Manager (ACM); AWS CloudFormation; Amazon EC2; Amazon EFS; Amazon EKS; Elastic Load Balancing (ELB); Amazon RDS; Amazon S3; AWS Systems Manager

Resumen

Los espacios de datos son redes federadas para el intercambio de datos en las que la confianza y el control sobre los propios datos son principios fundamentales. Permiten a las organizaciones compartir, intercambiar y colaborar en datos a escala al ofrecer una solución rentable e independiente de la tecnología.

Los espacios de datos tienen el potencial de impulsar significativamente los esfuerzos para un futuro sostenible mediante el uso de la resolución de problemas basada en datos con un end-to-end enfoque que involucre a todas las partes interesadas relevantes.

Este patrón lo guía a través del ejemplo de cómo dos empresas pueden utilizar la tecnología de espacio de datos en Amazon Web Services (AWS) para impulsar su estrategia de reducción de emisiones de carbono. En este escenario, la empresa X proporciona datos sobre las emisiones de carbono, que la empresa Y consume. Consulte la sección de información adicional para obtener los siguientes detalles de las especificaciones del espacio de datos:

• Participantes

• Caso de negocio

• Autoridad del espacio de datos

• Componentes del espacio de datos

• Servicios de espacio de datos

• Datos que se van a intercambiar

• Modelo de datos

• Conector Tractus-X EDC

El patrón incluye los pasos siguientes:

• Implementar la infraestructura necesaria para un espacio de datos básico con dos participantes en ejecución AWS.

• Intercambiar datos sobre la intensidad de las emisiones de carbono mediante los conectores de forma segura.

Este patrón implementa un clúster de Kubernetes que alojará los conectores de espacios de datos y sus servicios a través de Amazon Elastic Kubernetes Service (Amazon EKS).

Tanto el plano de control como el plano de datos de Eclipse Dataspace Components (EDC) se implementan en Amazon EKS. El gráfico oficial de Tractus-X Helm despliega los servicios de PostgreSQL y Vault como dependencias. HashiCorp

Además, el servicio de identidad se implementa en Amazon Elastic Compute Cloud (Amazon EC2) para replicar un escenario real de un espacio de datos mínimo viable (MVDS).

Requisitos previos y limitaciones

Requisitos previos 

• Un activo Cuenta de AWS para implementar la infraestructura que elijas Región de AWS

• Un usuario AWS Identity and Access Management (IAM) con acceso a Amazon S3 que se utilizará temporalmente como usuario técnico (el conector EDC actualmente no admite el uso de funciones). Le recomendamos que cree un usuario de IAM específico para esta demostración y que este usuario tenga permisos limitados asociados a él).

• AWS Command Line Interface (AWS CLI) instalado y configurado según su elección Región de AWS

• AWS credenciales de seguridad

• eksctl en su estación de trabajo

• Git en tu estación de trabajo

• kubectl

• Helm

• Cartero

• Un certificado AWS Certificate Manager SSL/TLS (ACM)

• Un nombre DNS que apuntará a un Application Load Balancer (el nombre DNS debe estar cubierto por el certificado ACM)

• HashiCorp Vault (para obtener información sobre AWS Secrets Manager cómo administrar secretos, consulte la sección Información adicional).

Versiones de producto

• AWS CLI versión 2+

• Colección Postman v2.1

Limitaciones

• Selección de conectores: esta implementación utiliza un conector basado en EDC. Sin embargo, asegúrese de tener en cuenta los puntos fuertes y las funcionalidades de los conectores EDC y FIWARE True para tomar una decisión informada que se ajuste a las necesidades específicas de la implementación.

• Construcción del conector EDC: la solución de despliegue elegida se basa en el diagrama Tractus-X EDC Connector Helm, una opción de despliegue bien establecida y ampliamente probada. La decisión de utilizar este gráfico se debe a su uso habitual y a la inclusión de las extensiones esenciales en la versión proporcionada. Si bien PostgreSQL HashiCorp y Vault son componentes predeterminados, tiene la flexibilidad de personalizar su propia compilación de conectores si es necesario.

• Acceso al clúster privado: el acceso al clúster de EKS implementado está restringido a los canales privados. La interacción con el clúster se realiza exclusivamente mediante el uso de kubectl un IAM. El acceso público a los recursos del clúster se puede habilitar mediante el uso de balanceadores de carga y nombres de dominio, que deben implementarse de forma selectiva para exponer servicios específicos a una red más amplia. Sin embargo, no recomendamos proporcionar acceso público.

• Centrado en la seguridad: se hace hincapié en resumir las configuraciones de seguridad según las especificaciones predeterminadas, de modo que pueda concentrarse en los pasos necesarios para el intercambio de datos de los conectores EDC. Si bien se mantiene la configuración de seguridad predeterminada, es imprescindible habilitar las comunicaciones seguras antes de exponer el clúster a la red pública. Esta precaución garantiza una base sólida para el manejo seguro de los datos.

• Costo de infraestructura: se puede obtener una estimación del costo de la infraestructura utilizando el AWS Pricing Calculator. Un cálculo sencillo muestra que los costes pueden ascender a 162,92 USD al mes para la infraestructura implementada.

Arquitectura

La arquitectura MVDS consta de dos nubes privadas virtuales (VPC), una para el servicio de identidad del Sistema de aprovisionamiento dinámico de atributos (DAPS) y otra para Amazon EKS.

Arquitectura DAPS

El siguiente diagrama muestra la ejecución de DAPS en instancias EC2 controladas por un grupo de Auto Scaling. Un Application Load Balancer y una tabla de enrutamiento muestran los servidores DAPS. Amazon Elastic File System (Amazon EFS) sincroniza los datos entre las instancias de DAPS.

Arquitectura Amazon EKS

Los espacios de datos están diseñados para ser soluciones independientes de la tecnología y existen varias implementaciones. Este patrón utiliza un clúster de Amazon EKS para implementar los componentes técnicos del espacio de datos. El siguiente diagrama muestra la implementación del clúster EKS. Los nodos de trabajo se instalan en subredes privadas. Los pods de Kubernetes acceden a la instancia de Amazon Relational Database Service (Amazon RDS) para PostgreSQL que también se encuentra en las subredes privadas. Los pods de Kubernetes almacenan datos compartidos en Amazon S3.

Herramientas

AWS servicios

• AWS CloudFormationle ayuda a configurar AWS los recursos, aprovisionarlos de forma rápida y coherente y administrarlos a lo largo de su ciclo de vida en todas Cuentas de AWS las regiones.

• Amazon Elastic Compute Cloud (Amazon EC2) brinda capacidad de computación escalable en la Nube de AWS. Puede lanzar tantos servidores virtuales como necesite y escalarlos o reducirlos con rapidez.

• Amazon Elastic File System (Amazon EFS) lo ayuda a crear y configurar sistemas de archivos compartidos en la Nube de AWS.

• Amazon Elastic Kubernetes Service (Amazon EKS) le ayuda a ejecutar AWS Kubernetes sin necesidad de instalar o mantener su propio plano de control o nodos de Kubernetes.

• Amazon Simple Storage Service (Amazon S3) es un servicio de almacenamiento de objetos basado en la nube que le ayuda a almacenar, proteger y recuperar cualquier cantidad de datos.

• Elastic Load Balancing (ELB) distribuye el tráfico entrante de aplicaciones o redes entre varios destinos. Así, por ejemplo, puede distribuir el tráfico entre instancias de EC2, contenedores y direcciones IP de una o varias zonas de disponibilidad.

Otras herramientas

• eksctl: es una utilidad sencilla de línea de comandos para crear y administrar clústeres de Kubernetes en Amazon EKS.

• Git es un sistema de control de versiones distribuido de código abierto.

• HashiCorp Vault proporciona un almacenamiento seguro con acceso controlado para las credenciales y otra información confidencial.

• Helm es un administrador de paquetes de código abierto para Kubernetes que le ayuda a instalar y administrar aplicaciones en su clúster de Kubernetes.

• kubectl: una interfaz de la línea de comandos que le ayuda en la ejecución de comandos en clústeres de Kubernetes.

• Postman es una plataforma de API.

Repositorio de código

Los archivos YAML de configuración de Kubernetes y los scripts de Python para este patrón están disponibles en el repositorio. GitHub aws-patterns-edc El patrón también usa el repositorio EDC de Tractus-X.

Prácticas recomendadas

Amazon EKS y el aislamiento de las infraestructuras de los participantes

Los espacios de nombres en Kubernetes separarán la infraestructura del proveedor X de la empresa de la infraestructura del consumidor Y siguiendo este patrón. Para obtener más información, consulte las guías de mejores prácticas de EKS.

En una situación más realista, cada participante tendría un clúster de Kubernetes independiente que se ejecutaría dentro del suyo. Cuenta de AWS Los participantes del espacio de datos podrían acceder a la infraestructura compartida (DAPS según este patrón) y, al mismo tiempo, estaría completamente separada de las infraestructuras de los participantes.

Epics

Configure el entorno y aprovisione un clúster EKS e instancias EC2

Tarea	Descripción	Habilidades requeridas
Clonar el repositorio.	Para clonar el repositorio en su estación de trabajo, ejecute el siguiente comando: git clone https://github.com/Think-iT-Labs/aws-patterns-edc La estación de trabajo debe tener acceso a su. Cuenta de AWS	DevOps ingeniero
Aprovisione el clúster de Kubernetes y configure los espacios de nombres.	Para implementar un clúster EKS predeterminado simplificado en su cuenta, ejecute el siguiente eksctl comando en la estación de trabajo en la que clonó el repositorio: eksctl create cluster El comando crea la VPC y las subredes públicas y privadas que abarcan tres zonas de disponibilidad diferentes. Una vez creada la capa de red, el comando crea dos instancias m5.large EC2 dentro de un grupo de Auto Scaling. Para obtener más información y ejemplos de resultados, consulte la guía eksctl. Tras aprovisionar el clúster privado, añade el nuevo clúster de EKS a tu configuración local de Kubernetes ejecutando el siguiente comando: aws eks update-kubeconfig --name <EKS CLUSTER NAME> --region <AWS REGION> Este patrón utiliza el para ejecutar todos eu-west-1 Región de AWS los comandos. Sin embargo, puede ejecutar los mismos comandos en el modo que prefiera Región de AWS. Para confirmar que los nodos EKS se están ejecutando y están preparados, ejecute el siguiente comando: kubectl get nodes	DevOps ingeniero
Configure los espacios de nombres.	Para crear espacios de nombres para el proveedor y el consumidor, ejecute los siguientes comandos: kubectl create ns provider kubectl create ns consumer En este patrón, es importante utilizar provider y consumer como espacios de nombres para adaptarlos a las configuraciones en los siguientes pasos.	DevOps ingeniero

Implemente el servicio de identidad

Tarea	Descripción	Habilidades requeridas
Implemente DAPS mediante AWS CloudFormation.	Para facilitar la administración de las operaciones de DAPS, el servidor DAPS se instala en las instancias EC2. Para instalar DAPS, utilice la plantilla.AWS CloudFormation Necesitará el certificado ACM y el nombre DNS de la sección de requisitos previos. La plantilla implementa y configura lo siguiente: Equilibrador de carga de aplicación Grupo de escalado automático Instancias EC2 configuradas con datos de usuario para instalar todos los paquetes necesarios Roles de IAM DAPS Puede implementar la AWS CloudFormation plantilla iniciando sesión en la AWS CloudFormation consola AWS Management Console y utilizándola. También puede implementar la plantilla mediante un AWS CLI comando como el siguiente: aws cloudformation create-stack --stack-name daps \ --template-body file://aws-patterns-edc/cloudformation.yml --parameters \ ParameterKey=CertificateARN,ParameterValue=<ACM Certificate ARN> \ ParameterKey=DNSName,ParameterValue=<DNS name> \ ParameterKey=InstanceType,ParameterValue=<EC2 instance type> \ ParameterKey=EnvironmentName,ParameterValue=<Environment Name> --capabilities CAPABILITY_NAMED_IAM El nombre del entorno es de su elección. Recomendamos utilizar un término significativo, por ejemploDapsInfrastructure, porque se reflejará en las etiquetas de los AWS recursos. Para este patrón, t3.small es lo suficientemente grande como para ejecutar el flujo de trabajo de DAPS, que tiene tres contenedores Docker. La plantilla despliega las instancias de EC2 en subredes privadas. Esto significa que no se puede acceder directamente a las instancias a través de SSH (Secure Shell) desde Internet. Las instancias cuentan con la función de IAM y el AWS Systems Manager agente necesarios para permitir el acceso a las instancias en ejecución a través del Administrador de sesiones, una capacidad de. AWS Systems Manager Se recomienda utilizar el administrador de sesiones para acceder. Como alternativa, puede aprovisionar un host bastión para permitir el acceso SSH desde Internet. Si se utiliza el enfoque de host bastión, es posible que la instancia de EC2 tarde unos minutos más en empezar a ejecutarse. Una vez que la AWS CloudFormation plantilla se haya implementado correctamente, apunte el nombre DNS al nombre DNS de Application Load Balancer. Para confirmar, ejecute el siguiente comando: dig <DNS NAME> El resultado debería ser similar al siguiente: ; <<>> DiG 9.16.1-Ubuntu <<>> edc-pattern.think-it.io ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42344 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;edc-pattern.think-it.io. IN A ;; ANSWER SECTION: edc-pattern.think-it.io. 276 IN CNAME daps-alb-iap9zmwy3kn8-1328773120.eu-west-1.elb.amazonaws.com. daps-alb-iap9zmwy3kn8-1328773120.eu-west-1.elb.amazonaws.com. 36 IN A 52.208.240.129 daps-alb-iap9zmwy3kn8-1328773120.eu-west-1.elb.amazonaws.com. 36 IN A 52.210.155.124	DevOps ingeniero
Registre los conectores de los participantes en el servicio DAPS.	Desde cualquiera de las instancias EC2 aprovisionadas para DAPS, registre a los participantes: Ejecute el script disponible en la instancia EC2 mediante el usuario root: cd /srv/mvds/omejdn-daps Registre el proveedor: bash scripts/register_connector.sh <provider_name> Registre al consumidor: bash scripts/register_connector.sh <consumer_name> La elección de los nombres no afecta a los próximos pasos. Se recomienda usar consumer o provider companyx ycompanyy. Los comandos de registro también configurarán automáticamente el servicio DAPS con la información necesaria obtenida de los certificados y claves creados. Mientras esté conectado a un servidor DAPS, recopile la información necesaria para los pasos posteriores de la instalación: Desde omejdn-daps/config/clients.yml obtener el client id para el proveedor y el consumidor. Los client id valores son cadenas largas de dígitos hexadecimales. Del omejdn-daps/keys directorio, copie el contenido de los provider.key archivos consumer.cert consumer.keyprovider.cert,, y. Se recomienda copiar y pegar el texto en archivos con nombres similares y con el prefijo «» daps- en la estación de trabajo. Debe tener los ID de cliente del proveedor y del consumidor y cuatro archivos en el directorio de trabajo de la estación de trabajo: El nombre del archivo fuente consumer.cert pasa a ser el nombre del archivo de la estación de trabajo. daps-consumer.cert El nombre del archivo fuente consumer.key pasa a ser el nombre del archivo de la estación de trabajo. daps-consumer.key El nombre del archivo fuente provider.cert pasa a ser el nombre del archivo de la estación de trabajo. daps-provider.cert El nombre del archivo fuente provider.key pasa a ser el nombre del archivo de la estación de trabajo. daps-provider.key	DevOps ingeniero

Despliegue los conectores de los participantes

Tarea	Descripción	Habilidades requeridas
Clona el repositorio EDC de Tractus-X y usa la versión 0.4.1.	La compilación del conector EDC de Tractus-X requiere la implementación y disponibilidad de los servicios PostgreSQL (base de datos de activos) y HashiCorp Vault (administración de secretos). Existen muchas versiones diferentes de los gráficos EDC Helm de Tractus-X. Este patrón especifica la versión 0.4.1 porque utiliza el servidor DAPS. Las versiones más recientes utilizan Managed Identity Wallet (MIW) con una implementación distribuida del servicio de identidad. En la estación de trabajo en la que creó los dos espacios de nombres de Kubernetes, clone el repositorio tractusx-edc y compruebe la sucursal. release/0.4.1 git clone https://github.com/eclipse-tractusx/tractusx-edc cd tractusx-edc git checkout release/0.4.1	DevOps ingeniero
Configure el gráfico Tractus-X EDC Helm.	Modifique la configuración de la plantilla del gráfico Tractus-X Helm para permitir que ambos conectores interactúen entre sí. Para ello, debe añadir el espacio de nombres al nombre DNS del servicio para que otros servicios del clúster puedan resolverlo. Estas modificaciones deben realizarse en el charts/tractusx-connector/templates/_helpers.tpl archivo. Este patrón proporciona una versión final modificada de este archivo para su uso. Cópielo y colóquelo en la daps sección del archivocharts/tractusx-connector/templates/_helpers.tpl. Asegúrese de comentar todas las dependencias del DAPS en: charts/tractusx-connector/Chart.yaml dependencies: # IDS Dynamic Attribute Provisioning Service (IAM) # - name: daps # version: 0.0.1 # repository: "file://./subcharts/omejdn" # alias: daps # condition: install.daps	DevOps ingeniero
Configure los conectores para usar PostgreSQL en Amazon RDS.	(Opcional) La instancia de Amazon Relational Database Service (Amazon RDS) no es necesaria en este patrón. Sin embargo, recomendamos encarecidamente utilizar Amazon RDS o Amazon Aurora, ya que ofrecen funciones como alta disponibilidad y backup y recuperación. Para reemplazar PostgreSQL en Kubernetes por Amazon RDS, haga lo siguiente: Aprovisione la instancia de Amazon RDS for PostgreSQL. EnChart.yaml, comente la sección. PostgreSQL En provider_values.yml yconsumer_values.yml, configure la postgresql sección de la siguiente manera: postgresql: auth: database: edc password: <RDS PASSWORD> username: <RDS Username> jdbcUrl: jdbc:postgresql://<RDS DNS NAME>:5432/edc username: <RDS Username> password: <RDS PASSWORD> primary: persistence: enabled: false readReplicas: persistence: enabled: false	DevOps ingeniero
Configure e implemente el conector del proveedor y sus servicios.	Para configurar el conector del proveedor y sus servicios, haga lo siguiente: Para descargar el provider_edc.yaml archivo del edc_helm_configs directorio a la carpeta de gráficos de Helm actual, ejecute el siguiente comando: wget -q https://raw.githubusercontent.com/Think-iT-Labs/aws-patterns-edc/main/edc_helm_configs/provider_edc.yaml> -P charts/tractusx-connector/ Sustituya las siguientes variables (también marcadas en el archivo) por sus valores: CLIENT_ID‒ El ID generado por el DAPS. CLIENT_IDDebe estar /srv/mvds/omejdn-daps/config/clients.yml/config/clients.yml en el servidor DAPS. Debe ser una cadena de caracteres hexadecimales. DAPS_URL‒ La URL del servidor DAPS. Debe https://{DNS name} usar el nombre DNS que configuró cuando ejecutó la AWS CloudFormation plantilla. VAULT_TOKEN‒ El token que se utilizará para la autorización de Vault. Elige cualquier valor. vault.fullnameOverride ‒ vault-provider. vault.hashicorp.url ‒ http://vault-provider:8200/. Los valores anteriores asumen que el nombre de la implementación y el nombre del espacio de nombres son proveedores. Para ejecutar el diagrama de Helm desde su estación de trabajo, utilice los siguientes comandos: cd charts/tractusx-connector helm dependency build helm upgrade --install provider ./ -f provider_edc.yaml -n provider	DevOps ingeniero
Añada el certificado y las claves a la bóveda del proveedor.	Para evitar confusiones, genere los siguientes certificados fuera del tractusx-edc/charts directorio. Por ejemplo, ejecute el siguiente comando para cambiar a su directorio principal: cd ~ Ahora tiene que añadir al almacén los secretos que necesita el proveedor. Los nombres de los secretos del almacén son los valores de las claves de la secretNames: sección del provider_edc.yml archivo. De forma predeterminada, se configuran de la siguiente manera: secretNames: transferProxyTokenSignerPrivateKey: transfer-proxy-token-signer-private-key transferProxyTokenSignerPublicKey: transfer-proxy-token-signer-public-key transferProxyTokenEncryptionAesKey: transfer-proxy-token-encryption-aes-key dapsPrivateKey: daps-private-key dapsPublicKey: daps-public-key Inicialmente se generan una clave de estándar de cifrado avanzado (AES), una clave privada, una clave pública y un certificado autofirmado. Posteriormente, se añaden como secretos a la bóveda. Además, este directorio debe contener los daps-provider.key archivos daps-provider.cert y archivos que copió del servidor DAPS. Ejecute los comandos siguientes: # generate a private key openssl ecparam -name prime256v1 -genkey -noout -out provider-private-key.pem # generate corresponding public key openssl ec -in provider-private-key.pem -pubout -out provider-public-key.pem # create a self-signed certificate openssl req -new -x509 -key provider-private-key.pem -out provider-cert.pem -days 360 # generate aes key openssl rand -base64 32 > provider-aes.key Antes de añadir los secretos al almacén, conviértalos de líneas múltiples en líneas simples sustituyendo los saltos de línea por: \n cat provider-private-key.pem | sed 's/$/\\\\n/'|tr -d '\\n' > provider-private-key.pem.line cat provider-public-key.pem | sed 's/$/\\\\n/'|tr -d '\\n' > provider-public-key.pem.line cat provider-cert.pem | sed 's/$/\\\\n/'|tr -d '\\n' > provider-cert.pem.line cat provider-aes.key | sed 's/$/\\\\n/'|tr -d '\\n' > provider-aes.key.line ## The following block is for daps certificate and key openssl x509 -in daps-provider.cert -outform PEM | sed 's/$/\\\\n/'|tr -d '\\n' > daps-provider.cert.line cat daps-provider.key | sed 's/$/\\\\n/'|tr -d '\\n' > daps-provider.key.line Para formatear los secretos que se añadirán a Vault, ejecuta los siguientes comandos: JSONFORMAT='{"content": "%s"}' #create a single line in JSON format printf "${JSONFORMAT}\\n" "`cat provider-private-key.pem.line`" > provider-private-key.json printf "${JSONFORMAT}\\n" "`cat provider-public-key.pem.line`" > provider-public-key.json printf "${JSONFORMAT}\\n" "`cat provider-cert.pem.line`" > provider-cert.json printf "${JSONFORMAT}\\n" "`cat provider-aes.key.line`" > provider-aes.json printf "${JSONFORMAT}\\n" "`cat daps-provider.key.line`" > daps-provider.key.json printf "${JSONFORMAT}\\n" "`cat daps-provider.cert.line`" > daps-provider.cert.json Los secretos están ahora en formato JSON y están listos para añadirse al almacén. Para obtener el nombre del pod del almacén, ejecute el siguiente comando: kubectl get pods -n provider|egrep "vault|NAME" El nombre del pod será similar a"vault-provider-0". Este nombre se utiliza al crear un puerto de reenvío al almacén. El reenvío de puertos permite acceder a la bóveda para añadir el secreto. Debe ejecutarlo desde una estación de trabajo que tenga configuradas las credenciales de AWS. Para acceder al almacén, utilice esta opción kubectl para configurar un reenvío de puertos: kubectl port-forward <VAULT_POD_NAME> 8200:8200 -n provider Ahora debería poder acceder a la bóveda a través de su navegador o la CLI. Navegador Con el navegador, vaya a http://127.0.0.1:8200, donde se utilizará el puerto de reenvío que configuró. Inicie sesión con el token que configuró anteriormenteprovider_edc.yml. En el motor de secretos, crea tres secretos. Cada secreto tendrá un Path for this secret valor, que es el nombre del secreto que se muestra en la siguiente lista. Dentro de la secret data sección, el nombre de la clave será content y el valor será la única línea de texto del archivo respectivo nombrado.line. Los nombres secretos provienen de la secretNames sección del provider_edc.yml archivo. Cree los siguientes secretos: Secreto transfer-proxy-token-signer-private-key con nombre de archivo provider-private-key.pem.line Secreto transfer-proxy-token-signer-public-key con nombre de archivo provider-cert.pem.line Secreto transfer-proxy-token-encryption-aes-key con nombre de archivo provider-aes.key.line Secreto daps-private-key con nombre de archivo daps-provider.key.line Secreto daps-public-key con nombre de archivo daps-provider.cert.line CLI de Vault La CLI también utilizará el reenvío de puertos que configuró. En su estación de trabajo, instale la CLI de Vault siguiendo las instrucciones de la documentación de HashiCorp Vault. Para iniciar sesión en el almacén con el token que configuróprovider_edc.yml, ejecute el siguiente comando: vault login -address=http://127.0.0.1:8200 Con el token correcto, deberías ver el mensaje "Success! You are now authenticated." Para crear los secretos mediante los archivos con formato JSON que creó anteriormente, ejecute el código siguiente: vault kv put -address=http://127.0.0.1:8200 secret/transfer-proxy-token-signer-private-key @provider-private-key.json vault kv put -address=http://127.0.0.1:8200 secret/transfer-proxy-token-signer-public-key @provider-cert.json vault kv put -address=http://127.0.0.1:8200 secret/transfer-proxy-token-encryption-aes-key @provider-aes.json vault kv put -address=http://127.0.0.1:8200 secret/daps-private-key @daps-provider.key.json vault kv put -address=http://127.0.0.1:8200 secret/daps-public-key @daps-provider.cert.json	DevOps ingeniero
Configure e implemente el conector de consumo y sus servicios.	Los pasos para configurar e implementar el consumidor son similares a los que se realizaron para el proveedor: Para copiarlos consumer_edc.yaml del aws-patterns-edcrepositorio a la carpeta tractusx-edc/charts/tractusx-connecto r, ejecute los siguientes comandos: cd tractusx-edc wget -q https://raw.githubusercontent.com/Think-iT-Labs/aws-patterns-edc/main/edc_helm_configs/consumer_edc.yaml -P charts/tractusx-connector/ Actualice las siguientes variables con sus valores reales: CONSUMER_CLIENT_ID‒ El ID generado por DAPS. CONSUMER_CLIENT_IDDebe estar config/clients.yml en el servidor DAPS. DAPS_URL‒ La misma URL de DAPS que utilizó para el proveedor. VAULT_TOKEN‒ El token que se utilizará para la autorización de Vault. Elige cualquier valor. vault.fullnameOverride ‒ vault-consumer vault.hashicorp.url ‒ http://vault-provider:8200/ Los valores anteriores asumen que el nombre de la implementación y el nombre del espacio de nombres son. consumer Para ejecutar el gráfico de Helm, usa los siguientes comandos: cd charts/tractusx-connector helm upgrade --install consumer ./ -f consumer_edc.yaml -n consumer
Añada el certificado y las claves a la bóveda del consumidor.	Desde el punto de vista de la seguridad, recomendamos volver a generar los certificados y las claves de cada participante del espacio de datos. Este patrón regenera los certificados y las claves para el consumidor. Los pasos son muy similares a los del proveedor. Puede comprobar los nombres secretos del consumer_edc.yml archivo. Los nombres de los secretos del almacén son los valores de las claves de la secretNames: secciónconsumer_edc.yml file. De forma predeterminada, se configuran de la siguiente manera: secretNames: transferProxyTokenSignerPrivateKey: transfer-proxy-token-signer-private-key transferProxyTokenSignerPublicKey: transfer-proxy-token-signer-public-key transferProxyTokenEncryptionAesKey: transfer-proxy-token-encryption-aes-key dapsPrivateKey: daps-private-key dapsPublicKey: daps-public-key Los daps-consumer.key archivos daps-consumer.cert y que copió del servidor DAPS ya deberían existir en este directorio. Ejecute los comandos siguientes: # generate a private key openssl ecparam -name prime256v1 -genkey -noout -out consumer-private-key.pem # generate corresponding public key openssl ec -in consumer-private-key.pem -pubout -out consumer-public-key.pem # create a self-signed certificate openssl req -new -x509 -key consumer-private-key.pem -out consumer-cert.pem -days 360 # generate aes key openssl rand -base64 32 > consumer-aes.key Edite manualmente los archivos para sustituir los saltos de \n línea por ellos o utilice tres comandos similares a los siguientes: cat consumer-private-key.pem | sed 's/$/\\\\n/'|tr -d '\\n' > consumer-private-key.pem.line cat consumer-public-key.pem | sed 's/$/\\\\n/'|tr -d '\\n' > consumer-public-key.pem.line cat consumer-cert.pem | sed 's/$/\\\\n/'|tr -d '\\n' > consumer-cert.pem.line cat consumer-aes.key | sed 's/$/\\\\n/'|tr -d '\\n' > consumer-aes.key.line cat daps-consumer.cert | sed 's/$/\\\\n/'|tr -d '\\n' > daps-consumer.cert.line cat daps-consumer.key | sed 's/$/\\\\n/'|tr -d '\\n' > daps-consumer.key.line Para formatear los secretos que se añadirán a Vault, ejecuta los siguientes comandos: JSONFORMAT='{"content": "%s"}' #create a single line in JSON format printf "${JSONFORMAT}\\n" "`cat consumer-private-key.pem.line`" > consumer-private-key.json printf "${JSONFORMAT}\\n" "`cat consumer-public-key.pem.line`" > consumer-public-key.json printf "${JSONFORMAT}\\n" "`cat consumer-cert.pem.line`" > consumer-cert.json printf "${JSONFORMAT}\\n" "`cat consumer-aes.key.line`" > consumer-aes.json printf "${JSONFORMAT}\\n" "`cat daps-consumer.key.line`" > daps-consumer.key.json printf "${JSONFORMAT}\\n" "`cat daps-consumer.cert.line`" > daps-consumer.cert.json Los secretos están ahora en formato JSON y están listos para añadirse al almacén. Para obtener el nombre del pod de la bóveda del consumidor, ejecuta el siguiente comando: kubectl get pods -n consumer | egrep "vault|NAME" El nombre del pod será similar a"vault-consumer-0". Este nombre se utiliza al crear un puerto de reenvío al almacén. El reenvío de puertos permite acceder a la bóveda para añadir el secreto. Debe ejecutarlo desde una estación de trabajo que tenga configuradas AWS las credenciales. Para acceder al almacén, utilice kubectl para configurar un reenvío de puertos: kubectl port-forward <VAULT_POD_NAME> 8201:8200 -n consumer Esta vez, el puerto local es el 8201, por lo que puede disponer de reenvíos de puertos tanto para el productor como para el consumidor. Navegador Puedes usar tu navegador para conectarte a http://localhost:8201/ para acceder a la bóveda del consumidor y crear los secretos con los nombres y el contenido tal y como se describe. Los secretos y archivos que contienen el contenido son los siguientes: Secreto transfer-proxy-token-signer-private-key con nombre de archivo consumer-private-key.pem.line Secreto transfer-proxy-token-signer-public-key con nombre de archivo consumer-cert.pem.line Secreto transfer-proxy-token-encryption-aes-key con nombre de archivo consumer-aes.key.line CLI de Vault Con la CLI de Vault, puede ejecutar los siguientes comandos para iniciar sesión en el almacén y crear los secretos: Inicie sesión en el almacén con el token que configuróconsumer_edc.yml: vault login -address=http://127.0.0.1:8201 Con el token correcto, deberías ver el mensaje "Success! You are now authenticated." Para crear los secretos con los archivos con formato JSON que creó anteriormente, ejecute el siguiente código: vault kv put -address=http://127.0.0.1:8201 secret/transfer-proxy-token-signer-private-key @consumer-private-key.json vault kv put -address=http://127.0.0.1:8201 secret/transfer-proxy-token-signer-public-key @consumer-cert.json vault kv put -address=http://127.0.0.1:8201 secret/transfer-proxy-token-encryption-aes-key @consumer-aes.json vault kv put -address=http://127.0.0.1:8201 secret/daps-private-key @daps-consumer.key.json vault kv put -address=http://127.0.0.1:8201 secret/daps-public-key @daps-consumer.cert.json	DevOps ingeniero

Configure un cliente HTTP para interactuar con la API de administración de los conectores

Tarea	Descripción	Habilidades requeridas
Configure el reenvío de puertos.	Para comprobar el estado de los pods, ejecuta los siguientes comandos: kubectl get pods -n provider kubectl get pods -n consumer Para asegurarte de que las implementaciones de Kubernetes se realizaron correctamente, consulta los registros de los pods de Kubernetes proveedores y consumidores ejecutando los siguientes comandos: kubectl logs -n provider <producer control plane pod name> kubectl logs -n consumer <consumer control plane pod name> El clúster es privado y no se puede acceder a él públicamente. Para interactuar con los conectores, utilice la función de reenvío de puertos de Kubernetes para reenviar el tráfico generado por su máquina al plano de control del conector. En el primer terminal, reenvíe las solicitudes del consumidor a la API de administración a través del puerto 8300: kubectl port-forward deployment/consumer-tractusx-connector-controlplane 8300:8081 -n consumer En el segundo terminal, reenvía las solicitudes del proveedor a la API de administración a través del puerto 8400: kubectl port-forward deployment/provider-tractusx-connector-controlplane 8400:8081 -n provider	DevOps ingeniero
Cree depósitos S3 para el proveedor y el consumidor.	Actualmente, el conector EDC no utiliza credenciales de AWS temporales, como las que se proporcionan al asumir un rol. El EDC solo admite el uso de una combinación de ID de clave de acceso de IAM y clave de acceso secreta. Se necesitan dos cubos S3 para los pasos posteriores. Se utiliza un depósito de S3 para almacenar los datos puestos a disposición por el proveedor. El otro depósito de S3 es para los datos que recibe el consumidor. El usuario de IAM debe tener permiso para leer y escribir objetos únicamente en los dos cubos con nombre. Es necesario crear y mantener a salvo un identificador de clave de acceso y un par de claves de acceso secretas. Una vez que se haya dado de baja este MVDS, se debe eliminar el usuario de IAM. El siguiente código es un ejemplo de política de IAM para el usuario: { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt1708699805237", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:ListAllMyBuckets", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:ListBucketVersions", "s3:PutObject" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::<S3 Provider Bucket>", "arn:aws:s3:::<S3 Consumer Bucket>", "arn:aws:s3:::<S3 Provider Bucket>/*", "arn:aws:s3:::<S3 Consumer Bucket>/*" ] } ] }	DevOps ingeniero
Configure Postman para que interactúe con el conector.	Ahora puede interactuar con los conectores a través de su instancia EC2. Utilice Postman como cliente HTTP y proporcione colecciones de Postman para los conectores del proveedor y del consumidor. Importa las colecciones del aws-pattern-edc repositorio a tu instancia de Postman. Este patrón usa variables de colección de Postman para proporcionar información a tus solicitudes.	Desarrollador de aplicaciones, ingeniero de datos

Proporcione los datos de la huella de carbono de la empresa X a través del conector

Tarea	Descripción	Habilidades requeridas
Prepare los datos sobre la intensidad de las emisiones de carbono para compartirlos.	En primer lugar, debe decidir el activo de datos que se va a compartir. Los datos de la empresa X representan la huella de emisiones de carbono de su flota de vehículos. El peso es el peso bruto del vehículo (GVW) en toneladas y las emisiones se expresan en gramos de CO2 por tonelada-kilómetro (g de CO2 e/t-km) según la medición de la rueda al pozo (WTW): Tipo de vehículo: furgoneta; peso: < 3,5; emisiones: 800 Tipo de vehículo: camión urbano; peso: 3,5‒7,5; emisiones: 315 Tipo de vehículo: vehículo de transporte de mercancías de tamaño medio (MGV); peso: 7,5‒20; emisiones: 195 Tipo de vehículo: vehículo pesado de transporte de mercancías (HGV); peso: > 20; emisiones: 115 Los datos de ejemplo se encuentran en el carbon_emissions_data.json archivo del aws-patterns-edc repositorio. La empresa X utiliza Amazon S3 para almacenar objetos. Cree el bucket de S3 y almacene allí el objeto de datos de ejemplo. Los siguientes comandos crean un depósito de S3 con la configuración de seguridad predeterminada. Recomendamos encarecidamente consultar las prácticas recomendadas de seguridad para Amazon S3. aws s3api create-bucket <BUCKET_NAME> --region <AWS_REGION> # You need to add '--create-bucket-configuration # LocationConstraint=<AWS_REGION>' if you want to create # the bucket outside of us-east-1 region aws s3api put-object --bucket <BUCKET_NAME> \ --key <S3 OBJECT NAME> \ --body <PATH OF THE FILE TO UPLOAD> El nombre del bucket de S3 debe ser único a nivel mundial. Para obtener más información sobre las reglas de nomenclatura, consulte la documentación de AWS.	Desarrollador de aplicaciones, ingeniero de datos
Registre el activo de datos en el conector del proveedor mediante Postman.	Un activo de datos de un conector EDC contiene el nombre de los datos y su ubicación. En este caso, el activo de datos del conector EDC apuntará al objeto creado en el depósito S3: Conector: proveedor Solicitud: crear un activo Variables de recopilación: actualizaciónASSET_NAME. Elija un nombre significativo que represente el activo. Cuerpo de la solicitud: actualice el cuerpo de la solicitud con el depósito de S3 que creó para el proveedor. "dataAddress": { "edc:type": "AmazonS3", "name": "Vehicle Carbon Footprint", "bucketName": "<REPLACE WITH THE SOURCE BUCKET NAME>", "keyName": "<REPLACE WITH YOUR OBJECT NAME>", "region": "<REPLACE WITH THE BUCKET REGION>", "accessKeyId": "<REPLACE WITH YOUR ACCESS KEY ID>", "secretAccessKey": "<REPLACE WITH SECRET ACCESS KEY>" } Respuesta: una solicitud correcta devuelve la hora de creación y el ID del activo recién creado. { "@id": "c89aa31c-ec4c-44ed-9e8c-1647f19d7583" } Variable de colección ASSET_ID: actualice la variable de colección Postman ASSET_ID con el identificador que generó automáticamente el conector EDC tras su creación.	Desarrollador de aplicaciones, ingeniero de datos
Defina la política de uso del activo.	Un activo de datos de la EDC debe estar asociado a políticas de uso claras. En primer lugar, cree la definición de política en el conector del proveedor. La política de la empresa X es permitir que los participantes del espacio de datos utilicen los datos de la huella de emisiones de carbono. Órgano de la solicitud: Conector: proveedor Solicitud: crear una política Variables de recopilación: actualice la Policy Name variable con el nombre de la política. Respuesta: una solicitud correcta devuelve la hora de creación y el identificador de política de la política recién creada. Actualice la variable de recopilación POLICY_ID con el ID de la política generada por el conector EDC tras su creación.	Desarrollador de aplicaciones, ingeniero de datos
Defina una oferta de contrato de EDC para el activo y su política de uso.	Para permitir que otros participantes soliciten acceso a sus datos, ofrézcalos en un contrato que especifique las condiciones de uso y los permisos: Conector: proveedor Solicitud: crear una definición de contrato Variables de recopilación: actualice la Contract Name variable con un nombre para la oferta o definición del contrato.	Desarrollador de aplicaciones, ingeniero de datos

Descubra los activos y llegue a un acuerdo sobre los contratos definidos

Tarea	Descripción	Habilidades requeridas
Solicite el catálogo de datos que comparte la empresa X.	Como consumidora de datos en el espacio de datos, la empresa Y primero debe descubrir los datos que comparten otros participantes. En esta configuración básica, puede hacerlo pidiéndole al conector consumidor que solicite directamente al conector proveedor el catálogo de activos disponibles. Conector: consumidor Solicitud: Solicite un catálogo Respuesta: Todos los activos de datos disponibles del proveedor junto con sus políticas de uso adjuntas. Como consumidor de datos, busque el contrato que le interese y actualice las siguientes variables de recopilación en consecuencia. CONTRACT_OFFER_ID‒ El identificador de la oferta contractual que el consumidor quiere negociar ASSET_ID‒ El identificador del activo que el consumidor quiere negociar PROVIDER_CLIENT_ID‒ El ID del conector del proveedor con el que se va a negociar	Desarrollador de aplicaciones, ingeniero de datos
Inicie una negociación contractual para obtener los datos de intensidad de emisiones de carbono de la empresa X.	Ahora que ha identificado el activo que quiere consumir, inicie un proceso de negociación del contrato entre el consumidor y el proveedor. Conector: consumidor Solicitud: Negociación de contrato Variables de recopilación: actualice la CONSUMER_CLIENT_ID variable con el ID del conector de consumo con el que desee negociar. Es posible que el proceso tarde algún tiempo en alcanzar el estado VERIFICADO. Puede comprobar el estado de la negociación del contrato y el identificador del acuerdo correspondiente mediante la Get Negotiation solicitud.	Desarrollador de aplicaciones, ingeniero de datos

Consuma los datos utilizando el acuerdo de contrato

Tarea	Descripción	Habilidades requeridas
Consume datos de puntos finales HTTP.	(Opción 1) Para usar el plano de datos HTTP para consumir datos en el espacio de datos, puede usar webhook.site para emular un servidor HTTP e iniciar el proceso de transferencia en el conector de consumo: Conector: Consumer Solicitud: Negociación de contrato Variables de recopilación: actualice la Contract Agreement ID variable con el ID del acuerdo de contrato generado por el conector EDC. Cuerpo de la solicitud: actualice el cuerpo de la solicitud para HTTP especificarlo dataDestination junto a la URL del webhook: { "dataDestination": { "type": "HttpProxy" }, "privateProperties": { "receiverHttpEndpoint": "<WEBHOOK URL>" } } El conector enviará la información necesaria para descargar el archivo directamente a la URL del webhook. La carga útil recibida es similar a la siguiente: { "id": "dcc90391-3819-4b54-b401-1a005a029b78", "endpoint": "http://consumer-tractusx-connector-dataplane.consumer:8081/api/public", "authKey": "Authorization", "authCode": "<AUTH CODE YOU RECEIVE IN THE ENDPOINT>", "properties": { "https://w3id.org/edc/v0.0.1/ns/cid": "vehicle-carbon-footprint-contract:4563abf7-5dc7-4c28-bc3d-97f45e32edac:b073669b-db20-4c83-82df-46b583c4c062" } } Utilice las credenciales recibidas para obtener el activo de S3 que compartió el proveedor. En este último paso, debes enviar la solicitud al plano de datos del consumidor (reenviar los puertos correctamente), tal y como se indica en la carga útil (endpoint).	Desarrollador de aplicaciones, ingeniero de datos
Consume los datos de los depósitos de S3 directamente.	(Opción 2) Utilice la integración de Amazon S3 con el conector EDC y apunte directamente al depósito S3 de la infraestructura de consumo como destino: Cuerpo de la solicitud: actualice el cuerpo de la solicitud para especificar el bucket de S3 como DataDestination. Debe ser el depósito de S3 que creó anteriormente para almacenar los datos recibidos por el consumidor. { "dataDestination": { "type": "AmazonS3", "bucketName": "{{ REPLACE WITH THE DESTINATION BUCKET NAME }}", "keyName": "{{ REPLACE WITH YOUR OBJECT NAME }}", "region": "{{ REPLACE WITH THE BUCKET REGION }}", "accessKeyId": "{{ REPLACE WITH YOUR ACCESS KEY ID }}", "secretAccessKey": "{{ REPLACE WITH SECRET ACCESS KEY }}" } } }	Desarrollador de aplicaciones, ingeniero de datos

Resolución de problemas

Problema	Solución
El conector podría plantear un problema relacionado con el formato PEM del certificado.	Concatene el contenido de cada archivo en una sola línea agregando. \n

Recursos relacionados

• DSSC

• Creación de espacios de datos para casos de uso de sostenibilidad (estrategia AWS Prescriptive Guidance de Think-IT)

• AWS para espacios de datos

• Documentación de Tractus-X

• DAPS

• Permitir el intercambio de datos a través de espacios de datos y AWS (entrada del blog)

Información adicional

Especificaciones del espacio de datos

Participantes

Participante	Descripción de la empresa	Enfoque de la empresa
Empresa X	Opera una flota de vehículos en Europa y Sudamérica para transportar diversas mercancías.	Su objetivo es tomar decisiones basadas en datos para reducir la intensidad de su huella de emisiones de carbono.
Empresa Y	Una autoridad reguladora ambiental	Hace cumplir las normas y políticas ambientales diseñadas para monitorear y mitigar el impacto ambiental de las empresas e industrias, incluida la intensidad de las emisiones de carbono.

Caso de negocio

La empresa X utiliza la tecnología del espacio de datos para compartir los datos sobre la huella de carbono con un auditor de cumplimiento, la empresa Y, a fin de evaluar y abordar el impacto ambiental de las operaciones logísticas de la empresa X.

Autoridad en materia de espacio de datos

La autoridad del espacio de datos es un consorcio de las organizaciones que gobiernan el espacio de datos. En este patrón, tanto la empresa X como la empresa Y forman el órgano de gobierno y representan una autoridad federada en materia de espacio de datos.

Componentes del espacio de datos

Componente	Implementación elegida	Información adicional
Protocolo de intercambio de conjuntos de datos	Protocolo Dataspace versión 0.8	JSON-LD Vocabulario del catálogo de datos (DCAT)
Conector de espacio de datos	Conector Tractus-X EDC versión 0.4.1	Extensiones EDC
Políticas de intercambio de datos	Política de USO predeterminada	Lenguaje abierto de derechos digitales (ODRL)

Servicios de espacio de datos

Servicio	Implementación	Información adicional
Servicio de identidad	Sistema dinámico de aprovisionamiento de atributos (DAPS)	«Un sistema dinámico de aprovisionamiento de atributos (DAPS) tiene la intención de determinar ciertos atributos de las organizaciones y los conectores. Por lo tanto, los terceros no necesitan confiar en estos últimos siempre que confíen en las afirmaciones del DAPS». — DAPS Para centrarse en la lógica del conector, el espacio de datos se implementa en una máquina Amazon EC2 mediante Docker Compose.
Servicio de detección	Catálogo federado Gaia-X	«El Catálogo Federado constituye un repositorio indexado de las autodescripciones de Gaia-X que permite descubrir y seleccionar los proveedores y sus ofertas de servicios. Las autodescripciones son la información proporcionada por los participantes sobre sí mismos y sobre sus servicios en forma de propiedades y reclamaciones». — Kickstarter del ecosistema Gaia-X

Datos que se van a intercambiar

Activos de datos	Descripción	Formato
Datos de emisiones de carbono	Valores de intensidad para diferentes tipos de vehículos en la región especificada (Europa y Sudamérica) de toda la flota de vehículos	Archivo JSON

Modelo de datos

{
  "region": "string",
  "vehicles": [
// Each vehicle type has its Gross Vehicle Weight (GVW) category and its emission intensity in grams of CO2 per Tonne-Kilometer (g CO2 e/t-km) according to the "Well-to-Wheel" (WTW) measurement.
    {
      "type": "string",
      "gross_vehicle_weight": "string",
      "emission_intensity": {
        "CO2": "number",
        "unit": "string"
      }
    }
  ]
}

Conector Tractus-X EDC

Para obtener la documentación de cada parámetro EDC de Tractus-X, consulte el archivo de valores original.

La siguiente tabla muestra todos los servicios, junto con sus correspondientes puertos y puntos finales expuestos como referencia.

Nombre del servicio	Puerto y ruta
Plano de control	● administración: ‒ Puerto: 8081 Ruta: /management ● control ‒ Puerto: 8083 Ruta: /control ● Puerto de protocolo: 8084 Ruta: /api/v1/dsp ● métricas ‒ Puerto: 9090 Ruta: /metrics ● observabilidad ‒ Puerto: 8085 Ruta: /observability
Plano de datos	predeterminado ‒ Puerto: 8080 Ruta: /api público ‒ Puerto: 8081 Ruta: /api/dataplane/control proxy ‒ Puerto: 8186 Ruta: /proxy métricas ‒ Puerto: 9090 Ruta: /metrics observabilidad ‒ Puerto: 8085 Ruta: /observability
Almacén	Puerto: 8200
PostgreSQL	Puerto: 5432

Uso AWS Secrets Manager del administrador

Es posible usar Secrets Manager en lugar de HashiCorp Vault como administrador de secretos. Para hacerlo, debe usar o compilar la extensión AWS Secrets Manager EDC.

Serás responsable de crear y mantener tu propia imagen, ya que Tractus-X no ofrece soporte para Secrets Manager.

Para ello, tendrás que modificar los archivos de compilación de Gradle tanto del plano de control como del plano de datos del conector introduciendo la extensión AWS Secrets Manager EDC (consulta este magnífico artefacto para ver un ejemplo) y, a continuación, crear, mantener y hacer referencia a la imagen de Docker.

Para obtener más información sobre la refactorización de la imagen Docker del conector Tractus-X, consulte los gráficos Refactorizar Tractus-X EDC Helm.

Por motivos de simplicidad, evitamos volver a crear la imagen del conector siguiendo este patrón y utilizamos Vault. HashiCorp