[OpenShift Container Platform][IBM Cloud Pak for Integration][Linux]

例: TLS の構成

この例では、 IBM® MQ Operatorを使用して、キュー・マネージャーを Red Hat® OpenShift® Container Platform にデプロイします。 サンプル・クライアントとキュー・マネージャーの間に単方向の TLS 通信を構成します。 この例では、メッセージの書き込みと読み取りによって構成が成功したことを確認します。

始める前に

この例を完了するには、まず以下の前提条件を満たしておく必要があります。

  • IBM MQ clientをインストールし、 samp/binbinパスに追加します。 runmqakmamqsputc 、および amqsgetc アプリケーションが必要です。これらのアプリケーションは、以下のように IBM MQ client の一部としてインストールできます。
  • ご使用のオペレーティング・システム用の 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
クライアントの鍵データベースへのサーバーの公開鍵の追加
クライアント・アプリケーションのトラストストアとして鍵データベースを使用します。
クライアントの鍵データベースを作成します。
runmqakm -keydb -create -db clientkey.kdb -pw password -type cms -stash
前に生成した公開鍵をクライアントの鍵データベースに追加します。
runmqakm -cert -add -db clientkey.kdb -label mqservercert -file tls.crt -format ascii -stashed
キュー・マネージャー・デプロイメントの TLS 証明書の構成
キュー・マネージャーが鍵と証明書を参照して適用できるようにするために、上で作成したファイルを参照する Kubernetes TLS シークレットを作成します。 まず、このタスクの開始前に作成した名前空間で作業していることを確認してください。
oc create secret tls example-tls-secret --key="tls.key" --cert="tls.crt"
MQSC コマンドを組み込んだ構成マップの作成
MQSC コマンドを組み込んだ Kubernetes 構成マップを作成します。そのコマンドによって、新しいキューと SVRCONN チャネルを作成し、nobody というユーザーだけをブロックすることによってチャネルへのアクセスを許可するチャネル認証レコードを追加します。

この方法を使用するのは、開発のためだけに限定してください。

(「作業を開始する前に」 を参照)で作成した名前空間であることを確認し、OCP UI またはコマンドラインで以下の YAML を入力します。
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-tls-configmap
data:
  tls.mqsc: |
    DEFINE QLOCAL('EXAMPLE.QUEUE') REPLACE 
    DEFINE CHANNEL(SECUREQMCHL) CHLTYPE(SVRCONN) TRPTYPE(TCP) SSLCAUTH(OPTIONAL) SSLCIPH('ANY_TLS12_OR_HIGHER')
    SET CHLAUTH(SECUREQMCHL) TYPE(BLOCKUSER) USERLIST('nobody') ACTION(ADD)
必要な 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: passthrough

Red Hat OpenShift Container Platform Router は、 IBM MQ キュー・マネージャーへの要求のルーティングに SNI を使用することに注意してください。 前に作成した構成マップの MQSC で指定したチャネル名を変更する場合は、ホスト・フィールドも、ここと、後で作成する CCDT ファイルで、変更する必要があります。 詳細は Red Hat OpenShiftの外部からキューマネージャに接続するためのルートの設定 」を参照してください。

キュー・マネージャーのデプロイ
重要: この例では、MQSNOAUT 変数を使用してキュー・マネージャーでの許可を無効にします。これにより、TLS を使用してクライアントを接続するために必要なステップに集中できるようになります。 これは、 IBM MQの実動デプロイメントでは推奨されません。これは、これにより、接続するすべてのアプリケーションが、個々のアプリケーションのアクセス権を下げるメカニズムなしで、完全な管理権限を持つようになるためです。

以下のカスタム・リソース YAML を使用して、新しいキュー・マネージャーを作成します。 前に作成した構成マップとシークレットを参照していること、MQSNOAUT 変数を使用していることに注意してください。
このタスクを開始する前に作成した名前空間にいることを確認してから、コマンド・ラインまたは IBM Cloud Pak® for Integration Platform Navigatorを使用して、OCP UI で以下の YAML を入力します。 正しいライセンスが指定されていることを確認し、falsetrue に変更してライセンスに同意します。
apiVersion: mq.ibm.com/v1beta1
kind: QueueManager
metadata:
  name: secureqm
spec:
  license:
    accept: false
    license: L-RJON-C7QG3S
    use: Production
  queueManager:
    name: SECUREQM
    mqsc:
    - configMap:
        name: example-tls-configmap
        items:
        - tls.mqsc
    storage:
      queueManager:
        type: ephemeral
  template:
    pod:
      containers:
        - env:
            - name: MQSNOAUT
              value: 'yes'
          name: qmgr
  version: 9.2.5.0-r3
  web:
    enabled: true
  pki:
    keys:
      - name: example
        secret:
          secretName: example-tls-secret
          items: 
          - tls.key
          - tls.crt
キュー・マネージャーが稼働していることの確認
キュー・マネージャーがデプロイされます。 続行する前に、Running 状態であることを確認してください。 以下に例を示します。
oc get qmgr secureqm
キュー・マネージャーへの接続のテスト
キュー・マネージャーで単方向の TLS 通信が構成されていることを確認するために、サンプル・アプリケーション amqsputcamqsgetc を使用します。
キュー・マネージャーのホスト名の検索
次のコマンドを使用して、経路 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"
        }
   ]
}
環境変数のエクスポート
オペレーティング・システムに適した方法で以下の環境変数をエクスポートします。 これらの変数は amqsputcamqsgetc によって読み取られます。
システム上のファイルへのパスを更新します。
export MQCCDTURL='<full path to file>/CCDT.JSON'
export MQSSLKEYR='<full path to file>/clientkey'
キューへのメッセージの書き込み
以下のコマンドを実行します。
amqsputc EXAMPLE.QUEUE SECUREQM
キュー・マネージャーへの接続が成功すると、以下の応答が出力されます。
target queue is EXAMPLE.QUEUE
任意のテキストを入力してから Enter を押す操作を何回か繰り返すことで、キューに複数のメッセージを書き込みます。
書き込みを終了するには、Enter を 2 回押します。
キューからのメッセージの取得
以下のコマンドを実行します。
amqsgetc EXAMPLE.QUEUE SECUREQM
前のステップで追加したメッセージがコンシュームされ、出力されます。
数秒後にコマンドが終了します。

TLS を有効にしてキュー・マネージャーをデプロイする操作を正常に実行できました。クライアントからキュー・マネージャーに対してメッセージの書き込みと読み取りをセキュアな方法で実行できることも確認できました。