第6章 Kafka のセキュリティー
AMQ Streams のセキュアなデプロイメントには、以下が含めることができます。
- データ交換の暗号化
- アイデンティティー証明に使用する認証
- ユーザーが実行するアクションを許可または拒否する認可
6.1. 暗号化
AMQ Streams は、暗号化通信用のプロトコルである Transport Layer Security (TLS) をサポートします。
通信は、以下の間で常に暗号化されます。
- Kafka ブローカー
- ZooKeeper ノード
- Operator および Kafka ブローカー
- Operator および ZooKeeper ノード
- Kafka Exporter
また、Kafka ブローカーのリスナーに TLS 暗号化を適用して、Kafka ブローカーとクライアント間で TLS を設定することもできます。外部リスナーの設定時に外部クライアントに TLS を指定します。
AMQ Streams コンポーネントおよび Kafka クライアントは、暗号化にデジタル署名を使用します。Cluster Operator は、証明書を設定し、Kafka クラスター内で暗号化を有効にします。Kafka クライアントと Kafka ブローカーの通信やクラスター間の通信に、Kafka リスナー証明書と呼ばれる独自のサーバー証明書を指定できます。
AMQ Streams は シークレット を使用して、TLS に必要な証明書および秘密鍵を PEM および PKCS #12 形式で保存します。
TLS 認証局 (CA) は、証明書を発行してコンポーネントのアイデンティティーを認証します。AMQ Streams は、CA 証明書に対してコンポーネントの証明書を検証します。
- AMQ Streams コンポーネントは、クラスター CA 証明局 (CA) に対して検証されます。
- Kafka クライアントは クライアント CA 証明局 (CA) に対して検証されます。
6.2. 認証
Kafka リスナーは認証を使用して、Kafka クラスターへのクライアント接続のセキュリティーを確保します。
サポート対象の認証メカニズム:
- 相互 TLS クライアント認証 (TLS 暗号化が有効なリスナーの場合)
- SASL SCRAM-SHA-512
- OAuth 2.0 のトークンベースの認証
User Operator では TLS および SCRAM 認証のユーザー認証情報は管理対象ですが、OAuth 2.0 は管理対象ではありません。たとえば、User Operator を使用して、Kafka クラスターにアクセスする必要があるクライアントに対応するユーザーを作成し、認証タイプとして TLS を指定できます。
OAuth 2.0 トークンベースの認証を使用すると、アプリケーションクライアントは、アカウント認証情報を公開せずに Kafka ブローカーにアクセスできます。承認サーバーは、アクセスの付与とアクセスに関する問い合わせを処理します。
6.3. 承認
Kafka クラスターは、承認メカニズムを使用して特定のクライアントまたはユーザーによって Kafka ブローカーで許可される操作を制御します。承認は、Kafka クラスターに適用されると、クライアント接続に使用する全リスナーに対して有効になります。
ユーザーを Kafka ブローカー設定の スーパーユーザー のリストに追加すると、承認メカニズムにより適用される承認制約に関係なく、そのユーザーにはクラスターへのアクセスが無制限に許可されます。
サポート対象の承認メカニズム:
- 簡易承認
- OAuth 2.0 での承認 (OAuth 2.0 トークンベースの認証を使用している場合)
- Open Policy Agent (OPA) での承認
簡易承認では、デフォルトの Kafka 承認プラグインである AclAuthorizer
が使用されます。AclAuthorizer
は、アクセス制御リスト (ACL) を使用して、どのユーザーがどのリソースにアクセスできるかを定義します。
OAuth 2.0 および OPA は、承認サーバーからのポリシーベースの制御を提供します。Kafka ブローカーのリソースへのアクセス権限を付与するのに使用されるセキュリティーポリシーおよびパーミッションは、承認サーバーで定義されます。
承認サーバーに接続し、クライアントまたはユーザーがリクエストした操作が許可または拒否されることを検証するのに、URL が使用されます。ユーザーとクライアントは、承認サーバーで作成されるポリシーと照合され、Kafka ブローカーで特定のアクションを実行するためのアクセスが許可されます。