第4章 Kafka へのセキュアなアクセスの管理
各クライアントの Kafka ブローカーへのアクセスを管理することで、Kafka クラスターを保護できます。
Kafka ブローカーとクライアント間のセキュアな接続には、以下が含まれます。
- データ交換の暗号化
- アイデンティティー証明に使用する認証
- ユーザーが実行するアクションを許可または拒否する承認
本章では、以下を取り上げ、Kafka ブローカーとクライアント間でセキュアな接続を設定する方法を説明します。
- Kafka クラスターおよびクライアントのセキュリティーオプション
- Kafka ブローカーをセキュアにする方法
- OAuth 2.0 トークンベースの認証および承認に承認サーバーを使用する方法
4.1. Kafka のセキュリティーオプション
Kafka リソースを使用して、Kafka の認証および承認に使用されるメカニズムを設定します。
4.1.1. リスナー認証
OpenShift クラスター内のクライアントの場合は、plain （暗号化なし）または tls internal リスナーを作成できます。
OpenShift クラスター外のクライアントの場合は、external リスナーを作成し、nodeport、loadbalancer、ingress、または route （OpenShift 上）などの接続メカニズムを指定します。
外部クライアントを接続するための設定オプションの詳細は、「外部リスナーの設定」を参照してください。
サポートされる認証オプションは次のとおりです。
- 相互 TLS 認証 (TLS による暗号化が有効なリスナーのみ)
- SCRAM-SHA-512 認証
- OAuth 2.0 のトークンベースの認証
選択する認証オプションは、Kafka ブローカーへのクライアントアクセスを認証する方法によって異なります。
図4.1 Kafka リスナーの認証オプション
リスナーの authentication プロパティーは、そのリスナーに固有の認証メカニズムを指定するために使用されます。
authentication プロパティーが指定されていない場合、リスナーはそのリスナー経由で接続するクライアントを認証しません。認証がないと、リスナーではすべての接続が許可されます。
認証は、User Operator を使用して KafkaUsers を管理する場合に設定する必要があります。
以下の例で指定されるものは次のとおりです。
-
SCRAM-SHA-512 認証に設定された
plainリスナー -
相互 TLS 認証を使用する
tlsリスナー -
相互 TLS 認証を使用する
externalリスナー
各リスナーは、Kafka クラスター内で一意の名前およびポートで設定されます。
ブローカー間通信 (9091) およびメトリクス (9404) 用に確保されたポートを使用するようにリスナーを設定することはできません。
リスナー認証設定の例
# ...
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
# ...
4.1.1.1. 相互 TLS 認証
相互 TLS 認証は、Kafka ブローカーと ZooKeeper Pod 間の通信で常に使用されます。
AMQ Streams では、Kafka が TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、Kafka ブローカーとクライアントとの間で暗号化された通信が行われるよう設定できます。相互 (双方向) 認証の場合、サーバーとクライアントの両方が証明書を提示します。相互認証を設定すると、ブローカーはクライアントを認証し (クライアント認証)、クライアントはブローカーを認証します (サーバー認証)。
TLS 認証は一般的には一方向で、一方が他方のアイデンティティーを認証します。たとえば、Web ブラウザーと Web サーバーの間で HTTPS が使用される場合、ブラウザーは Web サーバーのアイデンティティーの証明を取得します。
4.1.1.2. SCRAM-SHA-512 認証
SCRAM (Salted Challenge Response Authentication Mechanism) は、パスワードを使用して相互認証を確立できる認証プロトコルです。AMQ Streams では、Kafka が SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 を使用するよう設定し、暗号化されていないクライアントの接続と暗号化されたクライアントの接続の両方で認証を提供できます。
TLS クライアント接続で SCRAM-SHA-512 認証が使用される場合、TLS プロトコルは暗号化を提供しますが、認証には使用されません。
SCRAM の以下のプロパティーは、暗号化されていない接続でも SCRAM-SHA-512 を安全に使用できるようにします。
- 通信チャネル上では、パスワードはクリアテキストで送信されません。代わりに、クライアントとサーバーはお互いにチャレンジを生成し、認証するユーザーのパスワードを認識していることを証明します。
- サーバーとクライアントは、認証を交換するたびに新しいチャレンジを生成します。よって、この交換はリレー攻撃に対する回復性を備えています。
KafkaUser.spec.authentication.type を scram-sha-512 に設定すると、User Operator は、大文字と小文字の ASCII 文字と数字で構成されるランダムな 12 文字のパスワードを生成します。
4.1.1.3. ネットワークポリシー
AMQ Streams では、Kafka ブローカーで有効になっているリスナーごとに NetworkPolicy リソースが自動的に作成されます。デフォルトでは、すべてのアプリケーションと namespace にアクセスする権限が NetworkPolicy によってリスナーに付与されます。
ネットワークレベルでのリスナーへのアクセスを指定のアプリケーションまたは namespace のみに制限するには、networkPolicyPeers プロパティーを使用します。
リスナーの認証設定の一部としてネットワークポリシーを使用します。リスナーごとに、異なる networkPolicyPeers 設定を指定できます。
詳細は、「リスナーネットワークポリシー」のセクションおよび 「NetworkPolicyPeer API reference」を参照してください。
AMQ Streams でネットワークポリシーを使用するためには、OpenShift の構成が ingress NetworkPolicies をサポートしている必要があります。
4.1.1.4. 追加のリスナー設定オプション
GenericKafkaListenerConfiguration スキーマのプロパティーを使用して、設定をリスナーに追加できます。
4.1.2. Kafka の承認
Kafka.spec.kafka リソースの authorization プロパティーを使用すると Kafka ブローカーの承認を設定できます。authorization プロパティーがないと、承認が有効になりず、クライアントには制限がありません。承認を有効にすると、承認は有効なすべてのリスナーに適用されます。承認方法は type フィールドで定義されます。
サポートされる承認オプションは次のとおりです。
- 簡易承認
- OAuth 2.0 での承認 (OAuth 2.0 トークンベースの認証を使用している場合)
- Open Policy Agent (OPA) での承認
図4.2 Kafka クラスター承認オプション
4.1.2.1. スーパーユーザー
スーパーユーザーは、アクセスの制限に関係なく Kafka クラスターのすべてのリソースにアクセスでき、すべての承認メカニズムでサポートされます。
Kafka クラスターのスーパーユーザーを指定するには、superUsers プロパティーにユーザープリンシパルのリストを追加します。ユーザーが TLS クライアント認証を使用する場合、ユーザー名は CN= で始まる証明書のサブジェクトの共通名になります。
スーパーユーザーを使用した設定例
authorization:
type: simple
superUsers:
- CN=client_1
- user_2
- CN=client_3
