![[OpenShift Container Platform]](ngocp.gif)
![[IBM Cloud Pak for Integration]](ngcp4i.gif)
![[Linux]](nglinux.gif)
例: TLS の構成
この例では、 IBM® MQ Operatorを使用して、キュー・マネージャーを Red Hat® OpenShift® Container Platform にデプロイします。 サンプル・クライアントとキュー・マネージャーの間に単方向の TLS 通信を構成します。 この例では、メッセージの書き込みと読み取りによって構成が成功したことを確認します。
始める前に
この例を完了するには、まず以下の前提条件を満たしておく必要があります。
- IBM MQ clientをインストールし、 samp/bin と bin を パスに追加します。 runmqakm、 amqsputc 、および amqsgetc アプリケーションが必要です。これらのアプリケーションは、以下のように IBM MQ client の一部としてインストールできます。
![[Windows]](ngwin.gif)
Windows と の場合: Linux®https://ibm.biz/mq92redistclientsから、ご使用のオペレーティングシステム用の 再配布可能クライアントをインストールしてください。 IBM MQ
Mac 用:ダウンロードして設定する IBM MQ MacOS Toolkithttps://developer.ibm.com/tutorials/mq-macos-dev/
- ご使用のオペレーティング・システム用の OpenSSL ツールをインストールします。
- この例のための Red Hat OpenShift Container Platform (OCP) プロジェクト / 名前空間を作成します。
- コマンド・ラインで OCP クラスターにログインし、上記の名前空間に切り替えます。
- 上記の名前空間に IBM MQ Operator がインストールされ、使用可能であることを確認します。
本タスクについて
この例では、 Red Hat OpenShift Container Platformにデプロイするキュー・マネージャーを定義するカスタム・リソース YAML を提供します。 また、TLS を有効にしてキュー・マネージャーをデプロイするために必要な追加のステップも詳しく説明しています。 完了したら、メッセージの書き込みと読み取りによって、TLS を使用してキュー・マネージャーが構成されていることを検証します。
IBM MQ サーバー用の TLS 秘密鍵と証明書を作成します。
以下のコード例は、キュー・マネージャーの自己署名証明書を作成する方法と、クライアントのトラストストアとして機能する鍵データベースに証明書を追加する方法を示しています。 秘密鍵と証明書がすでに存在する場合は、代わりにそれらを使用できます。
自己署名証明書は、開発目的のみで使用すべきであることに注意してください。
- 現行ディレクトリーへの自己署名の秘密鍵と公開証明書の作成
- 以下のコマンドを実行します。
openssl req -newkey rsa:2048 -nodes -keyout tls.key -subj "/CN=localhost" -x509 -days 3650 -out tls.crt - クライアントの鍵データベースへのサーバーの公開鍵の追加
- クライアント・アプリケーションのトラストストアとして鍵データベースを使用します。
- キュー・マネージャー・デプロイメントの TLS 証明書の構成
- キュー・マネージャーが鍵と証明書を参照して適用できるようにするために、上で作成したファイルを参照する Kubernetes TLS シークレットを作成します。 まず、このタスクの開始前に作成した名前空間で作業していることを確認してください。
oc create secret tls example-tls-secret --key="tls.key" --cert="tls.crt" - MQSC コマンドを組み込んだ構成マップの作成
- MQSC コマンドを組み込んだ Kubernetes 構成マップを作成します。そのコマンドによって、新しいキューと SVRCONN チャネルを作成し、nobody というユーザーだけをブロックすることによってチャネルへのアクセスを許可するチャネル認証レコードを追加します。
この方法を使用するのは、開発のためだけに限定してください。
- 必要な OCP ルートの作成
- このタスクを開始する前に作成した名前空間で作業していることを確認してから、OCP UI またはコマンド・ラインで以下の YAML を入力します。
apiVersion: route.openshift.io/v1 kind: Route metadata: name: example-tls-route spec: host: secureqmchl.chl.mq.ibm.com to: kind: Service name: secureqm-ibm-mq port: targetPort: 1414 tls: termination: passthroughRed Hat OpenShift Container Platform Router は、 IBM MQ キュー・マネージャーへの要求のルーティングに SNI を使用することに注意してください。 前に作成した構成マップの MQSC で指定したチャネル名を変更する場合は、ホスト・フィールドも、ここと、後で作成する CCDT ファイルで、変更する必要があります。 詳細は Red Hat OpenShiftの外部からキューマネージャに接続するためのルートの設定 」を参照してください。
- キュー・マネージャーのデプロイ
- 重要: この例では、MQSNOAUT 変数を使用してキュー・マネージャーでの許可を無効にします。これにより、TLS を使用してクライアントを接続するために必要なステップに集中できるようになります。 これは、 IBM MQの実動デプロイメントでは推奨されません。これは、これにより、接続するすべてのアプリケーションが、個々のアプリケーションのアクセス権を下げるメカニズムなしで、完全な管理権限を持つようになるためです。
- キュー・マネージャーが稼働していることの確認
- キュー・マネージャーがデプロイされます。 続行する前に、
Running状態であることを確認してください。 以下に例を示します。oc get qmgr secureqm - キュー・マネージャーへの接続のテスト
- キュー・マネージャーで単方向の TLS 通信が構成されていることを確認するために、サンプル・アプリケーション amqsputc と amqsgetc を使用します。
- キュー・マネージャーのホスト名の検索
- 次のコマンドを使用して、経路
secureqm-ibm-mq-qmのキュー・マネージャー完全修飾ホスト名を見つけます:oc get routes secureqm-ibm-mq-qm - キュー・マネージャーの詳細情報の指定
- キュー・マネージャーの詳細を指定するファイル CCDT.JSON を作成します。 ホストの値を、前のステップで確認したホスト名に置き換えてください。
{ "channel": [ { "name": "SECUREQMCHL", "clientConnection": { "connection": [ { "host": "<hostname from previous step>", "port": 443 } ], "queueManager": "SECUREQM" }, "transmissionSecurity": { "cipherSpecification": "ECDHE_RSA_AES_128_CBC_SHA256" }, "type": "clientConnection" } ] } - 環境変数のエクスポート
- オペレーティング・システムに適した方法で以下の環境変数をエクスポートします。 これらの変数は amqsputc と amqsgetc によって読み取られます。
- キューへのメッセージの書き込み
- 以下のコマンドを実行します。
amqsputc EXAMPLE.QUEUE SECUREQM - キューからのメッセージの取得
- 以下のコマンドを実行します。
amqsgetc EXAMPLE.QUEUE SECUREQM
TLS を有効にしてキュー・マネージャーをデプロイする操作を正常に実行できました。クライアントからキュー・マネージャーに対してメッセージの書き込みと読み取りをセキュアな方法で実行できることも確認できました。