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
matchesKafkaUser.spec.authentication
-
Kafka.spec.kafka.authorization
はKafkaUser.spec.authorization
と一致します。
この手順では、mTLS 認証を使用した簡易承認とリスナーの設定を説明します。リスナー設定の詳細は、GenericKafkaListener
スキーマリファレンス を参照してください。
代わりに、リスナー認証 には SCRAM-SHA または OAuth 2.0、Kafka 認可 には OAuth 2.0 または OPA を使用することができます。
手順
Kafka
リソースを設定します。-
承認には
authorization
プロパティーを設定します。 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 として指定 できます。
外部リスナーを設定している場合、設定は選択した接続のメカニズムによって異なります。
-
承認には
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.authentication
はKafka.spec.kafka.listeners[*].authentication
と一致します。 -
KafkaUser.spec.authorization
はKafka.spec.kafka.authorization
と一致します。
この手順は、mTLS 認証を使用してユーザーを作成する方法を示しています。SCRAM-SHA 認証でユーザーを作成することも可能です。
必要な認証は、Kafka ブローカーリスナーに設定された認証のタイプ によって異なります。
Kafka ユーザーと Kafka ブローカー間の認証は、それぞれの認証設定によって異なります。たとえば、mTLS が Kafka 設定で有効になっていない場合は、mTLS でユーザーを認証できません。
前提条件
- mTLS 認証と TLS 暗号化を使用する Kafka ブローカーリスナーで設定された 実行中の Kafka クラスター。
- 実行中の User Operator (通常は Entity Operator とともにデプロイされます)。
KafkaUser
の認証タイプは、Kafka
ブローカーに設定された認証と一致する必要があります。
手順
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
KafkaUser
リソースを作成または更新します。oc apply -f <user_config_file>
KafkaUser
リソースと同じ名前の Secret と共に、ユーザーが作成されます。Secret には、mTLS 認証用の秘密鍵と公開鍵が含まれています。
Kafka ブローカーへのセキュアな接続のためのプロパティーを使用して Kafka クライアントを設定する方法については、「リスナーを使用した Kafka クラスターへのクライアントアクセス設定」 を参照してください。
15.3.3. ネットワークポリシーを使用した Kafka リスナーへのアクセス制限
networkPolicyPeers
プロパティーを使用すると、リスナーへのアクセスを指定のアプリケーションのみに制限できます。
前提条件
- Ingress NetworkPolicies をサポートする OpenShift クラスター。
- Cluster Operator が稼働中である。
手順
-
Kafka
リソースを開きます。 networkPolicyPeers
プロパティーで、Kafka クラスターへのアクセスが許可されるアプリケーション Pod または namespace を定義します。以下は、ラベル
app
がkafka-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: # ...
リソースを作成または更新します。
次のように
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 の暗号化された秘密鍵の使用はサポートされていません。これが機能するには、シークレットに保存されている秘密鍵が暗号化されていない必要があります。
手順
秘密鍵およびサーバー証明書が含まれる
Secret
を作成します。oc create secret generic my-secret --from-file=my-listener-key.key --from-file=my-listener-certificate.crt
クラスターの
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 # ...
新しい設定を適用してリソースを作成または更新します。
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
によって異なります。
外部リスナータイプ | SAN で指定する内容 |
---|---|
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
|
すべての Kafka ブローカー 一致するワイルドカード名を使用できます。 |
| Kafka ブローカー Pod がスケジュールされるすべての OpenShift ワーカーノードのアドレス。 一致するワイルドカード名を使用できます。 |