第6章 Kafka へのセキュアなアクセスの管理


各クライアントの Kafka ブローカーへのアクセスを管理することで、Kafka クラスターを保護できます。

Kafka ブローカーとクライアント間のセキュアな接続には、以下が含まれます。

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

本章では、以下を取り上げ、Kafka ブローカーとクライアント間でセキュアな接続を設定する方法を説明します。

  • Kafka クラスターおよびクライアントのセキュリティーオプション
  • Kafka ブローカーをセキュアにする方法
  • OAuth 2.0 トークンベースの認証および承認に承認サーバーを使用する方法

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

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

6.1.1. リスナー認証

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

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

注記

ブローカー間通信 (9091 または 9090) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。

リスナー認証の設定例

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: external
        port: 9094
        type: loadbalancer
        tls: true
        authentication:
          type: tls
# ...
Copy to Clipboard Toggle word wrap

6.1.1.1. mTLS 認証

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

AMQ Streams では、Kafka が TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、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 サーバーのアイデンティティーの証明を取得します。

6.1.1.2. SCRAM-SHA-512 認証

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

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

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

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

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

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

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

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

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

注記

AMQ Streams でネットワークポリシーを使用するためには、OpenShift の設定が ingress NetworkPolicies をサポートしている必要があります。

6.1.1.4. 追加のリスナー設定オプション

GenericKafkaListenerConfiguration スキーマのプロパティーを使用して、設定をリスナーに追加できます。

6.1.2. Kafka の承認

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

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

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

6.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存在しないフィールドは省略します。

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

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat