第15章 Kafka へのアクセスのセキュア化


クライアントが Kafka ブローカーに対して持つアクセスを管理することで、Kafka クラスターを保護します。Kafka ブローカーとクライアント間のセキュアな接続には、次のものが含まれます。

  • データ交換の暗号化
  • アイデンティティー証明に使用する認証
  • ユーザーが実行するアクションを許可または拒否する認可

Streams for Apache Kafka では、接続を保護するためにリスナーとユーザーアカウントを設定する必要があります。

リスナーの設定

Kafka リソースを使用して、Kafka ブローカーへのクライアント接続用のリスナーを設定します。リスナーは、mTLS、SCRAM-SHA-512、OAuth 2.0、またはカスタム認証方法の使用など、クライアントの認証方法を定義します。セキュリティーを強化するには、TLS 暗号化を設定して Kafka ブローカーとクライアント間の通信を保護します。Kafka ブローカー設定でサポートされている TLS バージョンと暗号スイートを指定することで、TLS ベースの通信をさらにセキュリティー保護できます。

保護層を追加するには、Kafka リソースを使用して、シンプル、OAuth 2.0、OPA、カスタム認証などの Kafka クラスターの認証方法を指定します。

ユーザーアカウント

Streams for Apache Kafka の KafkaUser リソースを使用してユーザーアカウントと認証情報を設定します。ユーザーはクライアントを表し、Kafka クラスターで認証および認可する方法を決定します。ユーザー設定で指定された認証および認可メカニズムは、Kafka 設定と一致する必要があります。さらに、アクセス制御リスト (ACL) を定義して、特定のトピックおよびアクションへのユーザーアクセスを制御し、よりきめ細かい承認を実現します。セキュリティーをさらに強化するには、ユーザークォータを指定して、バイトレートまたは CPU 使用率に基づいて Kafka ブローカーへのクライアントアクセスを制限します。

使用する TLS バージョンと暗号スイートを制限する場合は、クライアントにプロデューサー設定またはコンシューマー設定を追加することもできます。クライアントの設定では、ブローカーで有効になっているプロトコルと暗号スイートのみを使用する必要があります。

注記

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

Streams for Apache Kafka の Operator が、設定プロセスを自動化し、認証に必要な証明書を作成します。Cluster Operator は、クラスター内のデータ暗号化と認証に対して TLS 証明書を自動設定します。

15.1. Kafka のセキュリティーオプション

Kafka リソースを使用して、Kafka の認証および認可に使用されるメカニズムを設定します。

15.1.1. リスナー認証

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

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

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

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

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

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

注記

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

図15.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) 用に予約されているポートを使用するようにリスナーを設定できません。

リスナー認証の設定例

Copy to Clipboard Toggle word wrap
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
# ...

15.1.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 サーバーのアイデンティティーの証明を取得します。

15.1.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 文字と数字で構成されるランダムな 12 文字のパスワードを生成します。

15.1.1.3. ネットワークポリシー

Streams for Apache Kafka では、デフォルトで、Kafka ブローカーで有効になっているすべてのリスナーに対して NetworkPolicy リソースが自動的に作成されます。この NetworkPolicy により、アプリケーションはすべての namespace のリスナーに接続できます。リスナー設定の一部としてネットワークポリシーを使用します。

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

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

注記

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

15.1.1.4. リスナー証明書の提供

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

15.1.2. Kafka の承認

Kafka リソースの Kafka.spec.kafka.authorization プロパティーを使用して、Kafka ブローカーの承認を設定します。authorization プロパティーがないと、承認が有効になりず、クライアントには制限がありません。認可を有効にすると、認可は有効なすべてのリスナーに適用されます。承認方法は type フィールドで定義されます。

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

図15.2 Kafka クラスター承認オプション

kafka 承認設定のオプション

15.1.2.1. スーパーユーザー

スーパーユーザーは、アクセスの制限に関係なく Kafka クラスターのすべてのリソースにアクセスでき、すべての承認メカニズムでサポートされます。

Kafka クラスターのスーパーユーザーを指定するには、superUsers プロパティーにユーザープリンシパルのリストを追加します。ユーザーが mTLS 認証を使用する場合、ユーザー名は CN= で始まる TLS 証明書サブジェクトの共通名です。User Operator を使用せず、mTLS に独自の証明書を使用している場合、ユーザー名は完全な証明書サブジェクトです。完全な証明書サブジェクトには次のフィールドを含めることができます。CN=user,OU=my_ou,O=my_org,L=my_location,ST=my_state,C=my_country_code存在しないフィールドは省略します。

スーパーユーザーを使用した設定例

Copy to Clipboard Toggle word wrap
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
  namespace: myproject
spec:
  kafka:
    # ...
    authorization:
      type: simple
      superUsers:
        - CN=client_1
        - user_2
        - CN=client_3
        - CN=client_4,OU=my_ou,O=my_org,L=my_location,ST=my_state,C=US
        - CN=client_5,OU=my_ou,O=my_org,C=GB
        - CN=client_6,O=my_org
    # ...

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.