Confluent for Kubernetes での認可の構成¶

認証がユーザーとアプリケーションの ID を確認するのに対し、認可では、それらのユーザーやアプリケーションが接続後に実行できるアクションを定義できます。

Confluent for Kubernetes でサポートされる認可のメカニズムは次のとおりです。

認可なし
依存関係として LDAP サーバーを使用した Confluent ロールベースアクセス制御（RBAC）による認可

本稼働環境のデプロイでは、Confluent ロールベースアクセス制御（RBAC）の使用をお勧めします。RBAC を使用した場合、本稼働環境のベストプラクティスに準拠するよう、セキュアなセットアップがすべて CFK によって自動化されます。

Confluent ロールベースアクセス制御（RBAC）¶

Confluent for Kubernetes では、ロールベースアクセス制御（RBAC）がサポートされます。RBAC の核となるのは Confluent の Metadata Service（MDS）です。MDS は LDAP サーバーと連携し、認可データと認証データを一元管理する役割を担います。RBAC ではロールバインディングを利用して、特定のリソースにアクセスできるユーザーとグループ、そしてそのリソース（ロール）内で実行できるアクションが決定されます。

Confluent には監査ログが備わっています。ACL および RBAC によって保護されているアクションをユーザーまたはアプリケーションが実行しようとしたときに発生するアクセス許可チェックについて、実行時の決定が監査ログに記録されます。

RBAC は、Confluent コンポーネントが Kafka へのアクセスを認可する際にも使用されます。Confluent コンポーネントが機能するためには一連のプリンシパルとロールバインディングが必要であり、それらは自動化されたデプロイの過程で自動的に生成されます。

注釈

CFK では、新規インストールに対して RBAC を有効にできます。既存のクラスターをアップグレードして、RBAC を有効にすることはできません。

総合セキュリティガイドには、CFK に対する Confluent 用ロールベースアクセス制御（RBAC）のエンドツーエンドのセットアップについて詳しく説明されています。ガイドに記載された CustomResource の仕様と手順は、実際の環境に合わせて調整することをお勧めします。

RBAC を有効にしてデプロイすると、セキュリティのセットアップ全体が Confluent for Kubernetes によって自動化されます。最終的なアーキテクチャの状態は次のとおりです。

LDAP サーバーの要件¶

CFK で RBAC を有効にして使用するための要件は以下のとおりです。

Confluent Platform で認証に使用できる LDAP サーバーが必要です。
Confluent REST API は、RBAC で自動で有効になり、RBAC が有効の場合には無効にできません。

Confluent REST API へのアクセスには Kafka ブートストラップエンドポイント（MDS エンドポイントと同じ）を使用します。
Confluent Platform コンポーネントによって使用されるユーザープリンシパルを LDAP に作成する必要があります。デフォルトのユーザープリンシパルを次に示します。
- Kafka: kafka/kafka-secret
- Confluent REST API: erp/erp-secret
- Confluent Control Center: c3/c3-secret
- ksqlDB: ksql/ksql-secret
- Schema Registry: sr/sr-secret
- Replicator: replicator/replicator-secret
- Connect: connect/connect-secret
Metadata Service (MDS) で他のユーザーに関する LDAP クエリができるよう、LDAP の読み取り専用という最小限のアクセス許可を持つ LDAP ユーザーとパスワードを作成済みです。たとえば、ユーザー mds とパスワード Developer! を作成しました。
LDAP に Confluent REST API 用のユーザーを作成し、ユーザー名とパスワードを指定する必要があります。

Confluent Platform コンポーネントのプリンシパルに対するロールバインディング作成の自動化¶

Confluent for Kubernetes では、Confluent Platform コンポーネントに必要なすべてのロールバインディングを ConfluentRoleBinding カスタムリソース（CR）として自動的に作成します。

Confluent Platform の管理を可能にするための、Confluent Control Center ユーザーへのロール付与¶

Control Center ユーザーには、Control Center UI で表示および管理する Confluent Platform コンポーネントおよびリソースごとに個別のロールが必要です。これから説明するように、ユーザーに明示的なアクセス許可を付与してください。

以降の例では、testadmin プリンシパルが Control Center UI ユーザーとして使用されています。

Confluent Platform コンポーネントを表示および管理するためのアクセス許可の付与¶

必要なアクセス許可は、ロールバインディングの CR 一式をまとめたファイル（https://github.com/confluentinc/confluent-kubernetes-examples/blob/master/security/production-secure-deploy/controlcenter-testadmin-rolebindings.yaml）に示されています。

kubectl apply -f https://raw.githubusercontent.com/confluentinc/confluent-kubernetes-examples/master/security/production-secure-deploy/controlcenter-testadmin-rolebindings.yaml

kubectl get confluentrolebinding
Copy

トラブルシューティング: MDS 構成の確認¶

MDS にログインして、構成が正しいことを確認し、Kafka クラスター ID を取得します。コンポーネントのロールバインディングには Kafka クラスター ID が必要です。

次のコマンドで、https://<kafka_bootstrap_endpoint> を、構成ファイル（ $VALUES_FILE ）で global.dependencies.mds.endpoint に設定した値に置き換えます。

MDS に Kafka スーパーユーザーとしてログインします。次に例を示します。
```
confluent login \
 --url https://<kafka_bootstrap_endpoint> \
 --ca-cert-path <path-to-cacerts.pem>
```
Copy
以下の場合は、--ca-cert-path フラグを渡す必要があります。
- HTTPS トラフィックを処理するよう MDS を構成した場合（kafka.spec.dependencies.mds.tls.enabled: true）。
- MDS 証明書の発行に使用される CA が、コマンドを実行しているシステムから信頼されない場合。
Kafka のユーザー名とパスワードを要求された場合は指定します。この例では kafka と kafka-secret です。

ログイン成功の確認応答があります。

以下のコマンドを実行して、公開リスナーが正しく構成されていることを確認します。

curl -ik \
 -u '<kafka-user>:<kafka-user-password>' \
 https://<kafka_bootstrap_endpoint>/security/1.0/activenodes/https
Copy

以下のいずれかのコマンドを実行して、Kafka クラスター ID を取得します。

confluent cluster describe --url https://<kafka_bootstrap_endpoint>
Copy

curl -ik \
 https://<kafka_bootstrap_endpoint>/v1/metadata/id
Copy