Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第5章 セキュアな接続の設定

Kafka クラスターとクライアントアプリケーション間の接続を保護すると、クラスターとクライアント間の通信の機密性、整合性、信頼性が確保されます。

セキュアな接続を実現するために、認証、暗号化、および認可に関連する設定を導入できます。

認証
認証メカニズムを使用して、クライアントアプリケーションの ID を検証します。
暗号化
SSL/TLS 暗号化を使用して、クライアントとブローカーの間で転送されるデータの暗号化を有効にします。
認可
クライアントアプリケーションの認証された ID に基づいて、Kafka ブローカーで許可されるクライアントアクセスと操作を制御します。

認可は認証なしでは使用できません。認証が有効になっていない場合は、クライアントの ID を判断できないため、認可ルールを強制することができません。これは、認可ルールが定義されていても、認証がなければ適用されないことを意味します。

Streams for Apache Kafka では、リスナーを使用して Kafka ブローカーとクライアント間のネットワーク接続を設定します。リスナー設定オプションは、ブローカーが受信クライアント接続をリッスンする方法、およびセキュアなアクセスを管理する方法を決定します。必要な正確な設定は、選択した認証、暗号化、および認可メカニズムによって異なります。

Kafka ブローカーとクライアントアプリケーションを設定して、セキュリティー機能を有効にします。Kafka クラスターへのクライアント接続を保護するための一般的な概要は次のとおりです。

  1. Kafka クラスターを含む Streams for Apache Kafka コンポーネントをインストールします。
  2. TLS の場合、ブローカーとクライアントアプリケーションごとに TLS 証明書を生成します。
  3. セキュアな接続のためにブローカー設定でリスナーを設定します。
  4. クライアントアプリケーションをセキュアな接続用に設定します。

Kafka ブローカーとのセキュアで認証された接続を確立するために使用しているメカニズムに従ってクライアントアプリケーションを設定します。Kafka ブローカーが使用する認証、暗号化、認可は、接続元のクライアントアプリケーションが使用するものと同じである必要があります。クライアントアプリケーションとブローカーは、セキュアな通信を行うためにセキュリティープロトコルと設定について合意する必要があります。たとえば、Kafka クライアントと Kafka ブローカーは同じ TLS バージョンと暗号スイートを使用する必要があります。

注記

クライアントとブローカーの間のセキュリティー設定が一致しないと、接続障害が発生したり、セキュリティー上の脆弱性が発生したりする可能性があります。ブローカーとクライアントアプリケーションの両方を慎重に設定およびテストして、それらが適切に保護され、セキュアに通信できることを確認することが重要です。

5.1. セキュアなアクセスのためのブローカーのセットアップ

セキュアなアクセスのためにクライアントアプリケーションを設定するには、まず、使用するセキュリティーメカニズムをサポートするように Kafka クラスター内のブローカーをセットアップする必要があります。セキュアな接続を有効にするには、セキュリティーメカニズムに適切な設定を使用してリスナーを作成します。

5.1.1. RHEL 上で実行されている Kafka クラスターへのセキュアな接続の確立

RHEL で Streams for Apache Kafka を使用する場合、Kafka クラスターへのクライアント接続を保護するための一般的な概要は次のとおりです。

  1. Kafka クラスターを含む Streams for Apache Kafka コンポーネントを RHEL サーバーにインストールします。
  2. TLS の場合、Kafka クラスター内のすべてのブローカーの TLS 証明書を生成します。

  3. ブローカー設定プロパティーファイルでリスナーを設定します。

    • Kafka クラスターリスナーの認証 (TLS や SASL SCRAM-SHA-512 など) を設定します。
    • Kafka クラスターの有効なすべてのリスナーの認可 (simple 認可など) を設定します。
  4. TLS の場合、クライアントアプリケーションごとに TLS 証明書を生成します。
  5. config.properties ファイルを作成して、クライアントアプリケーションで使用される接続の詳細と認証情報を指定します。

  6. Kafka クライアントアプリケーションを起動し、Kafka クラスターに接続します。

    • config.properties ファイルに定義されたプロパティーを使用して、Kafka ブローカーに接続します。
  7. クライアントが Kafka クラスターに正常に接続し、メッセージをセキュアに消費および生成できることを確認します。

関連情報

ブローカーをセットアップする方法の詳細は、次のガイドを参照してください。

5.1.2. RHEL での Kafka クラスターのセキュアなリスナーの設定

設定プロパティーファイルを使用して、Kafka でリスナーを設定します。Kafka ブローカーのセキュアな接続を設定するには、TLS、SASL、およびその他のセキュリティー関連の設定に関連するプロパティーをこのファイルに設定します。

以下は、PKCS#12 形式のキーストアとトラストストアを使用して、Kafka ブローカーの server.properties 設定ファイルで指定された TLS リスナーの設定例です。

server.properties のリスナー設定の例

Copy to Clipboard Toggle word wrap 
listeners = listener_1://0.0.0.0:9093, listener_2://0.0.0.0:9094
listener.security.protocol.map = listener_1:SSL, listener_2:PLAINTEXT
ssl.keystore.type = PKCS12
ssl.keystore.location = /path/to/keystore.p12
ssl.keystore.password = <password>
ssl.truststore.type = PKCS12
ssl.truststore.location = /path/to/truststore.p12
ssl.truststore.password = <password>
ssl.client.auth = required
authorizer.class.name = kafka.security.auth.SimpleAclAuthorizer.
super.users = User:superuser

listeners プロパティーでは、各リスナー名、ブローカーがリッスンする IP アドレスとポートを指定します。プロトコルマップは、TLS 暗号化を使用するクライアントに対して SSL プロトコルを使用するように listener_1 リスナーに指示します。listener_2 は、TLS 暗号化を使用しないクライアントに PLAINTEXT 接続を提供します。キーストアには、ブローカーの秘密鍵と証明書が含まれています。トラストストアには、クライアントアプリケーションの ID を検証するために使用される信頼された証明書が含まれています。ssl.client.auth プロパティーはクライアント認証を強制します。

Kafka クラスターはシンプルな認可を使用します。オーソライザーは SimpleAclAuthorizer に設定されます。すべてのリスナーに対する無制限のアクセスのために、単一のスーパーユーザーが定義されています。Streams for Apache Kafka は、Kafka SimpleAclAuthorizer およびカスタムオーソライザープラグインをサポートしています。

設定プロパティーの前に listener.name.<name_of_listener> を付けると、設定はそのリスナーに固有になります。

これは単なる設定例です。一部の設定オプションはリスナーのタイプに固有です。OAuth 2.0 または Open Policy Agent (OPA) を使用している場合は、特定のリスナーで認可サーバーまたは OPA サーバーへのアクセスを設定する必要もあります。特定の要件と環境に基づいてリスナーを作成できます。

リスナー設定の詳細は、Apache Kafka ドキュメント を参照してください。

ACL を使用してアクセスを微調整する

アクセス制御リスト (ACL) を使用して、Kafka クラスターへのアクセスを微調整できます。アクセス制御リスト (ACL) を作成および管理するには、kafka-acls.sh コマンドラインツールを使用します。ACL は、アクセスルールをクライアントアプリケーションに適用します。

次の例では、最初の ACL は、my-topic という名前の特定のトピックに対する読み取り権限と説明権限を付与します。resource.patternType は literal に設定されます。これは、リソース名が正確に一致する必要があることを意味します。

2 番目の ACL は、my-group という名前の特定のコンシューマーグループに読み取り権限を付与します。resource.patternType は prefix に設定されます。これは、リソース名が接頭辞と一致する必要があることを意味します。

ACL 設定の例

Copy to Clipboard Toggle word wrap 
bin/kafka-acls.sh --authorizer-properties zookeeper.connect=localhost:2181 --add \
--allow-principal User:my-user --operation Read --operation Describe --topic my-topic --resource-pattern-type literal \
--allow-principal User:my-user --operation Read --group my-group --resource-pattern-type prefixed

5.1.3. OpenShift 上で実行している Kafka クラスターへのセキュアな接続の確立

OpenShift で Streams for Apache Kafka を使用する場合、Kafka クラスターへのクライアント接続を保護するための一般的な概要は次のとおりです。

  1. Cluster Operator を使用して、OpenShift 環境に Kafka クラスターをデプロイします。Kafka カスタムリソースを使用して、クラスターを設定およびインストールし、リスナーを作成します。

    • TLS や SASL SCRAM-SHA-512 などのリスナーの認証を設定します。Cluster Operator は、Kafka ブローカーの ID を検証するためのクラスター CA 証明書を含むシークレットを作成します。
    • simple 認可など、有効なすべてのリスナーの認可を設定します。

  2. User Operator を使用して、クライアントを表す Kafka ユーザーを作成します。KafkaUser カスタムリソースを使用して、ユーザーを設定および作成します。

    • リスナーの認証メカニズムと一致する Kafka ユーザー (クライアント) の認証を設定します。User Operator は、クライアントが Kafka クラスターでの認証に使用するクライアント証明書と秘密鍵を含むシークレットを作成します。
    • リスナーの認可メカニズムと一致する Kafka ユーザー (クライアント) の認可を設定します。認可ルールにより、Kafka クラスターでの特定の操作が許可されます。
  3. config.properties ファイルを作成して、クライアントアプリケーションがクラスターに接続するために必要な接続の詳細と認証情報を指定します。

  4. Kafka クライアントアプリケーションを起動し、Kafka クラスターに接続します。

    • config.properties ファイルに定義されたプロパティーを使用して、Kafka ブローカーに接続します。
  5. クライアントが Kafka クラスターに正常に接続し、メッセージをセキュアに消費および生成できることを確認します。

関連情報

ブローカーの設定の詳細は、OpenShift での Streams for Apache Kafka のデプロイと管理 を参照してください。

5.1.4. OpenShift 上の Kafka クラスターのセキュアなリスナーの設定

Streams for Apache Kafka を使用して Kafka カスタムリソースをデプロイする場合、リスナー設定を Kafka spec に追加します。リスナー設定を使用して、Kafka での接続を保護します。Kafka ブローカーのセキュアな接続を設定するには、TLS、SASL、およびその他のセキュリティー関連の設定に関連するプロパティーをリスナーレベルで設定します。

外部リスナーは、OpenShift クラスターの外部から Kafka クラスターへのクライアントアクセスを提供します。Streams for Apache Kafka は、設定に基づいて Kafka クラスターへのアクセスを可能にするリスナーサービスとブートストラップアドレスを作成します。たとえば、次の接続メカニズムを使用する外部リスナーを作成できます。

  • ノードポート
  • loadbalancers
  • OpenShift ルート

Kafka リソースの nodeport リスナーの設定例を次に示します。

Kafka リソースのリスナー設定の例

Copy to Clipboard Toggle word wrap 
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    listeners:
      - name: plaintext
        port: 9092
        type: internal
        tls: false
        configuration:
          useServiceDnsDomain: true
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external
        port: 9094
        type: route
        tls: true
        authentication:
          type: tls
    authorization:
      type: simple
      superUsers:
        - CN=superuser
  # ...

listeners プロパティーは、plaintext、tls、および external の 3 つのリスナーで設定されます。external リスナーのタイプは nodeport で、暗号化と認証の両方に TLS を使用します。Cluster Operator を使用して Kafka クラスターを作成すると、CA 証明書が自動的に生成されます。クラスター CA をクライアントアプリケーションのトラストストアに追加して、Kafka ブローカーの ID を確認します。あるいは、ブローカーまたはリスナーレベルで独自の証明書を使用するように Streams for Apache Kafka を設定することもできます。クライアントアプリケーションが異なるセキュリティー設定を必要とする場合、リスナーレベルでの証明書の使用が必要になる場合があります。リスナーレベルで証明書を使用すると、制御とセキュリティーの層が追加されます。

ヒント

設定プロバイダープラグインを使用して、設定データをプロデューサークライアントとコンシューマークライアントにロードします。設定プロバイダープラグインは、シークレットまたは ConfigMap から設定データを読み込みます。たとえば、Strimzi シークレットから証明書を自動的に取得するようにプロバイダーに指示できます。詳細は、OpenShift での実行に関する Streams for Apache Kafka ドキュメント を参照してください。

Kafka クラスターはシンプルな認可を使用します。認可プロパティーのタイプは simple に設定されています。すべてのリスナーに対する無制限のアクセスのために、単一のスーパーユーザーが定義されています。Streams for Apache Kafka は、Kafka SimpleAclAuthorizer およびカスタムオーソライザープラグインをサポートしています。

これは単なる設定例です。一部の設定オプションはリスナーのタイプに固有です。OAuth 2.0 または Open Policy Agent (OPA) を使用している場合は、特定のリスナーで認可サーバーまたは OPA サーバーへのアクセスを設定する必要もあります。特定の要件と環境に基づいてリスナーを作成できます。

リスナー設定の詳細は、GenericKafkaListener スキーマリファレンス を参照してください。

注記

OpenShift 上の Kafka クラスターへのクライアントアクセスに route タイプリスナーを使用する場合は、TLS パススルー機能が有効になります。OpenShift ルートは HTTP プロトコルで動作するように設計されていますが、Apache Kafka で使用される Kafka プロトコルなど、他のプロトコルのネットワークトラフィックをプロキシーするために使用することもできます。クライアントはルートへの接続を確立し、ルートは TLS Server Name Indication (SNI) 拡張機能を使用して OpenShift クラスター内で実行されているブローカーにトラフィックを転送し、ターゲットのホスト名を取得します。SNI 拡張により、ルートは各接続のターゲットブローカーを正しく識別できるようになります。

ACL を使用してアクセスを微調整する

アクセス制御リスト (ACL) を使用して、Kafka クラスターへのアクセスを微調整できます。アクセス制御リスト (ACL) を追加するには、KafkaUser カスタムリソースを設定します。KafkaUser を作成すると、Streams for Apache Kafka が自動的に作成を管理し、ACL を更新します。ACL は、アクセスルールをクライアントアプリケーションに適用します。

次の例では、最初の ACL は、my-topic という名前の特定のトピックに対する読み取り権限と説明権限を付与します。resource.patternType は literal に設定されます。これは、リソース名が正確に一致する必要があることを意味します。

2 番目の ACL は、my-group という名前の特定のコンシューマーグループに読み取り権限を付与します。resource.patternType は prefix に設定されます。これは、リソース名が接頭辞と一致する必要があることを意味します。

KafkaUser リソースの ACL 設定例

Copy to Clipboard Toggle word wrap 
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operations:
          - Read
          - Describe
      - resource:
          type: group
          name: my-group
          patternType: prefix
        operations:
          - Read

注記

Kafka ユーザーを設定するときに認証オプションとして tls-external を指定すると、User Operator によって生成されたクライアント証明書ではなく、独自のクライアント証明書を使用できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.