ジョブおよびルートのカスタムトラストストアまたはキーストアファイルの設定

データ統合タスク(ビッグデータを含む)、データサービス、およびルートのカスタムトラストストアまたはキーストアファイルを構成して、外部システムへの接続を認証します。

この例では、データ統合ジョブを使用して構成について説明します。データサービスとルートにも同じ手順が適用されます。

始める前に

dynamic-engine-crdカスタムリソース定義は、oci://ghcr.io/talend/helm/dynamic-engine-crd Helmチャートを使用してインストールされている必要があります。インストールされていない場合は、次のコマンドを実行してインストールしてください。
1. 使用するチャートのバージョンを見つけます。
  - 次のHelmコマンドを実行します:
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Talend Management Consoleから直接バージョンを見るか、自分のDynamic Engineバージョンに含まれているチャートバージョンのDynamic Engine変更ログをチェックしてください。
  - Dynamic EngineバージョンエンドポイントへのAPIコールを使用します。
2. 次のコマンドを実行し、目的のバージョンのHelmチャートをインストールします。
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  <helm_chart_version>を、お使いのDynamic Engineバージョンでサポートされているチャートのバージョンに置換します。
  バージョンを指定しないと、利用可能な最新のdynamic-engine-crdチャートバージョンがインストールされます。
Dynamic Engineがデプロイされている必要があります。デプロイされていない場合は、このコマンドを実行してデプロイしてください。
```
helm install dynamic-engine -f <engine-id>-helm-values/<engine-id>-values.yaml oci://ghcr.io/talend/helm/dynamic-engine 
```
現在のカスタマイズはDynamic Engine環境側でのみ必要であるため、これがデフォルトのデプロイメントです。このため、Dynamic Engineインスタンスにはカスタマイズは設定されません。

このタスクについて

ジョブまたはルートがTLSベースの認証を必要とする外部システムに接続する必要がある場合は、外部システムの証明書を検証するためのカスタムトラストストアを提供するか、外部システムでクライアント証明書の認証が必要な場合はトラストストアとキーストアの両方を提供できます。

注: ルートまたはデータサービス:

この設定は、外部システムへの送信接続にのみ適用されます。ルートまたはデータサービスへの受信クライアントリクエストに対してHTTPSは有効になりません。ここで設定されたキーストアとトラストストアは、ルートまたはデータサービス内のコンポーネントが外部システムへのTLSクライアントとして機能するときに使用され、コンポーネント自体をHTTPS経由で公開するために使用されるものではありません。

手順

Kubernetesマシンで、ダウンロードしておいたHelmデプロイメントのzipファイルを解凍します。
データ統合ジョブで使用するTruststoreファイルまたはKeystoreファイルを作成します。
例
たとえば、ジョブはMySQLデータベースへの接続と、サーバーのIDを確認するためにカスタムの信頼ストアが必要になります。KeystoreファイルやTruststoreファイルを生成する場合は、keytoolコマンドラインユーティリティを使用できます。次に、ジョブで使用されるTruststoreには、MySQLサーバーの証明書に署名した認証局(CA)の証明書が含まれている必要があります。これにより、MySQLクライアントとしてのDynamic Engine環境がサーバーのIDを検証できるようになります。

keytoolの詳細は、Keytoolをご覧ください。MySQLのSSL接続の設定手順については、MySQLのドキュメンテーションをご覧ください。
情報メモ注: KeystoreとTruststoreについて:
- サーバーKeystoreとクライアントTruststore: サーバーKeystoreは、サーバーのプライベートキーと証明書チェーンを保持しています。クライアントがサーバーのIDを検証できるよう、クライアントのTruststoreには、サーバーの署名付き証明書(keytool -exportを使ってサーバーKeystoreからエクスポートされたもの)、またはサーバーの証明書に署名した認証局(CA)証明書が含まれている必要があります。
  実行時に、クライアントのTLS(トランスポートレイヤーセキュリティ)スタックがサーバーの証明書を信頼できるかどうかを検証します。これを行うには、中間証明書を経由し、Truststoreで既に信頼されている証明書を見つけるまでサーバーの証明書チェーンを辿ります。この検証に失敗した場合、セキュアな接続(ハンドシェイク)は中断されます。つまり、クライアントはサーバーの証明書とTrustoreのエントリーが一致したときのみ接続することになります。

カスタム値ファイルを作成し、Dynamic Engine環境に対してTuststoreファイル、またはTruststoreファイルとKeystoreファイルの両方を提供します。

例

この例では、Truststoreファイルのみが使用されます。

STORE_TYPE=truststore
STORE_FILE=${keystoreFolder}/job-truststore.pc12
STORE_PASSWORD=${jobTruststorePassword}
STORE_FILE_TYPE=$(keytool -list -keystore "$STORE_FILE" \
-storepass "$STORE_PASSWORD" 2>/dev/null | awk -F': ' '/Keystore type/{print $2}')
cat <<EOF > $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-$STORE_TYPE-values.yaml
configuration:
  $STORE_TYPE:
    enabled: true
    data: $(base64 -i $STORE_FILE | tr -d '\n')
    password: $STORE_PASSWORD
    type: $STORE_FILE_TYPE
EOF

必要であれば、環境と認証情報に応じて変数値を置換してください。

ヒント: 一部のユースケースでは、ジョブが外部システムのIDを確認するためのTruststoreと、その外部システムへの認証を行うためのKeystoreの両方を提供する必要がことが必要です。そのようなシナリオでは、TruststoreとKeystoreそれぞれに対して値ファイルを作成します:

# Create the truststore values file
STORE_TYPE=truststore
STORE_FILE=${keystoreFolder}/job-truststore.pc12
STORE_PASSWORD=${jobTruststorePassword}
STORE_FILE_TYPE=$(keytool -list -keystore "$STORE_FILE" \
-storepass "$STORE_PASSWORD" 2>/dev/null | awk -F': ' '/Keystore type/{print $2}')
cat <<EOF > $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-$STORE_TYPE-values.yaml
configuration:
  $STORE_TYPE:
    enabled: true
    data: $(base64 -i $STORE_FILE | tr -d '\n')
    password: $STORE_PASSWORD
    type: $STORE_FILE_TYPE
EOF  

# Create the values file forkeystore
STORE_TYPE=keystore
STORE_FILE=${keystoreFolder}/job-keystore.jks
STORE_PASSWORD=${jobKeystorePassword}
STORE_FILE_TYPE=$(keytool -list -keystore "$STORE_FILE" \
-storepass "$STORE_PASSWORD" 2>/dev/null | awk -F': ' '/Keystore type/{print $2}')
cat <<EOF > $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-$STORE_TYPE-values.yaml
configuration:
  $STORE_TYPE:
    enabled: true
    data: $(base64 -i $STORE_FILE | tr -d '\n')
    password: $STORE_PASSWORD
    type: $STORE_FILE_TYPE
EOF

カスタム値ファイルを使って、Dynamic Engine環境チャートをインストールまたはアップグレードします。

helm install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml  \
 -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-truststore-values.yaml \
 oci://ghcr.io/talend/helm/dynamic-engine-environment \
 --version $DYNAMIC_ENGINE_VERSION

上述のとおり、ここではTruststoreの値ファイルのみが必要です。

アップグレードでは、helm installの代わりにhelm upgradeを使用します。

ヒント: ジョブがTruststoreとKeystoreの両方のファイルを提供する必要がある場合は、次のコマンドを実行して両方の値ファイルを同時に適用します:

helm install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml  \
 -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-truststore-values.yaml \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-keystore-values.yaml \
 oci://ghcr.io/talend/helm/dynamic-engine-environment \
 --version $DYNAMIC_ENGINE_VERSION

Dynamic Engine環境の準備が整っていること、そしてデータ統合ジョブがカスタムのTruststoreファイルまたはKeystoreファイルにアクセスできることを確認します。
- 環境サービスがすべて実行されていることを確認します。
- データ統合ジョブを起動し、カスタムのTruststoreファイルまたはKeystoreファイルを使って必要な外部システムに接続できることを確認します。

タスクの結果

デプロイメントが完了すると、Dynamic Engine環境内のデータ統合ジョブは、セキュアな接続のために指定されたTruststoreまたはKeystoreを使用します。

ヒント: データ統合ジョブを外部システムに安全に接続するには、環境レベルでTruststoreファイルまたはKeystoreファイルを設定するだけで十分です。このファイルには、外部システムへのTLS認証を可能にする証明書チェーンが含まれています。ジョブやStudioの設定を変更する必要はありません。

このページは役に立ちましたか?

このページまたはコンテンツにタイポ、ステップの省略、技術的エラーなどの問題が見つかった場合はお知らせください。

こちらにフィードバックをお寄せください