Configurez un espace de données minimum viable pour partager les données entre les organisations

Créé par Ramy Hcini (Think-it), Ismail Abdellaoui (Think-it), Malte Gasseling (Think-it), Jorge Hernandez Suarez (AWS) et Michael Miller (AWS)

Environnement : PoC ou pilote	Technologies : analyse ; conteneurs et microservices ; lacs de données ; bases de données ; infrastructure	Charge de travail : Open source
Services AWS : Amazon Aurora ; AWS Certificate Manager (ACM) ; AWS ; Amazon CloudFormation EC2 ; Amazon EFS ; Amazon EKS ; Elastic Load Balancing (ELB) ; Amazon RDS ; Amazon S3 ; AWS Systems Manager

Récapitulatif

Les espaces de données sont des réseaux fédérés pour l'échange de données, la confiance et le contrôle des données étant des principes fondamentaux. Ils permettent aux entreprises de partager, d'échanger et de collaborer sur des données à grande échelle en proposant une solution rentable et indépendante de la technologie.

Les espaces de données ont le potentiel de stimuler de manière significative les efforts en faveur d'un futur durable en utilisant la résolution de problèmes basée sur les données avec une end-to-end approche impliquant toutes les parties prenantes concernées.

Ce modèle vous montre comment deux entreprises peuvent utiliser la technologie de l'espace de données sur Amazon Web Services (AWS) pour faire avancer leur stratégie de réduction des émissions de carbone. Dans ce scénario, l'entreprise X fournit des données sur les émissions de carbone, que l'entreprise Y consomme. Consultez la section Informations supplémentaires pour obtenir les détails suivants sur les spécifications de l'espace de données :

• Les participants

• Affaire de rentabilisation

• Autorité de l'espace de données

• Composants de l'espace de données

• Services d'espace de données

• Données à échanger

• Modèle de données

• Connecteur Tractus-X EDC

Le modèle inclut les étapes suivantes :

• Déploiement de l'infrastructure nécessaire à un espace de données de base avec deux participants AWS.

• Échange de données sur l'intensité des émissions de carbone en utilisant les connecteurs de manière sécurisée.

Ce modèle déploie un cluster Kubernetes qui hébergera les connecteurs d'espace de données et leurs services via Amazon Elastic Kubernetes Service (Amazon EKS).

Le plan de contrôle et le plan de données Eclipse Dataspace Components (EDC) sont tous deux déployés sur Amazon EKS. Le graphique officiel de Tractus-X Helm déploie les services PostgreSQL et Vault en tant que dépendances HashiCorp .

En outre, le service d'identité est déployé sur Amazon Elastic Compute Cloud (Amazon EC2) afin de reproduire un scénario réel d'espace de données minimum viable (MVDS).

Conditions préalables et limitations

Prérequis

• Un actif Compte AWS pour déployer l'infrastructure de votre choix Région AWS

• Un utilisateur AWS Identity and Access Management (IAM) ayant accès à Amazon S3 qui sera utilisé temporairement en tant qu'utilisateur technique (le connecteur EDC ne prend actuellement pas en charge l'utilisation de rôles). Nous vous recommandons de créer un utilisateur IAM spécifiquement pour cette démo et de lui attribuer des autorisations limitées.)

• AWS Command Line Interface (AWS CLI) installé et configuré dans la configuration de votre choix Région AWS

• AWS informations d'identification de sécurité

• eksctl sur votre poste de travail

• Git sur votre poste de travail

• kubectl

• Casque

• facteur

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

• Un nom DNS qui pointera vers un Application Load Balancer (le nom DNS doit être couvert par le certificat ACM)

• HashiCorp Vault (pour plus d'informations sur l'utilisation AWS Secrets Manager pour gérer les secrets, consultez la section Informations supplémentaires.)

Versions du produit

• AWS CLI version 2+

• Collection Postman v2.1

Limites

• Sélection du connecteur ‒ Ce déploiement utilise un connecteur basé sur EDC. Assurez-vous toutefois de prendre en compte les points forts et les fonctionnalités des connecteurs EDC et FIWARE True pour prendre une décision éclairée qui correspond aux besoins spécifiques du déploiement.

• Conception du connecteur EDC ‒ La solution de déploiement choisie repose sur le tableau de bord du connecteur EDC de Tractus-X, une option de déploiement bien établie et largement testée. La décision d'utiliser ce tableau est motivée par son utilisation courante et par l'inclusion d'extensions essentielles dans la version fournie. Bien que PostgreSQL HashiCorp et Vault soient des composants par défaut, vous avez la possibilité de personnaliser votre propre version de connecteur si nécessaire.

• Accès au cluster privé ‒ L'accès au cluster EKS déployé est limité aux canaux privés. L'interaction avec le cluster s'effectue exclusivement à l'aide kubectl d'un IAM. L'accès public aux ressources du cluster peut être activé à l'aide d'équilibreurs de charge et de noms de domaine, qui doivent être mis en œuvre de manière sélective pour exposer des services spécifiques à un réseau plus large. Cependant, nous ne recommandons pas de fournir un accès public.

• Concentration sur la sécurité ‒ L'accent est mis sur l'abstraction des configurations de sécurité par rapport aux spécifications par défaut afin que vous puissiez vous concentrer sur les étapes de l'échange de données du connecteur EDC. Bien que les paramètres de sécurité par défaut soient conservés, il est impératif d'activer les communications sécurisées avant d'exposer le cluster au réseau public. Cette précaution garantit une base solide pour un traitement sécurisé des données.

• Coût de l'infrastructure ‒ Une estimation du coût de l'infrastructure peut être obtenue à l'aide du AWS Pricing Calculator. Un simple calcul montre que les coûts peuvent atteindre 162,92 USD par mois pour l'infrastructure déployée.

Architecture

L'architecture MVDS comprend deux clouds privés virtuels (VPC), l'un pour le service d'identité DAPS (Dynamic Attribute Provisioning System) et l'autre pour Amazon EKS.

Architecture DAPS

Le schéma suivant montre le DAPS exécuté sur des instances EC2 contrôlées par un groupe Auto Scaling. Un Application Load Balancer et une table de routage exposent les serveurs DAPS. Amazon Elastic File System (Amazon EFS) synchronise les données entre les instances DAPS.

Architecture d'Amazon EKS

Les espaces de données sont conçus pour être des solutions indépendantes de la technologie, et plusieurs implémentations existent. Ce modèle utilise un cluster Amazon EKS pour déployer les composants techniques de l'espace de données. Le schéma suivant montre le déploiement du cluster EKS. Les nœuds de travail sont installés dans des sous-réseaux privés. Les pods Kubernetes accèdent à l'instance Amazon Relational Database Service (Amazon RDS) pour PostgreSQL qui se trouve également dans les sous-réseaux privés. Les pods Kubernetes stockent les données partagées dans Amazon S3.

Outils

AWS services

• AWS CloudFormationvous aide à configurer les AWS ressources, à les approvisionner rapidement et de manière cohérente, et à les gérer tout au long de leur cycle de vie dans toutes Comptes AWS les régions.

• Amazon Elastic Compute Cloud (Amazon EC2) offre une capacité de calcul évolutive dans l' AWS Cloud. Vous pouvez lancer autant de serveurs virtuels que vous le souhaitez et les augmenter ou les diminuer rapidement.

• Amazon Elastic File System (Amazon EFS) vous aide à créer et à configurer des systèmes de fichiers partagés dans le AWS Cloud.

• Amazon Elastic Kubernetes Service (Amazon EKS) vous permet d'exécuter AWS Kubernetes sans avoir à installer ou à gérer votre propre plan de contrôle ou vos propres nœuds Kubernetes.

• Amazon Simple Storage Service (Amazon S3) est un service de stockage d'objets basé sur le cloud qui vous permet de stocker, de protéger et de récupérer n'importe quel volume de données.

• Elastic Load Balancing (ELB) répartit le trafic applicatif ou réseau entrant sur plusieurs cibles. Par exemple, vous pouvez répartir le trafic entre les instances EC2, les conteneurs et les adresses IP dans une ou plusieurs zones de disponibilité.

Autres outils

• eksctl est un utilitaire de ligne de commande permettant de créer et de gérer des clusters Kubernetes sur Amazon EKS.

• Git est un système de contrôle de version distribué et open source.

• HashiCorp Vault fournit un stockage sécurisé avec un accès contrôlé aux informations d'identification et autres informations sensibles.

• Helm est un gestionnaire de packages open source pour Kubernetes qui vous aide à installer et à gérer des applications sur votre cluster Kubernetes.

• kubectl est une interface de ligne de commande qui vous permet d'exécuter des commandes sur des clusters Kubernetes.

• Postman est une plateforme d'API.

Référentiel de code

Les fichiers YAML de configuration Kubernetes et les scripts Python pour ce modèle sont disponibles dans le référentiel aws-patterns-edc. GitHub Le modèle utilise également le référentiel Tractus-X EDC.

Bonnes pratiques

Amazon EKS et isolation des infrastructures des participants

Dans Kubernetes, les espaces de noms sépareront l'infrastructure du fournisseur X de l'infrastructure du consommateur de l'entreprise Y selon ce schéma. Pour plus d'informations, consultez les guides des meilleures pratiques d'EKS.

Dans une situation plus réaliste, chaque participant disposerait d'un cluster Kubernetes distinct fonctionnant au sein de son propre cluster. Compte AWS L'infrastructure partagée (DAPS dans ce modèle) serait accessible aux participants à l'espace de données tout en étant complètement séparée des infrastructures des participants.

Épopées

Configuration de l'environnement et mise en service d'un cluster EKS et d'instances EC2

Tâche	Description	Compétences requises
Pour cloner le référentiel.	Pour cloner le référentiel sur votre poste de travail, exécutez la commande suivante : git clone https://github.com/Think-iT-Labs/aws-patterns-edc Le poste de travail doit avoir accès à votre Compte AWS.	DevOps ingénieur
Provisionnez le cluster Kubernetes et configurez des espaces de noms.	Pour déployer un cluster EKS simplifié par défaut dans votre compte, exécutez la eksctl commande suivante sur le poste de travail sur lequel vous avez cloné le dépôt : eksctl create cluster La commande crée le VPC et les sous-réseaux privés et publics qui s'étendent sur trois zones de disponibilité différentes. Une fois la couche réseau créée, la commande crée deux instances m5.large EC2 au sein d'un groupe Auto Scaling. Pour plus d'informations et des exemples de sortie, consultez le guide eksctl. Après avoir provisionné le cluster privé, ajoutez le nouveau cluster EKS à votre configuration Kubernetes locale en exécutant la commande suivante : aws eks update-kubeconfig --name <EKS CLUSTER NAME> --region <AWS REGION> Ce modèle utilise le eu-west-1 Région AWS pour exécuter toutes les commandes. Cependant, vous pouvez exécuter les mêmes commandes dans vos préférences Région AWS. Pour vérifier que vos nœuds EKS fonctionnent et sont prêts, exécutez la commande suivante : kubectl get nodes	DevOps ingénieur
Configurez les espaces de noms.	Pour créer des espaces de noms pour le fournisseur et le consommateur, exécutez les commandes suivantes : kubectl create ns provider kubectl create ns consumer Dans ce modèle, il est important d'utiliser provider et d'utiliser consumer comme espaces de noms pour adapter les configurations aux étapes suivantes.	DevOps ingénieur

Déployer le service d'identité

Tâche	Description	Compétences requises
Déployez DAPS en utilisant AWS CloudFormation.	Pour faciliter la gestion des opérations DAPS, le serveur DAPS est installé sur les instances EC2. Pour installer DAPS, utilisez le AWS CloudFormation modèle. Vous aurez besoin du certificat ACM et du nom DNS indiqués dans la section Prérequis. Le modèle déploie et configure les éléments suivants : Application Load Balancer Groupe Auto Scaling Instances EC2 configurées avec les données utilisateur pour installer tous les packages nécessaires Rôles IAM DAPS Vous pouvez déployer le AWS CloudFormation modèle en vous connectant à la AWS CloudFormation console AWS Management Console et en utilisant celle-ci. Vous pouvez également déployer le modèle à l'aide d'une AWS CLI commande telle que la suivante : 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 C'est à vous de choisir le nom de l'environnement. Nous vous recommandons d'utiliser un terme significatif, tel queDapsInfrastructure, car il sera reflété dans les balises de AWS ressources. Pour ce modèle, t3.small il est suffisamment grand pour exécuter le flux de travail DAPS, qui comporte trois conteneurs Docker. Le modèle déploie les instances EC2 dans des sous-réseaux privés. Cela signifie que les instances ne sont pas directement accessibles via SSH (Secure Shell) depuis Internet. Les instances sont dotées du rôle IAM et de l' AWS Systems Manager agent nécessaires pour permettre l'accès aux instances en cours d'exécution via le gestionnaire de session, une fonctionnalité de. AWS Systems Manager Nous vous recommandons d'utiliser le gestionnaire de session pour y accéder. Vous pouvez également configurer un hôte bastion pour autoriser l'accès SSH depuis Internet. Lorsque vous utilisez l'approche de l'hôte bastion, l'exécution de l'instance EC2 peut prendre encore quelques minutes. Une fois le AWS CloudFormation modèle déployé avec succès, pointez le nom DNS sur le nom DNS de votre Application Load Balancer. Pour confirmer cela, exécutez la commande suivante : dig <DNS NAME> La sortie doit ressembler à ce qui suit : ; <<>> 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 ingénieur
Enregistrez les connecteurs des participants au service DAPS.	À partir de l'une des instances EC2 provisionnées pour le DAPS, enregistrez les participants : Exécutez le script disponible sur l'instance EC2 à l'aide de l'utilisateur root : cd /srv/mvds/omejdn-daps Enregistrez le fournisseur : bash scripts/register_connector.sh <provider_name> Enregistrez le consommateur : bash scripts/register_connector.sh <consumer_name> Le choix des noms n'a aucune incidence sur les prochaines étapes. Nous vous recommandons d'utiliser soit provider et consumer soit companyx etcompanyy. Les commandes d'enregistrement configureront également automatiquement le service DAPS avec les informations nécessaires extraites des certificats et des clés créés. Lorsque vous êtes connecté à un serveur DAPS, collectez les informations nécessaires pour les étapes ultérieures de l'installation : De omejdn-daps/config/clients.yml get the client id pour le fournisseur et le consommateur. Les client id valeurs sont de longues chaînes de chiffres hexadécimaux. Dans le omejdn-daps/keys répertoire, copiez le contenu des provider.key fichiers consumer.cert consumer.keyprovider.cert,, et. Nous vous recommandons de copier-coller le texte dans des fichiers portant le même nom et préfixés par le préfixe daps- sur votre poste de travail. Vous devez disposer des identifiants client du fournisseur et du consommateur et vous devez avoir quatre fichiers dans votre répertoire de travail sur votre poste de travail : Le nom du fichier source consumer.cert devient le nom du fichier du poste de travaildaps-consumer.cert. Le nom du fichier source consumer.key devient le nom du fichier du poste de travaildaps-consumer.key. Le nom du fichier source provider.cert devient le nom du fichier du poste de travaildaps-provider.cert. Le nom du fichier source provider.key devient le nom du fichier du poste de travaildaps-provider.key.	DevOps ingénieur

Déployez les connecteurs des participants

Tâche	Description	Compétences requises
Clonez le référentiel Tractus-X EDC et utilisez la version 0.4.1.	La version du connecteur Tractus-X EDC nécessite le déploiement et la disponibilité des services PostgreSQL (base de données des actifs) et HashiCorp Vault (gestion des secrets). Il existe de nombreuses versions des cartes Tractus-X EDC Helm. Ce modèle spécifie la version 0.4.1 car il utilise le serveur DAPS. Les dernières versions utilisent le Managed Identity Wallet (MIW) avec une implémentation distribuée du service d'identité. Sur le poste de travail où vous avez créé les deux espaces de noms Kubernetes, clonez le référentiel tractusx-edc et consultez la branche. release/0.4.1 git clone https://github.com/eclipse-tractusx/tractusx-edc cd tractusx-edc git checkout release/0.4.1	DevOps ingénieur
Configurez le graphique Tractus-X EDC Helm.	Modifiez la configuration du modèle de graphique Tractus-X Helm pour permettre aux deux connecteurs d'interagir ensemble. Pour ce faire, vous devez ajouter l'espace de noms au nom DNS du service afin qu'il puisse être résolu par les autres services du cluster. Ces modifications doivent être apportées au charts/tractusx-connector/templates/_helpers.tpl fichier. Ce modèle fournit une version finale modifiée de ce fichier que vous pouvez utiliser. Copiez-le et placez-le dans la daps section du fichiercharts/tractusx-connector/templates/_helpers.tpl. Assurez-vous de commenter toutes les dépendances DAPS dans 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 ingénieur
Configurez les connecteurs pour utiliser PostgreSQL sur Amazon RDS.	(Facultatif) L'instance Amazon Relational Database Service (Amazon RDS) n'est pas requise dans ce modèle. Cependant, nous vous recommandons vivement d'utiliser Amazon RDS ou Amazon Aurora, car ils fournissent des fonctionnalités telles que la haute disponibilité, la sauvegarde et la restauration. Pour remplacer PostgreSQL sur Kubernetes par Amazon RDS, procédez comme suit : Provisionnez l'instance Amazon RDS for PostgreSQL. DansChart.yaml, commentez la PostgreSQL section. Dans provider_values.yml etconsumer_values.yml, configurez la postgresql section comme suit : 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 ingénieur
Configurez et déployez le connecteur du fournisseur et ses services.	Pour configurer le connecteur du fournisseur et ses services, procédez comme suit : Pour télécharger le provider_edc.yaml fichier depuis le edc_helm_configs répertoire vers le dossier du graphique Helm actuel, exécutez la commande suivante : wget -q https://raw.githubusercontent.com/Think-iT-Labs/aws-patterns-edc/main/edc_helm_configs/provider_edc.yaml> -P charts/tractusx-connector/ Remplacez les variables suivantes (également marquées dans le fichier) par leurs valeurs : CLIENT_ID‒ L'identifiant généré par le DAPS. CLIENT_IDIl doit se trouver /srv/mvds/omejdn-daps/config/clients.yml/config/clients.yml sur le serveur DAPS. Il doit s'agir d'une chaîne de caractères hexadécimaux. DAPS_URL‒ URL du serveur DAPS. Il doit https://{DNS name} utiliser le nom DNS que vous avez défini lorsque vous avez exécuté le AWS CloudFormation modèle. VAULT_TOKEN‒ Le jeton à utiliser pour l'autorisation de Vault. Choisissez n'importe quelle valeur. vault.fullnameOverride ‒ vault-provider. vault.hashicorp.url ‒ http://vault-provider:8200/. Les valeurs précédentes supposent que le nom du déploiement et le nom de l'espace de noms sont le fournisseur. Pour exécuter le graphique Helm depuis votre poste de travail, utilisez les commandes suivantes : cd charts/tractusx-connector helm dependency build helm upgrade --install provider ./ -f provider_edc.yaml -n provider	DevOps ingénieur
Ajoutez le certificat et les clés dans le coffre du fournisseur.	Pour éviter toute confusion, produisez les certificats suivants en dehors du tractusx-edc/charts répertoire. Par exemple, exécutez la commande suivante pour accéder à votre répertoire de base : cd ~ Vous devez maintenant ajouter les secrets dont le fournisseur a besoin dans le coffre. Les noms des secrets contenus dans le coffre sont les valeurs des clés figurant dans la secretNames: section du provider_edc.yml fichier. Par défaut, ils sont configurés comme suit : 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 Une clé AES (Advanced Encryption Standard), une clé privée, une clé publique et un certificat autosigné sont initialement générés. Ils sont ensuite ajoutés en tant que secrets au coffre. De plus, ce répertoire doit contenir les daps-provider.key fichiers daps-provider.cert et que vous avez copiés depuis le serveur DAPS. Exécutez les commandes suivantes : # 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 Avant d'ajouter les secrets au coffre, convertissez-les de plusieurs lignes en lignes simples en remplaçant les sauts de ligne par \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 Pour formater les secrets qui seront ajoutés à Vault, exécutez les commandes suivantes : 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 Les secrets sont désormais au format JSON et sont prêts à être ajoutés au coffre. Pour obtenir le nom du module pour le coffre, exécutez la commande suivante : kubectl get pods -n provider|egrep "vault|NAME" Le nom du module sera similaire à"vault-provider-0". Ce nom est utilisé lors de la création d'un port de redirection vers le coffre. Le port forward vous permet d'accéder au coffre pour y ajouter le secret. Vous devez l'exécuter à partir d'un poste de travail sur lequel les informations d'identification AWS sont configurées. Pour accéder au coffre-fort, utilisez kubectl pour configurer un port de redirection : kubectl port-forward <VAULT_POD_NAME> 8200:8200 -n provider Vous devriez maintenant être en mesure d'accéder au coffre par le biais de votre navigateur ou de la CLI. Navigateur À l'aide du navigateur, accédez à http://127.0.0.1:8200, qui utilisera le port de redirection que vous avez configuré. Connectez-vous à l'aide du jeton que vous avez configuré précédemmentprovider_edc.yml. Dans le moteur de secrets, créez trois secrets. Chaque secret aura une Path for this secret valeur, qui est le nom du secret indiqué dans la liste suivante. Dans la secret data section, le nom de la clé sera content et la valeur sera la seule ligne de texte du fichier correspondant nommé.line. Les noms secrets proviennent de la secretNames section du provider_edc.yml fichier. Créez les secrets suivants : Secret transfer-proxy-token-signer-private-key avec nom de fichier provider-private-key.pem.line Secret transfer-proxy-token-signer-public-key avec nom de fichier provider-cert.pem.line Secret transfer-proxy-token-encryption-aes-key avec nom de fichier provider-aes.key.line Secret daps-private-key avec nom de fichier daps-provider.key.line Secret daps-public-key avec nom de fichier daps-provider.cert.line CLI Vault La CLI utilisera également le port forward que vous avez configuré. Sur votre poste de travail, installez la CLI Vault en suivant les instructions de la documentation de HashiCorp Vault. Pour vous connecter au coffre-fort à l'aide du jeton que vous avez configuréprovider_edc.yml, exécutez la commande suivante : vault login -address=http://127.0.0.1:8200 Avec le bon jeton, vous devriez voir le message "Success! You are now authenticated." Pour créer les secrets à l'aide des fichiers au format JSON que vous avez créés précédemment, exécutez le code suivant : 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 ingénieur
Configurez et déployez le connecteur grand public et ses services.	Les étapes de configuration et de déploiement du client sont similaires à celles que vous avez effectuées pour le fournisseur : Pour copier le consumer_edc.yaml depuis le dépôt aws-patterns-edc dans le dossier tractusx-edc/charts/tractusx-connecto r, exécutez les commandes suivantes : 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/ Mettez à jour les variables suivantes avec leurs valeurs réelles : CONSUMER_CLIENT_ID‒ L'identifiant généré par le DAPS. CONSUMER_CLIENT_IDIl doit se trouver config/clients.yml sur le serveur DAPS. DAPS_URL‒ La même URL DAPS que celle que vous avez utilisée pour le fournisseur. VAULT_TOKEN‒ Le jeton à utiliser pour l'autorisation de Vault. Choisissez n'importe quelle valeur. vault.fullnameOverride ‒ vault-consumer vault.hashicorp.url ‒ http://vault-provider:8200/ Les valeurs précédentes supposent que le nom du déploiement et le nom de l'espace de noms sontconsumer. Pour exécuter le graphique Helm, utilisez les commandes suivantes : cd charts/tractusx-connector helm upgrade --install consumer ./ -f consumer_edc.yaml -n consumer
Ajoutez le certificat et les clés au coffre-fort du consommateur.	Du point de vue de la sécurité, nous recommandons de régénérer les certificats et les clés pour chaque participant à l'espace de données. Ce modèle régénère les certificats et les clés pour le consommateur. Les étapes sont très similaires à celles du fournisseur. Vous pouvez vérifier les noms secrets contenus dans le consumer_edc.yml fichier. Les noms des secrets contenus dans le coffre sont les valeurs des clés figurant dans la secretNames: section duconsumer_edc.yml file. Par défaut, ils sont configurés comme suit : 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 Les daps-consumer.key fichiers daps-consumer.cert et que vous avez copiés depuis le serveur DAPS devraient déjà exister dans ce répertoire. Exécutez les commandes suivantes : # 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 Modifiez les fichiers manuellement pour remplacer les sauts de ligne par\n, ou utilisez trois commandes similaires aux suivantes : 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 Pour formater les secrets qui seront ajoutés à Vault, exécutez les commandes suivantes : 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 Les secrets sont désormais au format JSON et sont prêts à être ajoutés au coffre. Pour obtenir le nom du module pour le coffre du consommateur, exécutez la commande suivante : kubectl get pods -n consumer | egrep "vault|NAME" Le nom du module sera similaire à"vault-consumer-0". Ce nom est utilisé lors de la création d'un port de redirection vers le coffre. Le port forward vous permet d'accéder au coffre pour y ajouter le secret. Vous devez l'exécuter à partir d'un poste de travail dont les AWS informations d'identification sont configurées. Pour accéder au coffre-fort, utilisez kubectl pour configurer un port de redirection : kubectl port-forward <VAULT_POD_NAME> 8201:8200 -n consumer Le port local est cette fois le 8201, ce qui vous permet de mettre en place des redirections pour le producteur et le consommateur. Navigateur Vous pouvez utiliser votre navigateur pour vous connecter à http://localhost:8201/ afin d'accéder au coffre du consommateur et de créer les secrets avec les noms et le contenu tels que décrits. Les secrets et les fichiers contenant le contenu sont les suivants : Secret transfer-proxy-token-signer-private-key avec nom de fichier consumer-private-key.pem.line Secret transfer-proxy-token-signer-public-key avec nom de fichier consumer-cert.pem.line Secret transfer-proxy-token-encryption-aes-key avec nom de fichier consumer-aes.key.line CLI Vault À l'aide de la CLI de Vault, vous pouvez exécuter les commandes suivantes pour vous connecter au coffre-fort et créer les secrets : Connectez-vous au coffre-fort en utilisant le jeton que vous avez configuré dans consumer_edc.yml : vault login -address=http://127.0.0.1:8201 Avec le bon jeton, vous devriez voir le message "Success! You are now authenticated." Pour créer les secrets à l'aide des fichiers au format JSON que vous avez créés précédemment, exécutez le code suivant : 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 ingénieur

Configurer un client HTTP pour interagir avec l'API de gestion des connecteurs

Tâche	Description	Compétences requises
Configurez la redirection de port.	Pour vérifier l'état des pods, exécutez les commandes suivantes : kubectl get pods -n provider kubectl get pods -n consumer Pour vous assurer que les déploiements de Kubernetes ont réussi, consultez les journaux des pods Kubernetes du fournisseur et du consommateur en exécutant les commandes suivantes : kubectl logs -n provider <producer control plane pod name> kubectl logs -n consumer <consumer control plane pod name> Le cluster est privé et n'est pas accessible au public. Pour interagir avec les connecteurs, utilisez la fonction de transfert de port Kubernetes pour transférer le trafic généré par votre machine vers le plan de contrôle des connecteurs. Sur le premier terminal, transmettez les demandes du consommateur à l'API de gestion via le port 8300 : kubectl port-forward deployment/consumer-tractusx-connector-controlplane 8300:8081 -n consumer Sur le deuxième terminal, transmettez les demandes du fournisseur à l'API de gestion via le port 8400 : kubectl port-forward deployment/provider-tractusx-connector-controlplane 8400:8081 -n provider	DevOps ingénieur
Créez des compartiments S3 pour le fournisseur et le consommateur.	Le connecteur EDC n'utilise actuellement pas d'informations d'identification AWS temporaires, telles que celles fournies en assumant un rôle. L'EDC ne prend en charge que l'utilisation d'une combinaison de clé d'accès IAM et de clé d'accès secrète. Deux compartiments S3 sont nécessaires pour les étapes ultérieures. Un compartiment S3 est utilisé pour stocker les données mises à disposition par le fournisseur. L'autre compartiment S3 est destiné aux données reçues par le consommateur. L'utilisateur IAM doit être autorisé à lire et à écrire des objets uniquement dans les deux compartiments nommés. Une paire d'identifiant de clé d'accès et de clé d'accès secrète doit être créée et conservée en toute sécurité. Après la mise hors service de ce MVDS, l'utilisateur IAM doit être supprimé. Le code suivant est un exemple de politique IAM pour l'utilisateur : { "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 ingénieur
Configurez Postman pour qu'il interagisse avec le connecteur.	Vous pouvez désormais interagir avec les connecteurs via votre instance EC2. Utilisez Postman comme client HTTP et fournissez des collections Postman pour les connecteurs fournisseur et consommateur. Importez les collections du aws-pattern-edc référentiel dans votre instance Postman. Ce modèle utilise les variables de collection Postman pour fournir des informations à vos demandes.	Développeur d'applications, ingénieur de données

Fournissez les données d'empreinte carbone de l'entreprise X via le connecteur

Tâche	Description	Compétences requises
Préparez les données sur l'intensité des émissions de carbone à partager.	Vous devez d'abord choisir la ressource de données à partager. Les données de l'entreprise X représentent l'empreinte carbone de son parc de véhicules. Le poids est le poids brut du véhicule (PTC) en tonnes, et les émissions sont exprimées en grammes de CO2 par tonne-kilomètre (g de CO2 e/t-km) selon la mesure Wheel-to-Well (WTW) : Type de véhicule : fourgonnette ; poids : < 3,5 ; émissions : 800 Type de véhicule : camion urbain ; poids : 3,5 à 7,5 ; émissions : 315 Type de véhicule : véhicule utilitaire moyen (MGV) ; poids : 7,5 à 20 ; émissions : 195 Type de véhicule : poids lourd (poids lourd) ; poids : > 20 ; émissions : 115 Les données d'exemple se trouvent dans le carbon_emissions_data.json fichier du aws-patterns-edc référentiel. L'entreprise X utilise Amazon S3 pour stocker des objets. Créez le compartiment S3 et stockez-y l'exemple d'objet de données. Les commandes suivantes créent un compartiment S3 avec des paramètres de sécurité par défaut. Nous vous recommandons vivement de consulter les meilleures pratiques de sécurité pour 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> Le nom du compartiment S3 doit être unique au monde. Pour plus d'informations sur les règles de dénomination, consultez la documentation AWS.	Ingénieur de données, développeur d'applications
Enregistrez la ressource de données sur le connecteur du fournisseur à l'aide de Postman.	Une ressource de données du connecteur EDC contient le nom des données et leur emplacement. Dans ce cas, la ressource de données du connecteur EDC pointera vers l'objet créé dans le compartiment S3 : Connecteur : Provider Demande : créer un actif Variables de collection : mise à jourASSET_NAME. Choisissez un nom significatif qui représente l'actif. Corps de la demande : mettez à jour le corps de la demande avec le compartiment S3 que vous avez créé pour le fournisseur. "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>" } Réponse : Une demande réussie renvoie l'heure de création et l'ID de l'actif nouvellement créé. { "@id": "c89aa31c-ec4c-44ed-9e8c-1647f19d7583" } Variable de collection ASSET_ID : mettez à jour la variable de collection Postman ASSET_ID avec l'ID généré automatiquement par le connecteur EDC après sa création.	Développeur d'applications, ingénieur de données
Définissez la politique d'utilisation de l'actif.	Un actif de données EDC doit être associé à des politiques d'utilisation claires. Créez d'abord la définition de la politique dans le connecteur du fournisseur. La politique de l'entreprise X est de permettre aux participants de l'espace de données d'utiliser les données d'empreinte carbone. Organisme de la demande : Connecteur : Provider Demande : créer une politique Variables de collection : mettez à jour la Policy Name variable avec le nom de la politique. Réponse : Une demande réussie renvoie l'heure de création et l'ID de politique de la nouvelle politique. Mettez à jour la variable de collection POLICY_ID avec l'ID de la politique générée par le connecteur EDC après sa création.	Développeur d'applications, ingénieur de données
Définissez une offre de contrat EDC pour l'actif et sa politique d'utilisation.	Pour permettre aux autres participants de demander l'accès à vos données, proposez-les dans le cadre d'un contrat qui précise les conditions d'utilisation et les autorisations : Connecteur : Provider Demande : Création d'une définition de contrat Variables de collection : mettez à jour la Contract Name variable avec un nom pour l'offre ou la définition du contrat.	Développeur d'applications, ingénieur de données

Découvrez les actifs et parvenez à un accord sur les contrats définis

Tâche	Description	Compétences requises
Demandez le catalogue de données partagé par l'entreprise X.	En tant que consommateur de données dans le domaine des données, l'entreprise Y doit d'abord découvrir les données partagées par les autres participants. Dans cette configuration de base, vous pouvez le faire en demandant au connecteur consommateur de demander le catalogue des actifs disponibles directement au connecteur fournisseur. Connecteur : Consumer Demande : Demande de catalogue Réponse : Toutes les ressources de données disponibles auprès du fournisseur, ainsi que leurs politiques d'utilisation associées. En tant que consommateur de données, recherchez le contrat qui vous intéresse et mettez à jour les variables de collecte suivantes en conséquence. CONTRACT_OFFER_ID‒ L'identifiant de l'offre contractuelle que le consommateur souhaite négocier ASSET_ID‒ L'identifiant de l'actif que le consommateur souhaite négocier PROVIDER_CLIENT_ID‒ L'ID du connecteur du fournisseur avec lequel négocier	Développeur d'applications, ingénieur de données
Lancer une négociation contractuelle pour les données sur l'intensité des émissions de carbone de l'entreprise X.	Maintenant que vous avez identifié l'actif que vous souhaitez consommer, lancez un processus de négociation de contrat entre les connecteurs consommateur et fournisseur. Connecteur : Consumer Demande : Négociation de contrat Variables de collection : mettez à jour la CONSUMER_CLIENT_ID variable avec l'ID du connecteur consommateur avec lequel négocier. Le processus peut prendre un certain temps avant d'atteindre l'état VÉRIFIÉ. Vous pouvez vérifier l'état de la négociation du contrat et l'ID de contrat correspondant en utilisant la Get Negotiation demande.	Développeur d'applications, ingénieur de données

Consommez les données en utilisant le contrat

Tâche	Description	Compétences requises
Consommez les données des points de terminaison HTTP.	(Option 1) Pour utiliser le plan de données HTTP afin de consommer les données de l'espace de données, vous pouvez utiliser webhook.site pour émuler un serveur HTTP et lancer le processus de transfert dans le connecteur consommateur : Connecteur : Consumer Demande : Négociation de contrat Variables de collection : mettez à jour la Contract Agreement ID variable avec l'ID de l'accord contractuel généré par le connecteur EDC. Corps de la demande : mettez à jour le corps de la demande pour HTTP le spécifier à dataDestination côté de l'URL du webhook : { "dataDestination": { "type": "HttpProxy" }, "privateProperties": { "receiverHttpEndpoint": "<WEBHOOK URL>" } } Le connecteur enverra les informations nécessaires pour télécharger le fichier directement sur l'URL du webhook. La charge utile reçue est similaire à ce qui suit : { "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" } } Utilisez les informations d'identification reçues pour obtenir la ressource S3 partagée par le fournisseur. Dans cette dernière étape, vous devez envoyer la demande au plan de données du consommateur (ports de transfert correctement), comme indiqué dans la charge utile (endpoint).	Développeur d'applications, ingénieur de données
Consommez directement les données des compartiments S3.	(Option 2) Utilisez l'intégration Amazon S3 avec le connecteur EDC et pointez directement vers le compartiment S3 de l'infrastructure grand public comme destination : Corps de la demande : mettez à jour le corps de la demande pour spécifier le compartiment S3 en tant que DataDestination. Il doit s'agir du compartiment S3 que vous avez créé précédemment pour stocker les données reçues par le consommateur. { "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 }}" } } }	Ingénieur de données, développeur d'applications

Résolution des problèmes

Problème	Solution
Le connecteur peut soulever un problème concernant le format PEM du certificat.	Concaténez le contenu de chaque fichier sur une seule ligne en ajoutant. \n

Ressources connexes

• DSSC

• Création d'espaces de données pour les cas d'utilisation liés au développement durable (stratégie AWS Prescriptive Guidance de Think-it)

• AWS pour les espaces de données

• Documentation Tractus-X

• DAPS

• Permettre le partage de données via les espaces de données et AWS (article de blog)

Informations supplémentaires

Spécifications de l'espace de données

Les participants

Participant	Description de l'entreprise	Objectif de l'entreprise
Entreprise X	Exploite une flotte de véhicules en Europe et en Amérique du Sud pour transporter diverses marchandises.	Vise à prendre des décisions basées sur les données afin de réduire l'intensité de son empreinte carbone.
Entreprise Y	Une autorité de régulation environnementale	Applique les réglementations et politiques environnementales conçues pour surveiller et atténuer l'impact environnemental des entreprises et des industries, y compris l'intensité des émissions de carbone.

Affaire de rentabilisation

L'entreprise X utilise la technologie de l'espace de données pour partager les données d'empreinte carbone avec un auditeur de conformité, la société Y, afin d'évaluer et de traiter l'impact environnemental des opérations logistiques de l'entreprise X.

Autorité de l'espace de données

L'autorité de l'espace de données est un consortium des organisations qui régissent l'espace de données. Dans ce modèle, les entreprises X et Y forment l'organe de gouvernance et représentent une autorité fédérée en matière d'espace de données.

Composants de l'espace de données

Composant	Implémentation choisie	Informations supplémentaires
Protocole d'échange de jeux de données	Protocole Dataspace version 0.8	JSON-LD Vocabulaire du catalogue de données (DCAT)
Connecteur d'espace de données	Connecteur Tractus-X EDC version 0.4.1	Extensions EDC
Politiques d'échange de données	Politique d'utilisation par défaut	Langage ouvert des droits numériques (ODRL)

Services d'espace de données

Service	Mise en œuvre	Informations supplémentaires
Service d'identité	Système de provisionnement dynamique des attributs (DAPS)	« Un système de provisionnement dynamique des attributs (DAPS) a pour but de vérifier certains attributs des organisations et des connecteurs. Les tiers n'ont donc pas besoin de faire confiance à ces derniers à condition qu'ils fassent confiance aux assertions du DAPS. » — ROBINETS Pour se concentrer sur la logique du connecteur, l'espace de données est déployé sur une machine Amazon EC2 à l'aide de Docker Compose.
Le service de découverte	Catalogue fédéré Gaia-X	« Le catalogue fédéré constitue un référentiel indexé des auto-descriptions de Gaia-X afin de permettre la découverte et la sélection des fournisseurs et de leurs offres de services. Les auto-descriptions sont les informations fournies par les participants sur eux-mêmes et sur leurs services sous forme de propriétés et de réclamations. » — Kickstarter de l'écosystème Gaia-X

Données à échanger

Actifs de données	Description	Format
Données sur les émissions de carbone	Valeurs d'intensité pour différents types de véhicules dans la région spécifiée (Europe et Amérique du Sud) pour l'ensemble du parc de véhicules	Fichier JSON

Modèle de données

{
  "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"
      }
    }
  ]
}

Connecteur Tractus-X EDC

Pour la documentation de chaque paramètre EDC de Tractus-X, consultez le fichier de valeurs d'origine.

Le tableau suivant répertorie tous les services, ainsi que leurs ports exposés et points de terminaison correspondants à titre de référence.

Nom du service	Port et chemin
Plan de contrôle	● Gestion : ‒ Port : 8081 Chemin : /management ● contrôle ‒ Port : 8083 Trajet : /control ● Port du protocole : 8084 Chemin : /api/v1/dsp ● métriques ‒ Port : 9090 Trajet : /metrics ● observabilité ‒ Port : 8085 Trajet : /observability
Plan de données	par défaut ‒ Port : 8080 Chemin : /api public ‒ Port : 8081 Trajet : /api/dataplane/control proxy ‒ Port : 8186 Chemin : /proxy métriques ‒ Port : 9090 Trajet : /metrics observabilité ‒ Port : 8085 Trajet : /observability
Coffre-fort	Hafen : 8200
PostgreSQL	Hafen : 5432

Utilisation AWS Secrets Manager du gestionnaire

Il est possible d'utiliser Secrets Manager au lieu de HashiCorp Vault comme gestionnaire de secrets. Pour ce faire, vous devez utiliser ou créer l'extension AWS Secrets Manager EDC.

Vous serez responsable de la création et de la maintenance de votre propre image, car Tractus-X ne fournit pas de support pour Secrets Manager.

Pour ce faire, vous devez modifier les fichiers Gradle de génération du plan de contrôle et du plan de données du connecteur en introduisant votre extension AWS Secrets Manager EDC (voir cet artefact maven par exemple), puis créer, maintenir et référencer l'image Docker.

Pour plus d'informations sur la refactorisation de l'image Docker du connecteur Tractus-X, consultez les diagrammes Refactor Tractus-X EDC Helm.

Pour des raisons de simplicité, nous évitons de reconstruire l'image du connecteur selon ce modèle et utilisons HashiCorp Vault.