15.3. Kafka ブローカーへのアクセスのセキュア化


Kafka ブローカーへのセキュアなアクセスを確立するには、以下を設定し、適用します。

  • 以下を行う Kafka リソース。

    • 指定された認証タイプでリスナーを作成します。
    • Kafka クラスター全体の承認を設定します。
  • Kafka ブローカーにリスナー経由でセキュアにアクセスするための KafkaUser リソース。

Kafka リソースを設定して以下を設定します。

  • リスナー認証
  • Kafka リスナーへのアクセスを制限するネットワークポリシー
  • Kafka の承認
  • ブローカーへのアクセスが制限されないスーパーユーザー

認証は、リスナーごとに独立して設定されます。承認は、常に Kafka クラスター全体に対して設定されます。

Cluster Operator はリスナーを作成し、クラスターおよびクライアント認証局 (CA) 証明書を設定して Kafka クラスター内で認証を有効にします。

独自の証明書をインストール することで、Cluster Operator によって生成された証明書を置き換えることができます。

TLS 暗号化が有効になっているリスナーに対して独自のサーバー証明書と秘密鍵を提供することもできます。これらのユーザー提供による証明書は、Kafka リスナー証明書 と呼ばれます。Kafka リスナー証明書を提供すると、組織のプライベート CA やパブリック CA などの既存のセキュリティーインフラストラクチャーを利用できます。Kafka クライアントは、リスナー証明書の署名に使用された CA を信頼する必要があります。Kafka リスナー証明書の更新が必要な場合は、手作業で更新する必要があります。PKCS #12 形式 (.p12) および PEM 形式 (.crt) の証明書を利用できます。

KafkaUser を使用して、特定のクライアントが Kafka にアクセスするために使用する認証および認可メカニズムを有効にします。

KafkaUser リソースを設定して以下を設定します。

  • 有効なリスナー認証と一致する認証
  • 有効な Kafka 承認と一致する承認
  • クライアントによるリソースの使用を制御するクォータ

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

アクセス設定プロパティーの詳細は、次のスキーマリファレンスを参照してください。

15.3.1. Kafka ブローカーのセキュア化

この手順では、Streams for Apache Kafka を実行するときに Kafka ブローカーを保護するために必要な手順を示します。

Kafka ブローカーに実装されたセキュリティーは、アクセスを必要とするクライアントに実装されたセキュリティーとの互換性を維持する必要があります。

  • Kafka.spec.kafka.listeners[*].authentication matches KafkaUser.spec.authentication
  • Kafka.spec.kafka.authorizationKafkaUser.spec.authorization と一致します。

この手順では、mTLS 認証を使用した簡易承認とリスナーの設定を説明します。リスナー設定の詳細は、GenericKafkaListener スキーマリファレンス を参照してください。

代わりに、リスナー認証 には SCRAM-SHA または OAuth 2.0、Kafka 認可 には OAuth 2.0 または OPA を使用することができます。

手順

  1. Kafka リソースを設定します。

    1. 承認には authorization プロパティーを設定します。
    2. listeners プロパティーを設定し、認証でリスナーを作成します。

      以下に例を示します。

      apiVersion: kafka.strimzi.io/v1beta2
      kind: Kafka
      spec:
        kafka:
          # ...
          authorization: 1
            type: simple
            superUsers: 2
              - CN=client_1
              - user_2
              - CN=client_3
          listeners:
            - name: tls
              port: 9093
              type: internal
              tls: true
              authentication:
                type: tls 3
          # ...
        zookeeper:
          # ...
      1
      2
      Kafka へのアクセスを制限されないユーザープリンシパルのリスト。CN は、mTLS による認証が使用される場合のクライアント証明書のコモンネームです。
      3
      リスナーの認証メカニズムは各リスナーに対して設定でき、mTLS、SCRAM-SHA-512、またはトークンベース OAuth 2.0 として指定 できます。

      外部リスナーを設定している場合、設定は選択した接続のメカニズムによって異なります。

  2. Kafka リソースを作成または更新します。

    oc apply -f <kafka_configuration_file>

    Kafka クラスターは、mTLS 認証を使用する Kafka ブローカーリスナーと共に設定されます。

    Kafka ブローカー Pod ごとにサービスが作成されます。

    サービスが作成され、Kafka クラスターに接続するための ブートストラップアドレス として機能します。

    kafka ブローカーのアイデンティティーを検証するクラスター CA 証明書もシークレット <cluster_name>-cluster-ca-cert に作成されます。

15.3.2. Kafka へのユーザーアクセスのセキュア化

KafkaUser を作成または変更して、Kafka クラスターへのセキュアなアクセスを必要とするクライアントを表します。

KafkaUser 認証および認可メカニズムを設定する場合、必ず同等の Kafka 設定と一致するようにしてください。

  • KafkaUser.spec.authenticationKafka.spec.kafka.listeners[*].authentication と一致します。
  • KafkaUser.spec.authorizationKafka.spec.kafka.authorization と一致します。

この手順は、mTLS 認証を使用してユーザーを作成する方法を示しています。SCRAM-SHA 認証でユーザーを作成することも可能です。

必要な認証は、Kafka ブローカーリスナーに設定された認証のタイプ によって異なります。

注記

Kafka ユーザーと Kafka ブローカー間の認証は、それぞれの認証設定によって異なります。たとえば、mTLS が Kafka 設定で有効になっていない場合は、mTLS でユーザーを認証できません。

前提条件

KafkaUser の認証タイプは、Kafka ブローカーに設定された認証と一致する必要があります。

手順

  1. KafkaUser リソースを設定します。

    以下に例を示します。

    apiVersion: kafka.strimzi.io/v1beta2
    kind: KafkaUser
    metadata:
      name: my-user
      labels:
        strimzi.io/cluster: my-cluster
    spec:
      authentication: 1
        type: tls
      authorization:
        type: simple 2
        acls:
          - resource:
              type: topic
              name: my-topic
              patternType: literal
            operations:
              - Describe
              - Read
          - resource:
              type: group
              name: my-group
              patternType: literal
            operations:
              - Read
    1
    相互 tls または scram-sha-512 として定義されたユーザー認証メカニズム。
    2
    ACL ルールのリストが必要な簡易承認。
  2. KafkaUser リソースを作成または更新します。

    oc apply -f <user_config_file>

    KafkaUser リソースと同じ名前の Secret と共に、ユーザーが作成されます。Secret には、mTLS 認証用の秘密鍵と公開鍵が含まれています。

Kafka ブローカーへのセキュアな接続のためのプロパティーを使用して Kafka クライアントを設定する方法については、「リスナーを使用した Kafka クラスターへのクライアントアクセス設定」 を参照してください。

15.3.3. ネットワークポリシーを使用した Kafka リスナーへのアクセス制限

networkPolicyPeers プロパティーを使用すると、リスナーへのアクセスを指定のアプリケーションのみに制限できます。

前提条件

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

手順

  1. Kafka リソースを開きます。
  2. networkPolicyPeers プロパティーで、Kafka クラスターへのアクセスが許可されるアプリケーション Pod または namespace を定義します。

    以下は、ラベル appkafka-client に設定されているアプリケーションからの接続のみを許可するよう 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:
        # ...
  3. リソースを作成または更新します。

    次のように oc apply を使用します。

    oc apply -f your-file

15.3.4. TLS 暗号化用の独自の Kafka リスナー証明書を提供する

リスナーは、Kafka ブローカーへのクライアントアクセスを提供します。TLS を使用したクライアントアクセスに必要な設定を含め、Kafka リソースでリスナーを設定します。

デフォルトでは、リスナーは Streams for Apache Kafka によって生成された内部 CA (認証局) 証明書によって署名された証明書を使用します。CA 証明書は、Kafka クラスターを作成するときに Cluster Operator によって生成されます。クライアントを TLS 用に設定するときは、CA 証明書をそのトラストストア設定に追加して、Kafka クラスターを検証します。独自の CA 証明書をインストールして使用する こともできます。または、brokerCertChainAndKey プロパティーを使用してリスナーを設定し、カスタムサーバー証明書を使用することもできます。

brokerCertChainAndKey プロパティーを使用すると、リスナーレベルで独自のカスタム証明書を使用して Kafka ブローカーにアクセスできます。独自のプライベートキーとサーバー証明書を使用してシークレットを作成し、リスナーの brokerCertChainAndKey 設定でキーと証明書を指定します。パブリック (外部) CA またはプライベート CA によって署名された証明書を使用できます。パブリック CA によって署名されている場合、通常、それをクライアントのトラストストア設定に追加する必要はありません。カスタム証明書は Streams for Apache Kafka によって管理されないため、手動で更新する必要があります。

注記

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

前提条件

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

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

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

    • サブジェクト代替名 (SAN) は、各リスナーの証明書で指定されます。詳細は、「Kafka リスナーのサーバー証明書の 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
  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
    # ...

    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
    # ...

  3. 新しい設定を適用してリソースを作成または更新します。

    oc apply -f kafka.yaml

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

    注記

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

15.3.5. Kafka リスナーのサーバー証明書の SAN

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

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

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

15.3.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

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

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

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

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

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

© 2024 Red Hat, Inc.