15.2. Kafka クライアントのセキュリティーオプション

KafkaUser リソースを使用して、Kafka クライアントの認証メカニズム、認可メカニズム、およびアクセス権限を設定します。セキュリティーの設定では、クライアントはユーザーとして表されます。

Kafka ブローカーへのユーザーアクセスを認証および承認できます。認証によってアクセスが許可され、認可によって許容されるアクションへのアクセスが制限されます。

Kafka ブローカーへのアクセスが制限されない スーパーユーザー を作成することもできます。

認証および認可メカニズムは、Kafka ブローカーへのアクセスに使用されるリスナーの仕様と一致する必要があります。

Kafka ブローカーにセキュアにアクセスするための KafkaUser リソースの設定の詳細については、「リスナーを使用した Kafka クラスターへのクライアントアクセス設定」を参照してください。

15.2.1. ユーザー処理用の Kafka クラスターの特定

KafkaUser リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka リソースの名前から派生) を定義するラベルが含まれています。

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster

このラベルは、KafkaUser リソースを特定し、新しいユーザーを作成するために、User Operator によって使用されます。また、以降のユーザーの処理でも使用されます。

ラベルが Kafka クラスターと一致しない場合、User Operator は KafkaUser を識別できず、ユーザーは作成されません。

KafkaUser リソースの状態が空のままの場合は、ラベルを確認します。

15.2.2. ユーザー認証

KafkaUser カスタムリソースを使用して、Kafka クラスターへのアクセスを必要とするユーザー (クライアント) の認証情報を設定します。KafkaUser.spec の authentication プロパティーを使用して認証情報を設定します。type を指定することで、生成される認証情報を制御します。

サポートされる認証タイプ

mTLS 認証用の tls
外部証明書を使用した mTLS 認証用の tls-external
scram-sha-512(SCRAM-SHA-512 認証用)

tls または scram-sha-512 が指定された場合、User Operator がユーザーを作成する際に、認証用のクレデンシャルを作成します。tls-external が指定されている場合、ユーザーは引き続き mTLS を使用しますが、認証情報は作成されません。独自の証明書を指定する場合は、このオプションを使用します。認証タイプが指定されていない場合、User Operator はユーザーまたはそのクレデンシャルを作成しません。

tls-external を使用して、User Operator の外部で発行された証明書を使用して mTLS で認証できます。User Operator は TLS 証明書またはシークレットを生成しません。tls メカニズムを使用する場合と同様に、User Operator を使用して ACL ルールおよびクォータを管理できます。これは、ACL ルールおよびクォータを指定する際に CN=USER-NAME 形式を使用することを意味します。USER-NAME は、TLS 証明書で指定したコモンネームです。

15.2.2.1. mTLS 認証

mTLS 認証を使用するには、KafkaUser リソースの type フィールドを tls に設定します。

mTLS 認証が有効になっているユーザーの例

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

認証タイプは、Kafka クラスターへのアクセスに使用される Kafka リスナーの同等の設定と一致する必要があります。

ユーザーが User Operator によって作成されると、KafkaUser リソースと同じ名前で新しいシークレットが作成されます。シークレットには、mTLS の秘密鍵と公開鍵が含まれています。公開鍵はユーザー証明書に含まれており、作成時にクライアント CA (認証局) によって署名されます。すべての鍵は X.509 形式です。

注記

Cluster Operator によって生成されたクライアント CA を使用している場合、Cluster Operator によってクライアント CA が更新されると、User Operator によって生成されたユーザー証明書も更新されます。

ユーザーシークレットは、キーと証明書を PEM および PKCS #12 形式で提供します。

ユーザー認証情報を含むシークレットの例

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> # Public key of the clients CA
  user.crt: <user_certificate> # Public key of the user
  user.key: <user_private_key> # Private key of the user
  user.p12: <store> # PKCS #12 store for user certificates and keys
  user.password: <password_for_store> # Protects the PKCS #12 store

クライアントを設定するときは、次を指定します。

Kafka クラスターの ID を検証するためのパブリッククラスター CA 証明書の トラストストア プロパティー
クライアントを検証するためのユーザー認証クレデンシャルの キーストア プロパティー

設定は、ファイル形式 (PEM または PKCS #12) によって異なります。この例では、PKCS #12 ストアと、ストア内の認証情報にアクセスするために必要なパスワードを使用しています。

PKCS #12 形式の mTLS を使用したクライアント設定の例

bootstrap.servers=<kafka_cluster_name>-kafka-bootstrap:9093 1
security.protocol=SSL 2
ssl.truststore.location=/tmp/ca.p12 3
ssl.truststore.password=<truststore_password> 4
ssl.keystore.location=/tmp/user.p12 5
ssl.keystore.password=<keystore_password> 6

1: Kafka クラスターに接続するためのブートストラップサーバーアドレス。
2: 暗号化に TLS を使用する場合のセキュリティープロトコルオプション。
3: トラストストアの場所には、Kafka クラスターの公開鍵証明書 (ca.p12) が含まれます。クラスター CA 証明書とパスワードは、Kafka クラスターの作成時に <cluster_name>-cluster-ca-cert シークレットで Cluster Operator によって生成されます。
4: トラストストアにアクセスするためのパスワード (ca.password)。
5: キーストアの場所には、Kafka ユーザーの公開鍵証明書 (user.p12) が含まれます。
6: キーストアにアクセスするためのパスワード (user.password)。

15.2.2.2. User Operator の外部で発行された証明書を使用した mTLS 認証

User Operator の外部で発行された証明書を使用して mTLS 認証を使用するには、KafkaUser リソースの type フィールドを tls-external に設定します。シークレットおよび認証情報はユーザー用には作成されません。

User Operator 以外で発行された証明書を使用する mTLS 認証を使用するユーザーの例

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

15.2.2.3. SCRAM-SHA-512 認証

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

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

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

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

ユーザー認証情報を含むシークレットの例

apiVersion: v1
kind: Secret
metadata:
  name: my-user
  labels:
    strimzi.io/kind: KafkaUser
    strimzi.io/cluster: my-cluster
type: Opaque
data:
  password: Z2VuZXJhdGVkcGFzc3dvcmQ= 1
  sasl.jaas.config: b3JnLmFwYWNoZS5rYWZrYS5jb21tb24uc2VjdXJpdHkuc2NyYW0uU2NyYW1Mb2dpbk1vZHVsZSByZXF1aXJlZCB1c2VybmFtZT0ibXktdXNlciIgcGFzc3dvcmQ9ImdlbmVyYXRlZHBhc3N3b3JkIjsK 2

1: base64 でエンコードされた生成されたパスワード。
2: base64 でエンコードされた SASL SCRAM-SHA-512 認証の JAAS 設定文字列。

生成されたパスワードをデコードします。

echo "Z2VuZXJhdGVkcGFzc3dvcmQ=" | base64 --decode

15.2.2.3.1. カスタムパスワード設定

ユーザーが作成されると、Streams for Apache Kafka によってランダムなパスワードが生成されます。Streams for Apache Kafka によって生成されたパスワードの代わりに、独自のパスワードを使用できます。これを行うには、パスワードでシークレットを作成し、KafkaUser リソースでこれを参照します。

SCRAM-SHA-512 認証に設定されたパスワードを持つユーザーの例

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaUser
metadata:
  name: my-user
  labels:
    strimzi.io/cluster: my-cluster
spec:
  authentication:
    type: scram-sha-512
    password:
      valueFrom:
        secretKeyRef:
          name: my-secret 1
          key: my-password 2
  # ...

1: 事前に定義されたパスワードが含まれるシークレットの名前。
2: シークレット内に格納されているパスワードのキー。

15.2.3. ユーザーの承認

KafkaUser カスタムリソースを使用して、Kafka クラスターへのアクセスを必要とするユーザー (クライアント) の承認規則を設定します。KafkaUser.spec の authorization プロパティーを使用してルールを設定します。type を指定することで、使用するルールを制御します。

簡易承認を使用するには、KafkaUser.spec.authorization で type プロパティーを simple に設定します。簡易承認は、Kafka Admin API を使用して Kafka クラスター内で ACL ルールを管理します。User Operator の ACL 管理が有効であるかどうかは、Kafka クラスターの承認設定によって異なります。

簡易承認では、ACL 管理が常に有効になります。
OPA 承認の場合、ACL 管理は常に無効になります。承認ルールは OPA サーバーで設定されます。
Red Hat Single Sign-On の承認では、Red Hat Single Sign-On で ACL ルールを直接管理できます。設定のフォールバックオプションとして、承認を簡単なオーソライザーに委譲することもできます。簡単なオーソライザーへの委譲が有効になっている場合、User Operator は ACL ルールの管理も有効にします。
カスタム承認プラグインを使用したカスタム承認では、Kafka カスタムリソースの .spec.kafka.authorization 設定の supportsAdminApi プロパティーを使用して、サポートを有効または無効にする必要があります。

承認はクラスター全体です。認可タイプは、Kafka カスタムリソースの同等の設定と一致する必要があります。

ACL 管理が有効になっていない場合、Streams for Apache Kafka は、ACL ルールが含まれているリソースを拒否します。

User Operator のスタンドアロンデプロイメントを使用している場合、ACL 管理はデフォルトで有効にされます。STRIMZI_ACLS_ADMIN_API_SUPPORTED 環境変数を使用してこれを無効にすることができます。

承認が指定されていない場合は、User Operator によるユーザーのアクセス権限のプロビジョニングは行われません。このような KafkaUser がリソースにアクセスできるかどうかは、使用されているオーソライザーによって異なります。たとえば、simple 認可の場合、これは Kafka クラスターの allow.everyone.if.no.acl.found 設定によって決定されます。

15.2.3.1. ACL ルール

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

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

AclRule オブジェクトの詳細は、AclRule スキーマリファレンスを参照してください。

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

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

ブローカーへのスーパーユーザーアクセスの設定に関する詳細は Kafka の承認を参照してください。

15.2.3.3. ユーザークォータ

KafkaUser リソースの spec を設定してクォータを強制し、ユーザーが Kafka ブローカーへの設定されたアクセスレベルを超えないようにします。サイズベースのネットワーク使用量と時間ベースの CPU 使用率のしきい値を設定できます。また、パーティション mutation (変更) クォータを追加して、ユーザー要求に対して受け入れられるパーティション変更のリクエストのレートを制御することもできます。

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

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

1: ユーザーが Kafka ブローカーにプッシュできるデータ量の、秒あたりのバイトクォータ。
2: ユーザーが Kafka ブローカーからフェッチできるデータ量の、秒あたりのバイトクォータ。
3: クライアントグループあたりの時間割合で示される、CPU 使用制限。
4: 1 秒あたり許容される同時パーティション作成および削除操作 (mutations) の数

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

15.2. Kafka クライアントのセキュリティーオプション

15.2.1. ユーザー処理用の Kafka クラスターの特定

15.2.2. ユーザー認証

15.2.2.1. mTLS 認証

15.2.2.2. User Operator の外部で発行された証明書を使用した mTLS 認証

15.2.2.3. SCRAM-SHA-512 認証

15.2.2.3.1. カスタムパスワード設定

15.2.3. ユーザーの承認

15.2.3.1. ACL ルール

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

15.2.3.3. ユーザークォータ

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links