検索

第11章 TLS 証明書の管理

download PDF

AMQ Streams は、Kafka と AMQ Streams コンポーネントとの間で TLS プロトコルを使用して暗号化された通信をサポートします。Kafka ブローカー間の通信 (Interbroker 通信)、ZooKeeper ノード間の通信 (Internodal 通信)、およびこれらのコンポーネントと AMQ Streams Operator 間の通信は、常に暗号化されます。Kafka クライアントと Kafka ブローカーとの間の通信は、クラスターが設定された方法に応じて暗号化されます。Kafka および AMQ Streams コンポーネントでは、TLS 証明書も認証に使用されます。

Cluster Operator は、自動で TLS 証明書の設定および更新を行い、クラスター内での暗号化および認証を有効にします。また、Kafka ブローカーとクライアントとの間の暗号化または TLS 認証を有効にする場合、他の TLS 証明書も設定されます。ユーザーが用意した証明書は更新されません。

TLS 暗号化が有効になっている TLS リスナーまたは外部リスナーの、Kafka リスナー証明書 と呼ばれる独自のサーバー証明書を提供できます。詳細は、「Kafka リスナー証明書」 を参照してください。

図11.1 TLS によってセキュリティーが保護された通信のアークテクチャー例

セキュアな通信

11.1. 認証局

暗号化のサポートには、AMQ Streams コンポーネントごとに固有の秘密鍵と公開鍵証明書が必要です。すべてのコンポーネント証明書は、クラスター CA と呼ばれる内部認証局 (CA) により署名されます。

同様に、TLS クライアント認証を使用して AMQ Streams に接続する各 Kafka クライアントアプリケーションは、秘密鍵と証明書を提供する必要があります。クライアント CA という第 2 の内部 CA を使用して、Kafka クライアントの証明書に署名します。

11.1.1. CA 証明書

クラスター CA とクライアント CA の両方には、自己署名の公開鍵証明書があります。

Kafka ブローカーは、クラスター CA またはクライアント CA のいずれかが署名した証明書を信頼するように設定されます。クライアントによる接続が不要なコンポーネント (ZooKeeper など) のみが、クラスター CA によって署名された証明書を信頼します。外部リスナーの TLS 暗号化が無効でない限り、クライアントアプリケーションはクラスター CA により署名された証明書を必ず信頼する必要があります。これは、相互 TLS 認証 を実行するクライアントアプリケーションにも当てはまります。

デフォルトで、AMQ Streams はクラスター CA またはクライアント CA によって発行された CA 証明書を自動で生成および更新します。これらの CA 証明書の管理は、Kafka.spec.clusterCa および Kafka.spec.clientsCa オブジェクトで設定できます。ユーザーが用意した証明書は更新されません。

クラスター CA またはクライアント CA に、独自の CA 証明書を提供できます。詳細は、「独自の CA 証明書のインストール」 を参照してください。独自の証明書を提供する場合は、証明書の更新が必要なときに手作業で更新する必要があります。

11.1.2. 独自の CA 証明書のインストール

この手順では、Cluster Operator で生成される CA 証明書と鍵を使用する代わりに、独自の CA 証明書と秘密鍵をインストールする方法について説明します。

以下の手順を使用して、独自のクラスターまたはクライアント CA 証明書をインストールできます。

この手順では、PEM 形式の CA 証明書の更新を説明します。PKCS #12 形式の証明書を使用することもできます。

前提条件

  • Cluster Operator が稼働している必要があります。
  • Kafka クラスターがデプロイされていない必要があります。
  • クラスター CA またはクライアントの、PEM 形式による独自の X.509 証明書および鍵が必要です。

    • ルート CA ではないクラスターまたはクライアント CA を使用する場合、証明書ファイルにチェーン全体を含める必要があります。チェーンの順序は以下のとおりです。

      1. クラスターまたはクライアント CA
      2. 1 つ以上の中間 CA
      3. ルート CA
    • チェーン内のすべての CA は、X509v3 の基本制約 (Basic Constraint) で CA として設定する必要があります。

手順

  1. CA 証明書を対応する Secret に配置します。

    1. 既存のシークレットを削除します。

      oc delete secret CA-CERTIFICATE-SECRET

      CA-CERTIFICATE-SECRETSecretの名前で、クラスタCA証明書の場合はCLUSTER-NAME-cluster-ca-certであり、クライアントCA証明書の場合はCLUSTER-NAME-clients-ca-certとなります。

      「Not Exists」エラーを無視します。

    2. 新規シークレットを作成およびラベル付けします。

      oc create secret generic CA-CERTIFICATE-SECRET --from-file=ca.crt=CA-CERTIFICATE-FILENAME
  2. CA キーを対応する Secret に配置します。

    1. 既存のシークレットを削除します。

      oc delete secret CA-KEY-SECRET

      CA-KEY-SECRET は CA キーの名前です。これは、クラスター CA キーの場合は CLUSTER-NAME-cluster-ca、クライアント CA キーの場合は CLUSTER-NAME-clients-ca です。

    2. 新規シークレットを作成します。

      oc create secret generic CA-KEY-SECRET --from-file=ca.key=CA-KEY-SECRET-FILENAME
  3. シークレットに strimzi.io/kind=Kafka および strimzi.io/cluster=CLUSTER-NAME ラベルを付けます。

    oc label secret CA-CERTIFICATE-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
    oc label secret CA-KEY-SECRET strimzi.io/kind=Kafka strimzi.io/cluster=CLUSTER-NAME
  4. クラスターの Kafka リソースを作成し、生成された CA を使用 しない ように Kafka.spec.clusterCa または Kafka.spec.clientsCa オブジェクトを設定します。

    独自指定の証明書を使用するようにクラスター CA を設定する Kafka リソースの例 (抜粋)

    kind: Kafka
    version: kafka.strimzi.io/v1beta2
    spec:
      # ...
      clusterCa:
        generateCertificateAuthority: false

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.