第6章 User Operator の使用

User Operator は、OpenShift リソースより Kafka ユーザーを管理する方法を提供します。

6.1. User Operator

User Operator は、Kafka ユーザーが記述される KafkaUser リソースを監視して Kafka クラスターの Kafka ユーザーを管理し、Kafka ユーザーが Kafka クラスターで適切に設定されるようにします。

たとえば、KafkaUser とユーザーの関係は次のようになります。

KafkaUser が作成されると、User Operator によって記述されるユーザーが作成されます。
KafkaUser が削除されると、User Operator によって記述されるユーザーが削除されます。
KafkaUser が変更されると、User Operator によって記述されるユーザーが更新されます。

User Operator は Topic Operator とは異なり、Kafka クラスターからの変更は OpenShift リソースと同期されません。アプリケーションで直接 Kafka トピックを Kafka で作成することは可能ですが、ユーザーが User Operator と同時に直接 Kafka クラスターで管理されることは想定されません。

User Operator では、アプリケーションのデプロイメントの一部として KafkaUser リソースを宣言できます。ユーザーの認証および承認メカニズムを指定できます。たとえば、ユーザーがブローカーへのアクセスを独占しないようにするため、Kafka リソースの使用を制御する ユーザークォータ を設定することもできます。

ユーザーが作成されると、ユーザークレデンシャルが Secret に作成されます。アプリケーションはユーザーとそのクレデンシャルを使用して、認証やメッセージの生成または消費を行う必要があります。

User Operator は認証のクレデンシャルを管理する他に、KafkaUser 宣言にユーザーのアクセス権限の記述を含めることで承認も管理します。

6.2. 相互 TLS 認証

相互 TLS 認証は、Kafka ブローカーと ZooKeeper Pod 間の通信で常に使用されます。

相互認証または双方向認証は、サーバーとクライアントの両方が証明書を提示するときに使用されます。AMQ Streams では、Kafka が TLS (Transport Layer Security) を使用して、相互認証の有無を問わず、Kafka ブローカーとクライアントとの間で暗号化された通信が行われるよう設定できます。相互認証を設定する場合、ブローカーによってクライアントが認証され、クライアントによってブローカーが認証されます。

注記

TLS 認証は一般的には一方向で、一方が他方のアイデンティティーを認証します。たとえば、Web ブラウザーと Web サーバーの間で HTTPS が使用される場合、サーバーはブラウザーのアイデンティティーの証明を取得します。

6.2.1. クライアントに相互 TLS 認証を使用する場合

以下の場合、Kafka クライアントの認証に相互 TLS 認証が推奨されます。

相互 TLS 認証を使用した認証がクライアントでサポートされる場合。
パスワードの代わりに TLS 証明書を使用する必要がある場合。
期限切れの証明書を使用しないように、クライアントアプリケーションを定期的に再設定および再起動できる場合。

6.3. 相互 TLS 認証を使用した Kafka ユーザーの作成

前提条件

TLS 認証を使用してリスナーで設定された稼働中の Kafka クラスターが必要です。
稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。

手順

作成する KafkaUser が含まれる YAML ファイルを準備します。

KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Read
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Describe
      - resource:
          type: group
          name: my-group
          patternType: literal
        operation: Read

OpenShift で KafkaUser リソースを作成します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
アプリケーションで、my-user シークレットからのクレデンシャルを使用します。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
TLS を使用して認証するリスナーの設定に関する詳細は、「Kafka ブローカーリスナー」を参照してください。
Entity Operator のデプロイメントに関する詳細は、「Entitiy Operator」を参照してください。
KafkaUser オブジェクトの詳細は、「KafkaUser スキーマ参照」を参照してください。

6.4. SCRAM-SHA 認証

SCRAM (Salted Challenge Response Authentication Mechanism) は、パスワードを使用して相互認証を確立できる認証プロトコルです。AMQ Streams では、Kafka が SASL (Simple Authentication and Security Layer) SCRAM-SHA-512 を使用するよう設定し、暗号化されていないクライアントの接続と TLS で暗号化されたクライアントの接続の両方で認証を提供できます。TLS 認証は、Kafka ブローカーと ZooKeeper ノードの間で常に内部で使用されます。TLS クライアント接続で TLS プロトコルを使用すると、接続が暗号化されますが、認証には使用されません。

SCRAM の以下のプロパティーは、暗号化されていない接続でも SCRAM-SHA を安全に使用できるようにします。

通信チャネル上では、パスワードはクリアテキストで送信されません。代わりに、クライアントとサーバーはお互いにチャレンジを生成し、認証するユーザーのパスワードを認識していることを証明します。
サーバーとクライアントは、認証を交換するたびに新しいチャレンジを生成します。よって、交換はリレー攻撃に対して回復性を備えています。

6.4.1. サポートされる SCRAM クレデンシャル

AMQ Streams では SCRAM-SHA-512 のみがサポートされます。KafkaUser.spec.authentication.type を scram-sha-512 に設定すると、User Operator によって、大文字と小文字の ASCII 文字と数字で構成された無作為の 12 文字のパスワードが生成されます。

6.4.2. クライアントに SCRAM-SHA 認証を使用する場合

以下の場合、Kafka クライアントの認証に SCRAM-SHA が推奨されます。

SCRAM-SHA-512 を使用した認証がクライアントでサポートされる場合。
TLS 証明書の代わりにパスワードを使用する必要がある場合。
暗号化されていない通信に認証が必要な場合。

6.5. SCRAM SHA 認証を使用した Kafka ユーザーの作成

前提条件

SCRAM SHA 認証を使用してリスナーで設定された稼働中の Kafka クラスターが必要です。
稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。

手順

作成する KafkaUser が含まれる YAML ファイルを準備します。

KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Read
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Describe
      - resource:
          type: group
          name: my-group
          patternType: literal
        operation: Read

OpenShift で KafkaUser リソースを作成します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
アプリケーションで、my-user シークレットからのクレデンシャルを使用します。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
SCRAM SHA を使用して認証するリスナーの設定に関する詳細は、「Kafka ブローカーリスナー」を参照してください。
Entity Operator のデプロイメントに関する詳細は、「Entitiy Operator」を参照してください。
KafkaUser オブジェクトの詳細は、「KafkaUser スキーマ参照」を参照してください。

6.6. Kafka ユーザーの編集

この手順では、KafkaUser OpenShift リソースを使用して既存の Kafka ユーザーの設定を変更する方法を説明します。

前提条件

稼働中の Kafka クラスターが必要です。
稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。
変更する既存の KafkaUser。

手順

必要な KafkaUser が含まれる YAML ファイルを準備します。

KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Read
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Describe
      - resource:
          type: group
          name: my-group
          patternType: literal
        operation: Read

OpenShift で KafkaUser リソースを更新します。
oc apply を使用してこれを行うことができます。
```
oc apply -f your-file
```
my-user シークレットからの更新済みのクレデンシャルをアプリケーションで使用します。

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
Entity Operator のデプロイメントに関する詳細は、「Entitiy Operator」を参照してください。
KafkaUser オブジェクトの詳細は、「KafkaUser スキーマ参照」を参照してください。

6.7. Kafka ユーザーの削除

この手順では、KafkaUser OpenShift リソースで作成した Kafka ユーザーを削除する方法を説明します。

前提条件

稼働中の Kafka クラスターが必要です。
稼働中の User Operator (通常は Entity Operator でデプロイされる) が必要です。
削除する既存の KafkaUser。

手順

OpenShift で KafkaUser リソースを削除します。
oc delete を使用してこれを行うことができます。
```
oc delete kafkauser your-user-name
```

その他のリソース

Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」を参照してください。
KafkaUser オブジェクトの詳細は、「KafkaUser スキーマ参照」を参照してください。

6.8. Kafka User リソース

KafkaUser リソースを使用して、ユーザーの認証メカニズム、承認メカニズム、およびアクセス権限を設定します。

KafkaUser の完全なスキーマは、「KafkaUser スキーマ参照」で確認できます。

6.8.1. 認証

認証は、KafkaUser.spec の authentication プロパティーを使用して設定されます。ユーザーに有効な認証メカニズムは、type フィールドを使用して指定されます。現在、サポートされる唯一の認証メカニズムは、TLS クライアント認証メカニズムと SCRAM-SHA-512 メカニズムです。

認証メカニズムを指定しないと、User Operator によってユーザーまたはそのクレデンシャルが作成されません。

その他のリソース

6.8.1.1. TLS クライアント認証

TLS クライアント認証を使用するには、type フィールドを tls に設定します。

TLS クライアント認証が有効になっている KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: tls
  # ...

ユーザーが User Operator によって作成されると、User Operator は KafkaUser リソースと同じ名前で新規シークレットを作成します。シークレットには、TLS クライアント認証に使用する必要のある公開鍵および秘密鍵が含まれます。ユーザー証明書の署名に使用されたクライアント認証局の公開キーがバンドルされます。すべてのキーは X509 形式になります。

ユーザークレデンシャルのある Secret の例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  ca.crt: # Public key of the Clients CA
  user.crt: # Public key of the user
  user.key: # Private key of the user

6.8.1.2. SCRAM-SHA-512 認証

SCRAM-SHA-512 認証メカニズムを使用するには、type フィールドを scram-sha-512 に設定します。

SCRAM-SHA-512 認証が有効になっている KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
  # ...

ユーザーが User Operator によって作成されると、User Operator は KafkaUser リソースと同じ名前で新規シークレットを作成します。シークレットの password キーには、生成されたパスワードが含まれ、base64 でエンコードされます。パスワードを使用するにはデコードする必要があります。

ユーザークレデンシャルのある Secret の例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  password: Z2VuZXJhdGVkcGFzc3dvcmQ= # Generated password

生成されたパスワードは次のようにデコードします。

echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode

6.8.2. 承認

簡易承認は、KafkaUser.spec の authorization プロパティーを使用して設定されます。ユーザーに有効な承認タイプは、type フィールドを使用して指定します。

承認が指定されていない場合は、User Operator によるユーザーのアクセス権限のプロビジョニングは行われません。

さらに、OAuth 2.0 トークンベースの認証を使用している場合、OAuth 2.0 承認を設定することもできます。

6.8.2.1. 簡易承認

簡易承認では、デフォルトの Kafka 承認プラグインである SimpleAclAuthorizer が使用されます。

簡易承認を使用するには、KafkaUser.spec で type プロパティーを simple に設定します。

ACL ルール

SimpleAclAuthorizer は、ACL ルールを使用して Kafka ブローカーへのアクセスを管理します。

ACL ルールによって、acls プロパティーで指定したユーザーにアクセス権限が付与されます。

AclRule はプロパティーのセットとして指定されます。

resource

resource プロパティーで、ルールが適用されるリソースを指定します。

簡易承認は、type プロパティーに指定される、以下の 4 つのリソースタイプをサポートします。

トピック (topic)
コンシューマーグループ (group)
クラスター (cluster)
トランザクション ID (transactionalId)

Topic、Group、および Transactional ID リソースでは、name プロパティーでルールが適用されるリソースの名前を指定できます。

クラスタータイプのリソースには名前がありません。

名前は、patternType プロパティーを使用して literal または prefix として指定されます。

リテラル (literal) 名には、name フィールドに指定された名前がそのまま使われます。
接頭辞 (prefix) 名には、name からの値が接頭辞として使用され、その値で始まる名前を持つすべてのリソースにルールが適用されます。

type

type プロパティーは ACL ルールのタイプである allow または deny を指定します。

type フィールドの設定は任意です。type の指定がない場合、ACL ルールは allow ルールとして処理されます。

operation

operation は、許可または拒否する操作を指定します。

以下の操作がサポートされます。

Read
Write
Delete
Alter
Describe
All
IdempotentWrite
ClusterAction
Create
AlterConfigs
DescribeConfigs

特定の操作のみが各リソースで機能します。

SimpleAclAuthorizer、ACL、およびサポートされるリソースと操作の組み合わせの詳細は、「Authorization and ACL」を参照してください。

host

host プロパティーは、ルールを許可または拒否するリモートホストを指定します。

アスタリスク (*) を使用して、すべてのホストからの操作を許可または拒否します。host フィールドの設定は任意です。host を指定しないと、値 * がデフォルトで使用されます。

AclRule オブジェクトの詳細は、「AclRule スキーマ参照」を参照してください。

承認をともなう KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  authorization:
    type: simple
    acls:
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Read
      - resource:
          type: topic
          name: my-topic
          patternType: literal
        operation: Describe
      - resource:
          type: group
          name: my-group
          patternType: prefix
        operation: Read

6.8.2.2. Kafka ブローカーへのスーパーユーザーアクセス

ユーザーを Kafka ブローカー設定のスーパーユーザーのリストに追加すると、ACL で定義された承認制約に関係なく、そのユーザーにはクラスターへのアクセスが無制限に許可されます。

スーパーユーザーの設定に関する詳細は、Kafka ブローカーの「認証および承認」を参照してください。

6.8.3. ユーザークォータ

KafkaUser リソースの spec を設定してクォータを強制し、バイトしきい値または CPU 使用の時間制限に基づいてユーザーが Kafka ブローカーへのアクセスを超過しないようにすることができます。

ユーザークォータをともなう KafkaUser の例

apiVersion: kafka.strimzi.io/v1beta1
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  # ...
  quotas:
    producerByteRate: 1048576 1
    consumerByteRate: 2097152 2
    requestPercentage: 55 3

1: ユーザーが Kafka ブローカーにプッシュできるデータ量の、秒あたりのバイトクォータ。
2: ユーザーが Kafka ブローカーからフェッチできるデータ量の、秒あたりのバイトクォータ。
3: クライアントグループあたりの時間割合で示される、CPU 使用制限。

これらのプロパティーの詳細は、「KafkaUserQuotas スキーマ参照」を参照してください。

第6章 User Operator の使用

6.1. User Operator

6.2. 相互 TLS 認証

6.2.1. クライアントに相互 TLS 認証を使用する場合

6.3. 相互 TLS 認証を使用した Kafka ユーザーの作成

6.4. SCRAM-SHA 認証

6.4.1. サポートされる SCRAM クレデンシャル

6.4.2. クライアントに SCRAM-SHA 認証を使用する場合

6.5. SCRAM SHA 認証を使用した Kafka ユーザーの作成

6.6. Kafka ユーザーの編集

6.7. Kafka ユーザーの削除

6.8. Kafka User リソース

6.8.1. 認証

6.8.1.1. TLS クライアント認証

6.8.1.2. SCRAM-SHA-512 認証

6.8.2. 承認

6.8.2.1. 簡易承認

6.8.2.2. Kafka ブローカーへのスーパーユーザーアクセス

6.8.3. ユーザークォータ

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links