第6章 User Operator の使用
KafkaUser リソースを使用してユーザーを作成、編集、または削除する場合、User Operator によって変更が確実に Kafka クラスターで反映されます。
6.1. Kafka ユーザーリソース リンクのコピーリンクがクリップボードにコピーされました!
KafkaUser リソースを使用して、ユーザーの認証メカニズム、承認メカニズム、およびアクセス権限を設定します。
KafkaUser の完全なスキーマは、KafkaUser スキーマ参照 で確認できます。
6.1.1. ユーザー認証 リンクのコピーリンクがクリップボードにコピーされました!
認証は、KafkaUser.spec の authentication プロパティーを使用して設定されます。ユーザーに有効な認証メカニズムは、type フィールドを使用して指定されます。
サポートされる認証メカニズム
- TLS クライアント認証
- SCRAM-SHA-512 認証
認証メカニズムを指定しないと、User Operator によってユーザーまたはそのクレデンシャルが作成されません。
6.1.1.1. TLS クライアント認証 リンクのコピーリンクがクリップボードにコピーされました!
TLS クライアント認証を使用するには、type フィールドを tls に設定します。
TLS クライアント認証が有効になっている KafkaUser の例
ユーザーが User Operator によって作成されると、KafkaUser リソースと同じ名前で新しい Secret が作成されます。Secret には、TLS クライアント認証の秘密鍵と公開鍵が含まれます。公開鍵は、クライアント認証局 (CA) によって署名されたユーザー証明書に含まれます。
すべての鍵は X.509 形式です。
Secret には、PEM 形式および PKCS #12 形式の秘密鍵と証明書が含まれます。Kafka と Secret との通信をセキュアにする方法については、12章セキュリティー を参照してください。
ユーザークレデンシャルのある Secret の例
6.1.1.2. SCRAM-SHA-512 認証 リンクのコピーリンクがクリップボードにコピーされました!
SCRAM-SHA-512 認証メカニズムを使用するには、type フィールドを scram-sha-512 に設定します。
SCRAM-SHA-512 認証が有効になっている KafkaUser の例
ユーザーが User Operator によって作成されると、KafkaUser リソースと同じ名前で新しいシークレットが作成されます。シークレットの password キーには、生成されたパスワードが含まれ、base64 でエンコードされます。パスワードを使用するにはデコードする必要があります。
ユーザークレデンシャルのある Secret の例
生成されたパスワードをデコードします。
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode
6.1.2. ユーザーの承認 リンクのコピーリンクがクリップボードにコピーされました!
ユーザーの承認は、KafkaUser.spec の authorization プロパティーを使用して設定されます。ユーザーに有効な承認タイプは、type フィールドを使用して指定します。
承認が指定されていない場合は、User Operator によるユーザーのアクセス権限のプロビジョニングは行われません。
簡易承認を使用するには、KafkaUser.spec で type プロパティーを simple に設定します。簡易承認では、デフォルトの Kafka 承認プラグインである SimpleAclAuthorizer が使用されます。
また、OAuth 2.0 トークンベースの認証を使用している場合、OAuth 2.0 承認を設定する こともできます。
ACL ルール
SimpleAclAuthorizer は、ACL ルールを使用して Kafka ブローカーへのアクセスを管理します。
ACL ルールによって、acls プロパティーで指定したユーザーにアクセス権限が付与されます。
AclRule はプロパティーのセットとして指定されます。
resourceresourceプロパティーで、ルールが適用されるリソースを指定します。簡易承認は、
typeプロパティーに指定される、以下の 4 つのリソースタイプをサポートします。-
トピック (
topic) -
コンシューマーグループ (
group) -
クラスター (
cluster) -
トランザクション ID (
transactionalId)
Topic、Group、および Transactional ID リソースでは、
nameプロパティーでルールが適用されるリソースの名前を指定できます。クラスタータイプのリソースには名前がありません。
名前は、
patternTypeプロパティーを使用してliteralまたはprefixとして指定されます。-
リテラル (literal) 名には、
nameフィールドに指定された名前がそのまま使われます。 -
接頭辞 (prefix) 名には、
nameからの値が接頭辞として使用され、その値で始まる名前を持つすべてのリソースにルールが適用されます。
-
トピック (
typetypeプロパティーは ACL ルールのタイプであるallowまたはdenyを指定します。typeフィールドの設定は任意です。typeの指定がない場合、ACL ルールはallowルールとして処理されます。operationoperationは、許可または拒否する操作を指定します。以下の操作がサポートされます。
- Read
- Write
- Delete
- Alter
- Describe
- All
- IdempotentWrite
- ClusterAction
- Create
- AlterConfigs
- DescribeConfigs
特定の操作のみが各リソースで機能します。
SimpleAclAuthorizer、ACL、およびサポートされるリソースと操作の組み合わせの詳細は、Authorization and ACL を参照してください。hosthostプロパティーは、ルールを許可または拒否するリモートホストを指定します。アスタリスク (
*) を使用して、すべてのホストからの操作を許可または拒否します。hostフィールドの設定は任意です。hostを指定しないと、値*がデフォルトで使用されます。
AclRule オブジェクトの詳細は、AclRule スキーマ参照 を参照してください。
承認をともなう KafkaUser の例
6.1.2.1. Kafka ブローカーへのスーパーユーザーアクセス リンクのコピーリンクがクリップボードにコピーされました!
ユーザーを Kafka ブローカー設定のスーパーユーザーのリストに追加すると、ACL で定義された承認制約に関係なく、そのユーザーにはクラスターへのアクセスが無制限に許可されます。
スーパーユーザーの設定に関する詳細は、Kafka ブローカーの 認証および承認 を参照してください。
6.1.3. ユーザークォータ リンクのコピーリンクがクリップボードにコピーされました!
KafkaUser リソースの spec を設定してクォータを強制し、バイトしきい値または CPU 使用の時間制限に基づいてユーザーが Kafka ブローカーへのアクセスを超過しないようにすることができます。
ユーザークォータをともなう KafkaUser の例
これらのプロパティーの詳細は、KafkaUserQuotas スキーマ参照 を参照してください。