組織間でデータを共有するための最小限の実行可能なデータスペースを設定する

作成者: Ramy Hcini (Think-it)、Ismail Abdellaoui (Think-it)、Malte Gasseling (Think-it)、Jorge Hernandez Suarez (AWS)、Michael Miller (AWS)

環境：PoC またはパイロット	テクノロジー: 分析、コンテナとマイクロサービス、データレイク、データベース、インフラストラクチャ	ワークロード：オープンソース
AWS サービス: Amazon Aurora、AWS Certificate Manager (ACM)、AWS CloudFormation、Amazon EC2、Amazon EFSAmazon EKS、Elastic Load Balancing (ELB)、Amazon RDS、Amazon S3、AWS Systems Manager

[概要]

データスペースは、データ交換のためのフェデレーティッドネットワークであり、データの信頼と制御を中核となる原則としています。これにより、組織は費用対効果が高く、テクノロジーに依存しないソリューションを提供することで、大規模なデータの共有、交換、共同作業を行うことができます。

データスペースは、関連するすべての利害関係者が関与する end-to-end アプローチでデータ駆動型の問題解決を使用することで、持続可能な未来に向けた取り組みを大幅に推進できる可能性があります。

このパターンは、2 つの企業が Amazon Web Services (AWS) のデータスペーステクノロジーを使用して炭素排出量削減戦略を推し進める方法の例を示しています。このシナリオでは、X 社が炭素排出量データを提供し、Y 社が消費します。以下のデータスペース仕様の詳細については、「追加情報」セクションを参照してください。

• 参加者

• ビジネスケース

• データスペース権限

• データスペースコンポーネント

• データスペースサービス

• 交換するデータ

• データモデル

• Trac-X コネクタ

このパターンには、以下のステップが含まれます。

• で実行されている 2 人の参加者を含む基本的なデータスペースに必要なインフラストラクチャをデプロイします AWS。

• コネクタを安全な方法で使用して、炭素排出量と強度のデータを交換します。

このパターンは、Amazon Elastic Kubernetes Service (Amazon EKS) を介してデータスペースコネクタとそのサービスをホストする Kubernetes クラスターをデプロイします。

Eclipse Dataspace コンポーネント () コントロールプレーンとデータプレーンはどちらも Amazon EKS にデプロイされます。公式の Trac-X Helm チャートでは、PostgreSQL サービスと HashiCorp Vault サービスを依存関係としてデプロイします。

さらに、ID サービスは Amazon Elastic Compute Cloud (Amazon EC2) にデプロイされ、実用最小限のデータスペース (MVDS) の実際のシナリオをレプリケートします。

前提条件と制限

前提条件

• 選択した AWS アカウント にインフラストラクチャをデプロイするアクティブな AWS リージョン

• 技術ユーザーとして一時的に使用される Amazon S3 へのアクセス権を持つ AWS Identity and Access Management (IAM) ユーザー (現在、 コネクタはロールの使用をサポートしていません。 このデモ専用の IAM ユーザーを 1 人作成し、このユーザーには限定されたアクセス許可が関連付けられることをお勧めします）。

• 選択した に AWS Command Line Interface （AWS CLI） がインストールされ、設定されている AWS リージョン

• AWS セキュリティ認証情報

• ワークステーションの eksctl

• ワークステーションの Git

• kubectl

• Helm

• ポストマン

• AWS Certificate Manager (ACM) SSL/TLS 証明書

• Application Load Balancer を指す DNS 名 (DNS 名は ACM 証明書でカバーされている必要があります）

• HashiCorp ボールト ( AWS Secrets Manager を使用してシークレットを管理する方法については、「追加情報」セクションを参照してください）。

製品バージョン

• AWS CLI バージョン 2 以降

• Postman Collection v2.1

制約事項

• コネクタの選択 ‒ このデプロイでは、 ベースのコネクタを使用します。ただし、デプロイの特定のニーズに合った情報に基づいた決定を行うために、必ず https://github.com/eclipse-edc/Connector/ コネクタと FIWARE True コネクタの両方の長所と機能を考慮してください。

• 「コネクタ構築」 — 選択したデプロイソリューションは、十分に確立され、広範囲にテストされたデプロイオプションである Trac-X Connector Helm チャートに依存しています。このグラフを使用するかどうかの決定は、一般的な使用法と、提供されたビルドに不可欠な拡張機能を含めることによって決まります。PostgreSQL と HashiCorp Vault はデフォルトのコンポーネントですが、必要に応じて独自のコネクタ構築をカスタマイズできます。

• プライベートクラスターアクセス ‒ デプロイされた EKS クラスターへのアクセスはプライベートチャネルに制限されます。クラスターとのやり取りは、 kubectlおよび IAM の使用によってのみ実行されます。クラスターリソースへのパブリックアクセスは、ロードバランサーとドメイン名を使用して有効にできます。ロードバランサーとドメイン名は、特定のサービスをより広範なネットワークに公開するために選択的に実装する必要があります。ただし、パブリックアクセスを提供することはお勧めしません。

• セキュリティの焦点 ‒ セキュリティ設定をデフォルトの仕様に抽象化することに重点を置いているため、 コネクタのデータ交換に関連するステップに集中できます。デフォルトのセキュリティ設定は維持されますが、クラスターをパブリックネットワークに公開する前に、安全な通信を有効にすることが不可欠です。この予防策により、安全なデータ処理のための強固な基盤が確保されます。

• インフラストラクチャコスト ‒ インフラストラクチャのコストの見積もりは、 を使用して確認できますAWS Pricing Calculator。単純な計算では、デプロイされたインフラストラクチャのコストは 1 か月あたり最大 162.92 USD になる可能性があります。

アーキテクチャ

MVDS アーキテクチャは 2 つの仮想プライベートクラウド (VPCsで構成されます。1 つは動的属性プロビジョニングシステム (DAPS) ID サービス用、もう 1 つは Amazon EKS 用です。

DAPS アーキテクチャ

次の図は、Auto Scaling グループによって制御される EC2 インスタンスで実行されている DAPS を示しています。Application Load Balancer とルートテーブルは DAPS サーバーを公開します。Amazon Elastic File System (Amazon EFS ) は、DAPS インスタンス間でデータを同期します。

Amazon EKS アーキテクチャ

データスペースはテクノロジーに依存しないソリューションとして設計されており、複数の実装があります。このパターンでは、Amazon EKS クラスターを使用してデータスペースの技術コンポーネントをデプロイします。次の図は、EKS クラスターのデプロイを示しています。ワーカーノードはプライベートサブネットにインストールされます。Kubernetes ポッドは、プライベートサブネットにも存在する Amazon Relational Database Service (Amazon RDS) for PostgreSQL インスタンスにアクセスします。Kubernetes ポッドは、共有データを Amazon S3 に保存します。

ツール

AWS サービス

• AWS CloudFormation は、 AWS リソースをセットアップし、迅速かつ一貫してプロビジョニングし、 AWS アカウント および リージョン全体でライフサイクル全体にわたってリソースを管理するのに役立ちます。

• Amazon Elastic Compute Cloud (Amazon EC2) は、 AWS クラウドでスケーラブルなコンピューティング容量を提供します。必要な数の仮想サーバーを起動することができ、迅速にスケールアップまたはスケールダウンができます。

• Amazon Elastic File System (Amazon EFS) は、 AWS クラウドでの共有ファイルシステムの作成と設定に役立ちます。

• Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、独自の Kubernetes コントロールプレーンやノードをインストールまたは維持 AWS することなく、 で Kubernetes を実行できます。

• Amazon Simple Storage Service (Amazon S3) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。

• Elastic Load Balancing (ELB) は、受信するアプリケーションまたはネットワークのトラフィックを複数のターゲットに分散します。たとえば、1 つ以上のアベイラビリティーゾーンの EC2 インスタンス、コンテナ、IP アドレスにトラフィックを分散できます。

その他のツール

• eksctl – これは Amazon EKS で Kubernetes クラスターを作成および管理するコマンドラインユーティリティです。

• Git はオープンソースの分散バージョン管理システムです。

• HashiCorp Vault は、認証情報やその他の機密情報へのアクセスを制御できる安全なストレージを提供します。

• Helm は、Kubernetes クラスターへのアプリケーションのインストールと管理に役立つ Kubernetes のオープンソースパッケージマネージャーです。

• kubectlは、Kubernetes クラスターに対してコマンドを実行するためのコマンドラインインターフェイスです。

• Postman は API プラットフォームです。

コードリポジトリ

このパターンの Kubernetes 設定 YAML ファイルと Python スクリプトは、 GitHub aws-patterns-edc リポジトリにあります。このパターンでは、Trac-X リポジトリも使用します。

ベストプラクティス

Amazon EKS と参加者のインフラストラクチャの分離

Kubernetes の名前空間は、このパターンで X 社のプロバイダーのインフラストラクチャと Y 社のコンシューマーのインフラストラクチャを分離します。詳細については、「EKS ベストプラクティスガイド」を参照してください。

より現実的な状況では、各参加者には個別の Kubernetes クラスターが独自の 内で実行されています AWS アカウント。共有インフラストラクチャ (このパターンの DAPS) は、データスペースの参加者がアクセスでき、参加者のインフラストラクチャから完全に分離されます。

エピック

環境を設定し、EKS クラスターと EC2 インスタンスをプロビジョニングする

タスク	説明	必要なスキル
リポジトリをクローン作成します。	リポジトリのクローンをワークステーションに作成するには、次のコマンドを実行します。 git clone https://github.com/Think-iT-Labs/aws-patterns-edc ワークステーションは にアクセスできる必要があります AWS アカウント。	DevOps エンジニア
Kubernetes クラスターをプロビジョニングし、名前空間を設定します。	アカウントに簡略化されたデフォルトの EKS クラスターをデプロイするには、リポジトリをクローンしたワークステーションで次のeksctlコマンドを実行します。 eksctl create cluster コマンドは、VPC と、3 つの異なるアベイラビリティーゾーンにまたがるプライベートサブネットとパブリックサブネットを作成します。ネットワークレイヤーが作成されると、 コマンドは Auto Scaling グループ内に 2 つの m5.large EC2 インスタンスを作成します。 詳細と出力例については、「eksctl ガイド」を参照してください。 プライベートクラスターをプロビジョニングしたら、次のコマンドを実行して、新しい EKS クラスターをローカル Kubernetes 設定に追加します。 aws eks update-kubeconfig --name <EKS CLUSTER NAME> --region <AWS REGION> このパターンでは、 eu-west-1 AWS リージョン を使用してすべてのコマンドを実行します。ただし、任意の で同じコマンドを実行できます AWS リージョン。 EKS ノードが実行中で、準備完了状態であることを確認するには、次のコマンドを実行します。 kubectl get nodes	DevOps エンジニア
名前空間を設定します。	プロバイダーとコンシューマーの名前空間を作成するには、次のコマンドを実行します。 kubectl create ns provider kubectl create ns consumer このパターンでは、次のステップの設定に合わせて名前空間consumerとして providerと を使用することが重要です。	DevOps エンジニア

ID サービスをデプロイする

タスク	説明	必要なスキル
を使用して DAPS をデプロイします AWS CloudFormation。	DAPS オペレーションの管理を容易にするために、DAPS サーバーは EC2 インスタンスにインストールされます。 DAPS をインストールするには、 AWS CloudFormation テンプレート を使用します。前提条件セクションの ACM 証明書と DNS 名が必要です。テンプレートは以下をデプロイして設定します。 Application Load Balancer Auto Scaling グループ 必要なパッケージをすべてインストールするためのユーザーデータで設定された EC2 インスタンス IAM ロール DAPS テンプレートをデプロイするには AWS CloudFormation 、 にサインイン AWS Management Console し、AWS CloudFormation コンソール を使用します。テンプレートは、次のような AWS CLI コマンドを使用してデプロイすることもできます。 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 環境名は独自の選択です。 AWS リソースタグに反映DapsInfrastructureされるため、 などの意味のある用語を使用することをお勧めします。 このパターンでは、 t3.smallは 3 つの Docker コンテナがある DAPS ワークフローを実行するのに十分な大きさです。 テンプレートは EC2 インスタンスをプライベートサブネットにデプロイします。つまり、インスタンスはインターネットから SSH (Secure Shell) 経由で直接アクセスすることはできません。インスタンスは、 の一機能である Session Manager を介して実行中のインスタンスへのアクセスを可能にするために必要な IAM ロールと AWS Systems Manager エージェントでプロビジョニングされます AWS Systems Manager。 アクセスには Session Manager を使用することをお勧めします。または、踏み台ホストをプロビジョニングして、インターネットからの SSH アクセスを許可することもできます。踏み台ホストアプローチを使用する場合、EC2 インスタンスの実行開始に数分かかることがあります。 AWS CloudFormation テンプレートが正常にデプロイされたら、DNS 名を Application Load Balancer の DNS 名にポイントします。これを確認するには、次のコマンドを実行します。 dig <DNS NAME> 出力は次の例のようになります: ; <<>> 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 エンジニア
参加者のコネクタを DAPS サービスに登録します。	DAPS 用にプロビジョニングされた EC2 インスタンス内から、参加者を登録します。 ルートユーザーを使用してEC2 インスタンスで使用可能なスクリプトを実行します。 cd /srv/mvds/omejdn-daps プロバイダーを登録します。 bash scripts/register_connector.sh <provider_name> コンシューマーを登録します。 bash scripts/register_connector.sh <consumer_name> 名前の選択は次のステップには影響しません。と consumerまたは providerと companyx のいずれかを使用することをお勧めしますcompanyy。 また、登録コマンドは、作成された証明書とキーから取得された必要な情報を使用して DAPS サービスを自動的に設定します。 DAPS サーバーにログインしている間、インストールの後のステップで必要な情報を収集します。 プロバイダーとコンシューマーclient idの omejdn-daps/config/clients.ymlを取得します。client id 値は 16 進数の長い文字列です。 omejdn-daps/keys ディレクトリから、、consumer.cert、、consumer.keyprovider.certおよび provider.key ファイルの内容をコピーします。 テキストをコピーして、ワークステーションのプレフィックス が付いた同様の名前のファイルに貼り付けdaps-ることをお勧めします。 プロバイダーとコンシューマーIDs があり、ワークステーションの作業ディレクトリに 4 つのファイルがある必要があります。 ソースファイル名consumer.certはワークステーションファイル名 になりますdaps-consumer.cert。 ソースファイル名はワークステーションファイル名 consumer.keyになりますdaps-consumer.key。 ソースファイル名はワークステーションファイル名 provider.certになりますdaps-provider.cert。 ソースファイル名はワークステーションファイル名 provider.keyになりますdaps-provider.key。	DevOps エンジニア

参加者のコネクタをデプロイする

タスク	説明	必要なスキル
Trac-X リポジトリのクローンを作成し、0.4.1 バージョンを使用します。	Trac-X コネクタのビルドでは、PostgreSQL (アセットデータベース) と HashiCorp Vault (シークレット管理) サービスをデプロイして使用できるようにする必要があります。 Trac-X Helm グラフにはさまざまなバージョンがあります。このパターンは DAPS サーバーを使用するため、バージョン 0.4.1 を指定します。 最新バージョンでは、ID サービスの分散実装で Managed Identity Wallet (MIW) を使用します。 2 つの Kubernetes 名前空間を作成したワークステーションで、tractusx-edc リポジトリ のクローンを作成し、release/0.4.1ブランチを確認します。 git clone https://github.com/eclipse-tractusx/tractusx-edc cd tractusx-edc git checkout release/0.4.1	DevOps エンジニア
Trac-X Helm チャートを設定します。	両方のコネクタが相互にやり取りできるように、Trac-X Helm チャートテンプレート設定を変更します。 これを行うには、名前空間をサービスの DNS 名に追加して、クラスター内の他のサービスによって解決されるようにします。これらの変更は、 charts/tractusx-connector/templates/_helpers.tpl ファイルに対して行う必要があります。このパターンでは、このファイルの最終変更バージョンを使用できます。コピーして、ファイル の dapsセクションに配置しますcharts/tractusx-connector/templates/_helpers.tpl。 すべての DAPS 依存関係を に必ずコメントしてください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 エンジニア
Amazon RDS で PostgreSQL を使用するようにコネクタを設定します。	（オプション) このパターンではAmazon Relational Database Service (Amazon RDS) インスタンスは必要ありません。ただし、Amazon RDS または Amazon Aurora は高可用性、バックアップ、リカバリなどの機能を提供するため、使用を強くお勧めします。 Kubernetes 上の PostgreSQL を Amazon RDS に置き換えるには、次の手順を実行します。 Amazon RDS for PostgreSQL インスタンス をプロビジョニングします。 でChart.yaml、 PostgreSQLセクションにコメントを付けます。 provider_values.yml および でconsumer_values.yml、 postgresqlセクションを次のように設定します。 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 エンジニア
プロバイダーコネクタとそのサービスを設定してデプロイします。	プロバイダーコネクタとそのサービスを設定するには、次の手順を実行します。 edc_helm_configs ディレクトリから現在の Helm チャートフォルダにprovider_edc.yamlファイルをダウンロードするには、次のコマンドを実行します。 wget -q https://raw.githubusercontent.com/Think-iT-Labs/aws-patterns-edc/main/edc_helm_configs/provider_edc.yaml> -P charts/tractusx-connector/ 次の変数 ( ファイルでもマークされています) を値に置き換えます。 CLIENT_ID ‒ DAPS によって生成された ID。は DAPS サーバー/srv/mvds/omejdn-daps/config/clients.yml/config/clients.yml上にあるCLIENT_ID必要があります。16 進数の文字の文字列である必要があります。 DAPS_URL ‒ DAPS サーバーの URL。 AWS CloudFormation テンプレートの実行時に設定した DNS 名https://{DNS name}を使用している必要があります。 VAULT_TOKEN ‒ ボールト認証に使用されるトークン。任意の値を選択します。 vault.fullnameOverride ‒ vault-provider. vault.hashicorp.url ‒ http://vault-provider:8200/. 前の値は、デプロイ名と名前空間名がプロバイダーであることを前提としています。 ワークステーションから Helm チャートを実行するには、次のコマンドを使用します。 cd charts/tractusx-connector helm dependency build helm upgrade --install provider ./ -f provider_edc.yaml -n provider	DevOps エンジニア
証明書とキーをプロバイダーボールトに追加します。	混乱を避けるために、 tractusx-edc/charts ディレクトリの外部で次の証明書を生成します。 例えば、次のコマンドを実行してホームディレクトリに変更します。 cd ~ これで、プロバイダーが必要とするシークレットをボールトに追加する必要があります。 ボールト内のシークレットの名前は、 provider_edc.ymlファイルの secretNames:セクションにあるキーの値です。デフォルトでは、次のように設定されます。 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 Advanced Encryption Standard (AES) キー、プライベートキー、パブリックキー、および自己署名証明書が最初に生成されます。その後、これらはシークレットとしてボールトに追加されます。 さらに、このディレクトリには、DAPS サーバーからコピーした daps-provider.certおよび daps-provider.key ファイルが含まれている必要があります。 以下のコマンドを実行します。 # 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 シークレットをボールトに追加する前に、改行を に置き換えて、シークレットを複数行から単一行に変換します\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 Vault に追加されるシークレットをフォーマットするには、次のコマンドを実行します。 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 これでシークレットは JSON 形式で、ボールトに追加される準備が整いました。 ボールトのポッド名を取得するには、次のコマンドを実行します。 kubectl get pods -n provider|egrep "vault|NAME" ポッド名は に似ています"vault-provider-0"。この名前は、ボールトへのポート転送を作成するときに使用されます。ポート転送では、ボールトにアクセスしてシークレットを追加できます。これは、AWS 認証情報が設定されたワークステーションから実行する必要があります。 ボールトにアクセスするには、 kubectlを使用してポートフォワードを設定します。 kubectl port-forward <VAULT_POD_NAME> 8200:8200 -n provider これで、ブラウザまたは CLI からボールトにアクセスできるはずです。 ブラウザ ブラウザを使用して http://127.0.0.1:8200 に移動します。 では、設定したポートフォワードが使用されます。 で以前に設定したトークンを使用してログインしますprovider_edc.yml。シークレットエンジンで、3 つのシークレットを作成します。各シークレットには、次のリストに示すシークレット名である Path for this secret 値があります。secret data セクション内では、キーの名前は contentになり、値は という名前のそれぞれのファイルの 1 行のテキストになります.line。 シークレット名は、 provider_edc.yml ファイルの secretNamesセクションから取得されます。 次のシークレットを作成します。 ファイル名transfer-proxy-token-signer-private-keyのシークレット provider-private-key.pem.line ファイル名transfer-proxy-token-signer-public-keyのシークレット provider-cert.pem.line ファイル名transfer-proxy-token-encryption-aes-keyのシークレット provider-aes.key.line ファイル名daps-private-keyのシークレット daps-provider.key.line ファイル名daps-public-keyのシークレット daps-provider.cert.line ボールト CLI CLI は、設定したポート転送も使用します。 ワークステーションで、Vault HashiCorp ドキュメント の指示に従って Vault CLI をインストールします。 で設定したトークンを使用してボールトにログインするにはprovider_edc.yml、次のコマンドを実行します。 vault login -address=http://127.0.0.1:8200 正しいトークンを使用すると、 メッセージが表示されます。 "Success! You are now authenticated." 以前に作成した JSON 形式のファイルを使用してシークレットを作成するには、次のコードを実行します。 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 エンジニア
コンシューマーコネクタとそのサービスを設定してデプロイします。	コンシューマーを設定およびデプロイする手順は、プロバイダーに対して完了した手順と似ています。 aws-patterns-edc リポジトリconsumer_edc.yamlから tractusx-edc/charts/tractusx-connector フォルダに をコピーするには、次のコマンドを実行します。 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/ 次の変数を実際の値で更新します。 CONSUMER_CLIENT_ID ‒ DAPS によって生成された ID。は DAPS サーバーconfig/clients.yml上にあるCONSUMER_CLIENT_ID必要があります。 DAPS_URL ‒ プロバイダーに使用したのと同じ DAPS URL。 VAULT_TOKEN ‒ ボールト認証に使用されるトークン。任意の値を選択します。 vault.fullnameOverride ‒ vault-consumer vault.hashicorp.url ‒ http://vault-provider:8200/ 前の値は、デプロイ名と名前空間名が であることを前提としていますconsumer。 Helm チャートを実行するには、次のコマンドを使用します。 cd charts/tractusx-connector helm upgrade --install consumer ./ -f consumer_edc.yaml -n consumer
証明書とキーをコンシューマーボールトに追加します。	セキュリティの観点から、データスペース参加者ごとに証明書とキーを再生成することをお勧めします。このパターンは、コンシューマーの証明書とキーを再生成します。 これらの手順は、プロバイダーの手順と非常によく似ています。consumer_edc.yml ファイル内のシークレット名を確認できます。 ボールト内のシークレットの名前は、 の secretNames:セクションにあるキーの値ですconsumer_edc.yml file。デフォルトでは、次のように設定されます。 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 DAPS サーバーからコピーした daps-consumer.certおよび daps-consumer.key ファイルは、このディレクトリに既に存在している必要があります。 以下のコマンドを実行します。 # 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 ファイルを手動で編集して改行を に置き換えるか\n、次のような 3 つのコマンドを使用します。 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 Vault に追加されるシークレットをフォーマットするには、次のコマンドを実行します。 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 これでシークレットは JSON 形式で、ボールトに追加される準備が整いました。 コンシューマーボールトのポッド名を取得するには、次のコマンドを実行します。 kubectl get pods -n consumer | egrep "vault|NAME" ポッド名は に似ています"vault-consumer-0"。この名前は、ボールトへのポート転送を作成するときに使用されます。ポート転送では、ボールトにアクセスしてシークレットを追加できます。これは、 AWS 認証情報が設定されたワークステーションから実行する必要があります。 ボールトにアクセスするには、 kubectlを使用してポートフォワードを設定します。 kubectl port-forward <VAULT_POD_NAME> 8201:8200 -n consumer プロデューサーとコンシューマーの両方にポート転送を設定できるように、ローカルポートは今回 8201 です。 ブラウザ ブラウザを使用して http://localhost:8201/ に接続し、説明に従ってコンシューマーボールトにアクセスし、名前とコンテンツを含むシークレットを作成できます。 コンテンツを含むシークレットとファイルは次のとおりです。 ファイル名transfer-proxy-token-signer-private-keyのシークレット consumer-private-key.pem.line ファイル名transfer-proxy-token-signer-public-keyのシークレット consumer-cert.pem.line ファイル名transfer-proxy-token-encryption-aes-keyのシークレット consumer-aes.key.line ボールト CLI Vault CLI を使用すると、次のコマンドを実行してボールトにログインし、シークレットを作成できます。 内で設定したトークンを使用してボールトにログインしますconsumer_edc.yml。 vault login -address=http://127.0.0.1:8201 正しいトークンを使用すると、 メッセージが表示されます。 "Success! You are now authenticated." 以前に作成した JSON 形式のファイルを使用してシークレットを作成するには、次のコードを実行します。 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 エンジニア

コネクタの管理 API とやり取りするように HTTP クライアントを設定する

タスク	説明	必要なスキル
ポート転送を設定します。	ポッドのステータスを確認するには、次のコマンドを実行します。 kubectl get pods -n provider kubectl get pods -n consumer Kubernetes デプロイが成功したことを確認するには、次のコマンドを実行して、プロバイダーとコンシューマーの Kubernetes ポッドのログを確認します。 kubectl logs -n provider <producer control plane pod name> kubectl logs -n consumer <consumer control plane pod name> クラスターはプライベートであり、パブリックにアクセスすることはできません。コネクタを操作するには、Kubernetes ポート転送機能を使用して、マシンによって生成されたトラフィックをコネクタコントロールプレーンに転送します。 最初のターミナルで、ポート 8300 を介してコンシューマーのリクエストを管理 API に転送します。 kubectl port-forward deployment/consumer-tractusx-connector-controlplane 8300:8081 -n consumer 2 番目のターミナルで、プロバイダーのリクエストをポート 8400 経由で管理 API に転送します。 kubectl port-forward deployment/provider-tractusx-connector-controlplane 8400:8081 -n provider	DevOps エンジニア
プロバイダーとコンシューマーの S3 バケットを作成します。	コネクタは現在、ロールを引き受けることによって提供される認証情報など、一時的な AWS 認証情報を使用しません。 は、IAM アクセスキー ID とシークレットアクセスキーの組み合わせ の使用のみをサポートします。 後のステップでは 2 つの S3 バケットが必要です。1 つの S3 バケットは、プロバイダーが利用できるデータの保存に使用されます。もう 1 つの S3 バケットは、コンシューマーが受信したデータ用です。 IAM ユーザーには、2 つの名前付きバケット内のオブジェクトのみを読み書きするアクセス許可が必要です。 アクセスキー ID とシークレットアクセスキーペアを作成して安全に保つ必要があります。この MVDS が廃止されたら、IAM ユーザーを削除する必要があります。 次のコードは、 ユーザーの IAM ポリシーの例です。 { "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 エンジニア
コネクタを操作するように Postman を設定します。	EC2 インスタンスを介してコネクタを操作できるようになりました。Postman を HTTP クライアントとして使用し、プロバイダーとコンシューマーコネクタの両方に Postman コレクションを提供します。 aws-pattern-edc リポジトリから Postman インスタンスにコレクションをインポートします。 このパターンでは、Postman コレクション変数を使用してリクエストに入力を提供します。	アプリ開発者、データエンジニア

コネクタを介して X 社のカーボンエミッションフットプリントデータを提供する

タスク	説明	必要なスキル
共有する炭素排出量の強度データを準備します。	まず、共有するデータアセットを決定する必要があります。X 社のデータは、その車両フリートのカーボンエミッションフットプリントを表します。重量はトン単位の車両総重量 (GVW) で、排出量はホイールツーウェル (WTW) 測定値に従って 1 トン/キロメートル (例: CO2 e/t-km) CO2あたりの CO2 を消費します。 車両タイプ: バン、重量: < 3.5、排出量: 800 車両タイプ: 都市トラック、重量: 3.5～7.5、排出量: 315 車両タイプ: 中型車両 (MGV)、重量: 7.5‒20、排出量: 195 車両タイプ: 重量車両 (HGV)、重量: > 20、排出量: 115 サンプルデータはリポジトリの carbon_emissions_data.json ファイルにありますaws-patterns-edc。 X 社は Amazon S3 を使用してオブジェクトを保存します。 S3 バケットを作成し、そこにサンプルデータオブジェクトを保存します。次のコマンドは、デフォルトのセキュリティ設定で S3 バケットを作成します。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> S3 バケット名はグローバルに一意である必要があります。命名規則の詳細については、AWS ドキュメント を参照してください。	データエンジニア、アプリ開発者
Postman を使用してデータアセットをプロバイダーのコネクタに登録します。	コネクタのデータアセットは、データの名前とその場所を保持します。この場合、 コネクタのデータアセットは S3 バケットに作成されたオブジェクトを指します。 コネクタ： プロバイダー リクエスト：アセットの作成 コレクション変数： を更新しますASSET_NAME。アセットを表すわかりやすい名前を選択します。 リクエストボディ： プロバイダー用に作成した S3 バケットでリクエストボディを更新します。 "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>" } レスポンス： リクエストが成功すると、新しく作成されたアセットの作成時刻とアセット ID が返されます。 { "@id": "c89aa31c-ec4c-44ed-9e8c-1647f19d7583" } コレクション変数 ASSET_ID: Postman コレクション変数を、作成後に コネクタによって自動的に生成された ID ASSET_IDで更新します。	アプリ開発者、データエンジニア
アセットの使用ポリシーを定義します。	データアセットは、明確な使用ポリシーに関連付ける必要があります。まず、プロバイダーコネクタにポリシー定義を作成します。 X 社のポリシーは、データスペースの参加者が炭素排出量フットプリントデータを使用できるようにすることです。 リクエスト本文： コネクタ： プロバイダー リクエスト： ポリシーの作成 コレクション変数: ポリシーの名前でPolicy Name変数を更新します。 レスポンス： リクエストが成功すると、作成された時刻と、新しく作成されたポリシーのポリシー ID が返されます。コレクション変数を、作成後に コネクタによって生成されたポリシーの ID POLICY_IDで更新します。	アプリ開発者、データエンジニア
アセットとその使用ポリシーの 契約オファーを定義します。	他の参加者がデータへのアクセスをリクエストできるようにするには、使用条件とアクセス許可を指定する契約でデータを提供します。 コネクタ： プロバイダー リクエスト： 契約定義の作成 コレクション変数: Contract Name変数を契約オファーまたは定義の名前で更新します。	アプリ開発者、データエンジニア

アセットを見つけて、定義された契約について合意する

タスク	説明	必要なスキル
X 社が共有するデータカタログをリクエストします。	データスペース内のデータコンシューマーとして、Y 社はまず他の参加者と共有されているデータを検出する必要があります。 この基本的なセットアップでは、コンシューマーコネクタにプロバイダーコネクタから利用可能なアセットのカタログを直接リクエストするように依頼することで、これを行うことができます。 コネクタ： コンシューマー リクエスト： リクエストカタログ レスポンス： プロバイダーから利用可能なすべてのデータアセットと、アタッチされた使用ポリシー。データコンシューマーは、関心のある契約を探し、それに応じて次のコレクション変数を更新します。 CONTRACT_OFFER_ID ‒ コンシューマーが交渉したい契約オファーの ID ASSET_ID ‒ コンシューマーがネゴシエートしたいアセットの ID PROVIDER_CLIENT_ID ‒ ネゴシエートするプロバイダーコネクタの ID	アプリ開発者、データエンジニア
X 社からの炭素排出量強度データの契約交渉を開始します。	消費するアセットを特定したら、コンシューマーコネクタとプロバイダーコネクタの間で契約交渉プロセスを開始します。 コネクタ： コンシューマー リクエスト： 契約交渉 コレクション変数： ネゴシエートするコンシューマーコネクタの ID でCONSUMER_CLIENT_ID変数を更新します。 プロセスが検証済み状態になるまでに時間がかかる場合があります。 契約交渉の状態と対応する契約 ID は、 Get Negotiationリクエストを使用して確認できます。	アプリ開発者、データエンジニア

契約を使用してデータを使用する

タスク	説明	必要なスキル
HTTP エンドポイントからデータを使用します。	（オプション 1) HTTP データプレーンを使用してデータスペース内のデータを消費するには、webhook.site を使用して HTTP サーバーをエミュレートし、コンシューマーコネクタで転送プロセスを開始します。 コネクタ： コンシューマー リクエスト： 契約交渉 コレクション変数: コネクタによって生成された契約契約の ID でContract Agreement ID変数を更新します。 リクエスト本文： リクエスト本文を更新して、ウェブフック URL のdataDestination横に HTTPを指定します。 { "dataDestination": { "type": "HttpProxy" }, "privateProperties": { "receiverHttpEndpoint": "<WEBHOOK URL>" } } コネクタは、ファイルのダウンロードに必要な情報をウェブフック URL に直接送信します。 受信したペイロードは、次のようになります。 { "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" } } 受信した認証情報を使用して、プロバイダーによって共有された S3 アセットを取得します。 この最後のステップでは、ペイロード () に記載されているように、コンシューマーデータプレーンにリクエストを送信する必要があります (ポートを適切に転送）endpoint。	アプリ開発者、データエンジニア
S3 バケットからデータを直接消費します。	（オプション 2) Amazon S3 と コネクタの統合を使用し、コンシューマーインフラストラクチャの S3 バケットを宛先として直接指します。 リクエストボディ： リクエストボディを更新して、S3 バケットを dataDestination として指定します。 これは、コンシューマーが受信したデータを保存するために以前に作成した S3 バケットである必要があります。 { "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 }}" } } }	データエンジニア、アプリ開発者

トラブルシューティング

問題	ソリューション
コネクタは、証明書の PEM 形式に関する問題を引き起こす可能性があります。	を追加して、各ファイルの内容を 1 行に連結します\n。

関連リソース

• DSSC

• 持続可能性のユースケースのためのデータスペースの構築 ( Think-it による AWS 規範ガイダンス戦略）

• データスペースの AWS

• Trac-X ドキュメント

• DAPS

• データスペースと AWS によるデータ共有の有効化 (ブログ記事）

追加情報

データスペースの仕様

参加者

Participant	会社の説明	会社のフォーカス
X 社	ヨーロッパと南米で車両のフリートを運用し、さまざまな商品を輸送します。	炭素排出量のフットプリントの強度を減らすために、データ主導型の意思決定を行うことを目指します。
Y 社	環境規制当局	炭素排出量の強度など、企業や業界の環境への影響を監視および軽減するために設計された環境規制とポリシーを実施します。

ビジネスケース

X 社は、データスペーステクノロジーを使用してカーボンフットプリントデータをコンプライアンス監査者である Y 社と共有し、X 社の物流業務による環境への影響を評価して対処します。

データスペースの権限

データスペース機関は、データスペースを管理する組織のコンソーシアムです。このパターンでは、X 社と Y 社がガバナンス本文を形成し、フェデレーティッドデータスペースの権限を表します。

データスペースコンポーネント

コンポーネント	選択した実装	追加情報
データセット交換プロトコル	Dataspace Protocol バージョン 0.8	JSON-LD データカタログ語彙 (DCAT)
データスペースコネクタ	Trac-X コネクタバージョン 0.4.1	拡張機能
データ交換ポリシー	デフォルトの使用ポリシー	Open Digital Rights Language (ODRL)

データスペースサービス

サービス	実装	追加情報
ID サービス	動的属性プロビジョニングシステム (DAPS)	「動的属性プロビジョニングシステム (DAPS) には、組織やコネクタに対する特定の属性を確認する意図があります。したがって、DAPS アサーション を信頼しているサードパーティーは後者を信頼する必要はありません。— DAPS コネクタのロジックに焦点を当てるために、データスペースは Docker Compose を使用して Amazon EC2 マシンにデプロイされます。
検出サービス	Gaia-X フェデレーティッドカタログ	「フェデレーティッドカタログは、Gaia-X 自己説明のインデックス付きリポジトリを構成し、プロバイダーとそのサービスサービスの検出と選択を可能にします。自己説明は、参加者が自分自身とサービスについてプロパティとクレームの形式で提供する情報です。」 — Gaia-X エコシステムのキックスターター

交換するデータ

データアセット	説明	[形式]
炭素排出量データ	指定されたリージョン (欧州および南米) 内の車両フリート全体からの異なる車両タイプの強度値	JSON ファイル

データモデル

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

Trac-X コネクタ

各 Trac-X パラメータのドキュメントについては、元の値ファイル を参照してください。

次の表に、すべての のサービス、および対応する公開ポートとエンドポイントを示します。

[サービス名]	ポートとパス
コントロールプレーン	管理 : ‒ ポート: 8081 パス: /management 管理 ‒ ポート: 8083 パス: /control プロトコルポート: 8084 パス: /api/v1/dsp メトリクス ‒ ポート: 9090 パス: /metrics オブザーバビリティ ‒ ポート: 8085 パス: /observability
データプレーン	デフォルト ‒ ポート: 8080 パス: /api パブリック ‒ ポート: 8081 パス: /api/dataplane/control プロキシ ‒ ポート: 8186 パス: /proxy メトリクス ‒ ポート: 9090 パス: /metrics 可観測性 ‒ ポート: 8085 パス: /observability
ボールト	ポート: 8200
PostgreSQL	ポート: 5432

AWS Secrets Manager Manager の使用

HashiCorp Vault の代わりに Secrets Manager をシークレットマネージャーとして使用できます。そのためには、 は AWS Secrets Manager 拡張機能を使用または構築する必要があります。

Trac-X は Secrets Manager をサポートしていないため、独自のイメージの作成と保守はお客様の責任となります。

そのためには、 AWS Secrets Manager 拡張機能を導入して、コントロールプレーンとコネクタのデータプレーンの両方のビルド Gradle ファイルを変更し (例についてはこの Maven アーティファクトを参照）、Docker イメージを構築、保守、参照する必要があります。

Trac-X コネクタの Docker イメージのリファクタリングの詳細については、「Refactor Trac-X Helm charts」を参照してください。

わかりやすくするために、このパターンでコネクタイメージを再構築することは避け、 HashiCorp ボールトを使用します。