第16章 Kafka クラスターへのアクセスのセキュア化


Kafka と Kafka ユーザーを設定して接続を保護します。設定を通じて、暗号化、認証、認可のメカニズムを実装できます。

Kafka の設定

Kafka へのセキュアなアクセスを確立するには、お客様それぞれの要件に応じて、Kafka リソースを設定して次の設定を指定します。

  • クライアントの認証方法を定義する認証タイプを指定したリスナー

    • Kafka とクライアント間の通信の TLS 暗号化
    • セキュリティー強化のためのサポートされる TLS バージョンと暗号スイート
  • Kafka クラスター全体の認可
  • アクセスを制限するネットワークポリシー
  • ブローカーへのアクセスが制限されないスーパーユーザー

認証はリスナーごとに個別に設定されますが、認可は Kafka クラスター全体に対して設定されます。

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

ユーザー (クライアント側) 設定

Kafka へのセキュアなクライアントアクセスを有効にするには、KafkaUser リソースを設定します。このリソースはクライアントを表し、Kafka クラスターで認証および認可する方法を決定します。

お客様固有の要件に応じて、KafkaUser リソースを設定して次の設定を指定します。

  • 有効なリスナー認証と一致する認証

    • Kafka 設定と一致するサポートされる TLS バージョンと暗号スイート
  • アクセス制御リスト (ACL) ルールを適用するための簡易認可

    • トピックやアクションへのユーザーアクセスをきめ細かく制御するための ACL
  • バイトレートまたは CPU 使用率に基づいてクライアントアクセスを制限するクォータ

User Operator はクライアントに対応するユーザーを作成すると共に、選択した認証タイプに基づいて、クライアント認証に使用されるセキュリティークレデンシャルを作成します。

ユーザーのアクセス設定の詳細は、KafkaUser スキーマリファレンス を参照してください。

16.1. リスナーでのクライアント認証の設定

リスナーの作成時に、Kafka ブローカーのクライアント認証を設定します。Kafka リソースの Kafka.spec.kafka.listeners.authentication プロパティーを使用して、リスナー認証タイプを指定します。

OpenShift クラスター内のクライアントの場合は、plain (暗号化なし) または tls internal リスナーを作成できます。internal リスナータイプは、ヘッドレスサービスと、ブローカー Pod に指定された DNS 名を使用します。ヘッドレスサービスの代わりに、内部リスナーの cluster-ip タイプを作成して、ブローカーごとの ClusterIP サービスを使用して Kafka を公開することもできます。OpenShift クラスターの外部にあるクライアントの場合は、外部 リスナーを作成し、接続メカニズム (nodeportloadbalanceringress (Kubernetes のみ)、または route (OpenShift のみ)) を指定します。

外部クライアントを接続するための設定オプションの詳細は、15章Kafka クラスターへのクライアントアクセスの設定 を参照してください。

サポートされる認証オプションは次のとおりです。

  1. mTLS 認証 (TLS が有効な暗号化を使用するリスナーのみ)
  2. SCRAM-SHA-512 認証
  3. OAuth 2.0 のトークンベースの認証
  4. カスタム認証
  5. TLS バージョンおよび暗号スイート

クライアントアクセス管理に OAuth 2.0 を使用している場合、ユーザーの認証と認可の認証情報は認可サーバーを通じて処理されます。

選択する認証オプションは、Kafka ブローカーへのクライアントアクセスを認証する方法によって異なります。

注記

カスタム認証を使用する前に、標準の認証オプションを試してみてください。カスタム認証では、Kafka でサポートされているあらゆるタイプの認証が可能です。柔軟性を高めることができますが、複雑さも増します。

図16.1 Kafka リスナーの認証オプション

リスナー認証設定のオプション

リスナーの authentication プロパティーは、そのリスナーに固有の認証メカニズムを指定するために使用されます。

authentication プロパティーが指定されていない場合、リスナーはそのリスナー経由で接続するクライアントを認証しません。認証がないと、リスナーではすべての接続が許可されます。

認証は、User Operator を使用して KafkaUsers を管理する場合に設定する必要があります。

以下の例で指定されるものは次のとおりです。

  • SCRAM-SHA-512 認証に設定された plain リスナー
  • mTLS 認証を使用する TLS リスナー
  • mTLS 認証を使用する external リスナー

各リスナーは、Kafka クラスター内で一意の名前およびポートで設定されます。

重要

ブローカーへのクライアントアクセス用にリスナーを設定する場合、いくつかの例外を除き、ポート 9092 以降 (9093、9094 など) を使用できます。ブローカー間通信 (9090 および 9091)、Prometheus メトリック (9404)、および JMX (Java Management Extensions) モニタリング (9999) 用に予約されているポートを使用するようにリスナーを設定できません。

リスナー認証の設定例

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: true
        authentication:
          type: scram-sha-512
      - name: tls
        port: 9093
        type: internal
        tls: true
        authentication:
          type: tls
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: tls
# ...
Copy to Clipboard Toggle word wrap

16.1.1. mTLS 認証

mTLS 認証は、Kafka ブローカーと ZooKeeper Pod 間の通信で常に使用されます。

Streams for Apache Kafka では、TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、Kafka ブローカーとクライアントとの間で暗号化された通信を行うように Kafka を設定できます。相互 (双方向) 認証の場合、サーバーとクライアントの両方が証明書を提示します。mTLS 認証を設定すると、ブローカーはクライアントを認証し (クライアント認証)、クライアントはブローカーを認証します (サーバー認証)。

Kafka リソースの mTLS リスナー設定には、次のものが必要です。

  • TLS 暗号化とサーバー認証を指定する場合は tls: true
  • クライアント認証を指定する場合は authentication.type: tls

Cluster Operator によって Kafka クラスターが作成されると、<cluster_name>-cluster-ca-cert という名前の新しいシークレットが作成されます。シークレットには CA 証明書が含まれています。CA 証明書は PEM および PKCS #12 形式 です。Kafka クラスターを検証するには、CA 証明書をクライアント設定のトラストストアに追加します。クライアントを確認するには、クライアント設定のキーストアにユーザー証明書とキーを追加します。mTLS 用のクライアントの設定の詳細は、「ユーザー認証の設定」 を参照してください。

注記

TLS 認証は一般的には一方向で、一方が他方のアイデンティティーを認証します。たとえば、Web ブラウザーと Web サーバーの間で HTTPS が使用される場合、ブラウザーは Web サーバーのアイデンティティーの証明を取得します。

16.1.2. SCRAM-SHA-512 認証

SCRAM (Salted Challenge Response Authentication Mechanism) は、パスワードを使用して相互認証を確立できる認証プロトコルです。Streams for Apache Kafka では、SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 を使用するように Kafka を設定して、暗号化されていないクライアント接続と暗号化されたクライアント接続の両方で認証を提供できます。

SCRAM-SHA-512 認証が TLS 接続で使用される場合、TLS プロトコルは暗号化を提供しますが、認証には使用されません。

SCRAM の以下のプロパティーは、暗号化されていない接続でも SCRAM-SHA-512 を安全に使用できるようにします。

  • 通信チャネル上では、パスワードはクリアテキストで送信されません。代わりに、クライアントとサーバーはお互いにチャレンジを生成し、認証するユーザーのパスワードを認識していることを証明します。
  • サーバーとクライアントは、認証を交換するたびに新しいチャレンジを生成します。よって、この交換はリレー攻撃に対する回復性を備えています。

KafkaUser.spec.authentication.typescram-sha-512 に設定すると、User Operator が大文字と小文字の ASCII 文字と数字で構成されるランダムな 32 文字のパスワードを生成します。

16.1.3. ネットワークポリシーによるリスナーへのアクセス制限

Kafka リソースの networkPolicyPeers プロパティーを設定して、リスナーアクセスを制御します。

デフォルトでは、Streams for Apache Kafka は、すべての有効な Kafka リスナーに NetworkPolicy リソースを自動的に作成し、すべての namespace からの接続を許可します。

ネットワークレベルで特定のアプリケーションまたは namespace へのリスナーアクセスを制限するには、networkPolicyPeers プロパティーを設定します。各リスナーは独自の networkPolicyPeers 設定 を指定できます。ネットワークポリシーピアの詳細は、NetworkPolicyPeer API reference を参照してください。

カスタムネットワークポリシーを使用する場合は、Cluster Operator 設定で STRIMZI_NETWORK_POLICY_GENERATION 環境変数を false に設定できます。詳細は、「Cluster Operator の設定」 を参照してください。

注記

ネットワークポリシーを使用するには、OpenShift の設定で Ingress NetworkPolicies がサポートされている必要があります。

前提条件

  • Ingress NetworkPolicies をサポートする OpenShift クラスター。
  • Cluster Operator が稼働中である。

手順

  1. networkPolicyPeers プロパティーを設定して、Kafka クラスターへのアクセスを許可するアプリケーション Pod または namespace を定義します。

    この例では、kafka-client に設定されたラベル app を持つアプリケーション Pod からの接続のみを許可する tls リスナーの設定を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: Kafka
    spec:
      kafka:
        # ...
        listeners:
          - name: tls
            port: 9093
            type: internal
            tls: true
            authentication:
              type: tls
            networkPolicyPeers:
              - podSelector:
                  matchLabels:
                    app: kafka-client
        # ...
      zookeeper:
        # ...
    Copy to Clipboard Toggle word wrap
  2. Kafka リソース設定に変更を適用します。

16.1.4. TLS 暗号化にカスタムリスナー証明書を使用する

この手順では、TLS 暗号化が有効な TLS リスナーまたは外部リスナーのカスタムサーバー証明書を設定する方法を示します。

デフォルトでは、Kafka リスナーは Streams for Apache Kafka の内部 CA (認証局) によって署名された証明書を使用します。Kafka クラスターの作成時に、Cluster Operator が CA 証明書を自動的に生成します。TLS 用にクライアントを設定するには、Kafka クラスターを認証するための CA 証明書をそのトラストストア設定に含めます。または、独自の CA 証明書をインストールして使用 することもできます。

一方、リスナーレベルで独自のカスタム証明書を使用してよりきめ細かく制御する場合は、brokerCertChainAndKey プロパティーを使用してリスナーを設定できます。独自の秘密鍵とサーバー証明書を使用してシークレットを作成し、それらを brokerCertChainAndKey 設定で指定します。

ユーザーが提供する証明書を使用すると、既存のセキュリティーインフラストラクチャーを活用できます。パブリック (外部) CA またはプライベート CA によって署名された証明書を使用できます。Kafka クライアントは、リスナー証明書の署名に使用された CA を信頼する必要があります。パブリック CA によって署名されている場合、通常、それをクライアントのトラストストア設定に追加する必要はありません。

カスタム証明書は Streams for Apache Kafka によって管理されないため、手動で更新する必要があります。

注記

リスナー証明書は、TLS 暗号化とサーバー認証のみに使用されます。これらは TLS クライアント認証には使用されません。TLS クライアント認証にも独自の証明書を使用する場合は、独自のクライアント CA をインストールして使用する 必要があります。

前提条件

  • Cluster Operator が稼働中である。
  • 各リスナーには次のものが必要です。

    • 外部 CA によって署名された互換性のあるサーバー証明書。(X.509 証明書を PEM 形式で提供します。)

      複数のリスナーに対して 1 つのリスナー証明書を使用できます。

    • サブジェクト代替名 (SAN) は、各リスナーの証明書で指定されます。詳細は、「カスタムリスナー証明書の SAN の指定」 を参照してください。

自己署名証明書を使用していない場合は、証明書に CA チェーン全体を含む証明書を提供できます。

リスナーに対して TLS 暗号化 (tls: true) が設定されている場合は、brokerCertChainAndKey プロパティーのみを使用できます。

注記

Streams for Apache Kafka では、TLS の暗号化された秘密鍵の使用はサポートされていません。これが機能するには、シークレットに保存されている秘密鍵が暗号化されていない必要があります。

手順

  1. 秘密鍵およびサーバー証明書が含まれる Secret を作成します。

    oc create secret generic <my_secret> --from-file=<my_listener_key.key> --from-file=<my_listener_certificate.crt>
    Copy to Clipboard Toggle word wrap
  2. クラスターの Kafka リソースを編集します。

    Secret、証明書ファイル、および秘密鍵ファイルを使用するように、リスナーを configuration.brokerCertChainAndKey プロパティーで設定します。

    TLS 暗号化が有効な loadbalancer 外部リスナーの設定例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: external3
        port: 9094
        type: loadbalancer
        tls: true
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...
    Copy to Clipboard Toggle word wrap

    TLS リスナーの設定例

    # ...
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
      - name: tls
        port: 9093
        type: internal
        tls: true
        configuration:
          brokerCertChainAndKey:
            secretName: my-secret
            certificate: my-listener-certificate.crt
            key: my-listener-key.key
    # ...
    Copy to Clipboard Toggle word wrap

  3. Kafka リソース設定に変更を適用します。

    Cluster Operator は、Kafka クラスターのローリング更新を開始し、これによりリスナーの設定が更新されます。

    注記

    リスナーによってすでに使用されている Secret の Kafka リスナー証明書を更新した場合でも、ローリング更新が開始されます。

16.1.5. カスタムリスナー証明書の SAN の指定

カスタムの Kafka リスナー証明書 で TLS ホスト名検証を使用するには、各リスナーに正しいサブジェクト代替名 (SAN) を指定する必要があります。

証明書 SAN では、次のホスト名を指定する必要があります。

  • クラスターのすべての Kafka ブローカー
  • Kafka クラスターブートストラップサービス

ワイルドカード証明書は、CA でサポートされれば使用できます。

16.1.5.1. 内部リスナー用の SAN の例

次の例は、内部リスナーの証明書で SAN のホスト名を指定するのに役立ちます。

<cluster-name> を Kafka クラスターの名前に置き換え、<namespace> をクラスターが実行されている OpenShift namespace に置き換えます。

type: internal リスナーのワイルドカードの例

//Kafka brokers
*.<cluster_name>-kafka-brokers
*.<cluster_name>-kafka-brokers.<namespace>.svc

// Bootstrap service
<cluster_name>-kafka-bootstrap
<cluster_name>-kafka-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

type: internal リスナーのワイルドカード以外の例

// Kafka brokers
<cluster_name>-kafka-0.<cluster_name>-kafka-brokers
<cluster_name>-kafka-0.<cluster_name>-kafka-brokers.<namespace>.svc
<cluster_name>-kafka-1.<cluster_name>-kafka-brokers
<cluster_name>-kafka-1.<cluster_name>-kafka-brokers.<namespace>.svc
# ...

// Bootstrap service
<cluster_name>-kafka-bootstrap
<cluster_name>-kafka-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

type: cluster-ip リスナーのワイルドカード以外の例

// Kafka brokers
<cluster_name>-kafka-<listener-name>-0
<cluster_name>-kafka-<listener-name>-0.<namespace>.svc
<cluster_name>-kafka-_listener-name>-1
<cluster_name>-kafka-<listener-name>-1.<namespace>.svc
# ...

// Bootstrap service
<cluster_name>-kafka-<listener-name>-bootstrap
<cluster_name>-kafka-<listener-name>-bootstrap.<namespace>.svc
Copy to Clipboard Toggle word wrap

16.1.5.2. 外部リスナー用の SAN の例

TLS 暗号化が有効になっている外部リスナーの場合、証明書に指定する必要があるホスト名は、外部リスナーの type によって異なります。

Expand
表16.1 外部リスナー各タイプの SAN
外部リスナータイプSAN で指定する内容

ingress

すべての Kafka ブローカー Ingress リソースのアドレスとブートストラップ Ingress のアドレス。

一致するワイルドカード名を使用できます。

route

すべての Kafka ブローカー Routes のアドレス、およびブートストラップ Route のアドレス。

一致するワイルドカード名を使用できます。

loadbalancer

すべての Kafka ブローカー loadbalancers のアドレス、およびブートストラップ loadbalancer のアドレス。

一致するワイルドカード名を使用できます。

nodeport

Kafka ブローカー Pod がスケジュールされるすべての OpenShift ワーカーノードのアドレス。

一致するワイルドカード名を使用できます。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2026 Red Hat
トップに戻る