Confluent Metadata API リファレンス¶
Confluent Metadata API には多くのエンドポイントがあり、概念的に次のようにグループ化されています。
認証
LDAP に対してユーザーを認証し、Confluent Platform 内の他の MDS エンドポイントおよびコンポーネントで使用できるユーザーベアラートークンを返します（そのように構成されている場合）。
認可
特定のアクションの実行をユーザーに認可します。これらのエンドポイントは、ユーザーアクションを認可するために Confluent Platform コンポーネント（Connect や ksqlDB など）によって使用されるものであり、クライアントによる使用は想定されていません。
ロールベースアクセス制御
- ロールバインディングの CRUD
- ロールバインディングの概要（Confluent CLI が使用）
- 高レベルのロールバインディング管理とロールアップ（Confluent Control Center が使用）
一元的な ACL 制御
- Confluent Platform では、 一元的な ACL を使用した認可 により、ZooKeeper ではなく Kafka に ACL を保存できます。
- 従来の Kafka で一元管理されている MDS ベースの ACL に対する ACL の CRUD
監査ログ構成
ログにどのようなイベントが記録され、それらの監査ログイベントがどこに送信されるかを管理する構成。クラスターレジストリと連携し、構成の変更を Kafka クラスターにプッシュします。
クラスターレジストリ
CP コンポーネント/クラスターの追跡と命名。
- 管理者によって手動で入力および更新されます。
- 監査ログ構成によって活用されます。
- RBAC API によって活用され、RoleBinding 呼び出しで、（クラスター ID ではなく）クラスターの "わかりやすい名前" の使用を許可します。
注釈
これまでクラスター ID を指定する必要があったどの RBAC CRUD API でも、クラスターレジストリにクラスターが登録済みであれば、代わりに clusterName を使用することができます。ただし、次の制限を遵守する必要があります。
clusterNameと``clusters`` の両方ではなく、どちらか一方を使用します。clustersを使用する場合、kafka-clusterが常に必要となります。もう一方のクラスタータイプには一意の ID がないためです。
アクセス制限¶
認証されたユーザーが呼び出すことができるエンドポイントもあれば、管理者のみが呼び出すことができるエンドポイントもあります。さらに、API のエンドポイントの多くには、エンドポイントを呼び出しているユーザー（"呼び出し元" プリンシパル）と API 呼び出しの対象となるユーザー（"ターゲット" プリンシパル）の 2 人のユーザーが関与します。
例: UserAdmin ロールを持ち、HTTP 基本認証情報またはベアラートークンによって識別されるユーザー "alice" は、CRUD のエンドポイントを呼び出して、ユーザー "bob" に関するロールバインディングを変更します。
各エンドポイントのアクセス制限について文書化するには、以下の凡例を使用します。アクセスの制限が最も緩やかなものから最も限定的なものの順にリストされています。
- LDAP
- すべての認証済み LDAP ユーザー
- Admins+User
- 自分自身に関する情報をリクエストする管理者またはユーザー
- Admins+ResourceOwners
- ResourceOwner ロールが付与された管理者またはユーザー
- Admins+AclUsers
- 必要な ACL アクセス許可を持つ管理者またはユーザー
- Admins
- 管理者のみ（UserAdmin、SystemAdmin、ブローカーの super.user、または "Read" として指定された SecurityAdmin）
応答の概要¶
有効な応答
- 200: 呼び出しに成功しました（メッセージボディあり）。
- 204: 呼び出しに成功しました（メッセージボディなし）。
エラー
- 400: 無効なリクエスト。JSON 解析エラー、またはその他の正しくないリクエスト。
- 401: 認証されていません。有効な HTTP 基本認証の認証情報またはユーザーベアラートークンを渡す必要があります。
- 403: 認可されていません。有効なリクエストですが、リクエストされたアクションの実行が認可されていません。
- 404: 無効な URL。認証エンドポイントからこのエラーが発生した場合は、構成でベアラートークン認証を有効にする必要があることを意味します（
confluent.metadata.server.authentication.method=BEARER） - 405: メソッドが許可されていません。有効なエンドポイントで、正しくない HTTP メソッドが使用されています（POST の代わりに GET が使用されているなど）。
- 409: 矛盾。既存の状態との矛盾が生じる形で、新しいリソースの追加や既存のリソースの更新を実行しようとしています。
- このエラーは、監査ログ API およびクラスターレジストリ API によってスローされる可能性があります。
- 415: 無効なコンテンツタイプ。通常は、リクエストボディのヘッダーとして "application/json" が指定された結果。
- 500: サーバーエラー。
特殊なリソースタイプ¶
クラスターと Ksql クラスターは、ResourceOwner や DeveloperManage などのリソーススコープ付きロールにクラスターレベルの操作（Kafka クラスターに対する Describe Configs など）への制限付きアクセスを許可するため、特殊なリソースタイプです。これらの特殊なリソースタイプは、それぞれ値 kafka-cluster および ksql-cluster の LITERAL パターンのみを受け入れます。
API の詳細¶
Metadata Service には、OpenAPI 仕様が付属しています。その確認や操作には、組み込みの Swagger UI を使用します。
組み込みの Swagger UI を有効にするには、Metadata Service を構成する際に、ブローカーの構成でプロパティ confluent.metadata.server.openapi.enable=true を指定します。
これにより、ブローカーで Swagger UI を http://<host> :<port>/security/openapi/swagger-ui/index.html として利用できるようになります。
注釈
MDS がリッスンしているポートと同じポートを Swagger UI ポートとして指定します（デフォルトは 8090）。
警告
Swagger UI と Open API 仕様ファイルは、開発とテストの目的でのみ提供されています。このため、次の点に注意してください。
- 本稼働環境では有効にしないでください。
- Swagger UI は HTTP のみと連携できます。
プライベート RBAC UI エンドポイント¶
これらのエンドポイントは、Confluent Control Center の UI を強化するために特別に開発されました。そのため、該当するユースケースにのみ焦点を当てて、Confluent Control Center のコンテキストのみでテストされています。手動の API 呼び出しに関しては、これらのエンドポイントはテストされておらず、ユーザビリティも評価されていません。
API エンドポイント¶
トークンと認証¶
-
GET/security/1.0/authenticate¶ ベアラートークンを取得します。
LDAP ユーザーによる呼び出しが可能です。
リクエストの例:
GET /security/1.0/authenticate HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
認証されました
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "auth_token": "string", "token_type": "string", "expires_in": 1.0 }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
認可¶
-
PUT/security/1.0/authorize¶ 特定のユーザーに、resourceType に対する操作を認可します。
Admins+User による呼び出しが可能です。
リクエストの例:
PUT /security/1.0/authorize HTTP/1.1 Host: example.com Content-Type: application/json { "userPrincipal": "User:bob", "actions": [ { "scope": { "clusters": { "kafka-cluster": "K_GUID" } }, "resourceName": "clicksTopic1", "resourceType": "Topic", "operation": "Read" } ] }
ステータスコード: - 200 OK --
認可が処理されました
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "ALLOWED", "DENIED" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
Metadata Service の操作¶
-
GET/security/1.0/activenodes/{protocol}¶ Metadata Service REST API を実行しているすべてのノードを返します。
クライアントは、Metadata Service ノードの前にロードバランサーをセットアップしない場合、これらのエンドポイントへのラウンドロビン呼び出しを行う必要があります。
LDAP ユーザーによる呼び出しが可能です。
パラメーター: - protocol (string) -- "http" または "https" を指定します。
リクエストの例:
GET /security/1.0/activenodes/{protocol} HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
Metadata Service を実行している他のノードのリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "http://10.10.10.50:8090", "http://10.10.10.51:8090" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
RBAC - ロールの定義¶
-
GET/security/1.0/roles¶ システムで定義されているすべてのロールを返します。
情報提供および開発者による使用が目的です。
LDAP ユーザーによる呼び出しが可能です。
リクエストの例:
GET /security/1.0/roles HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
resourceType と許可された操作を含むロールのリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "name": "string", "accessPolicy": { "scopeType": "string", "allowedOperations": [ { "resourceType": "string", "operations": [ "string" ] } ] } } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
-
GET/security/1.0/roles/{roleName}¶ 特定のロールの resourceType と許可されている操作をリストします。
LDAP ユーザーによる呼び出しが可能です。
パラメーター: - roleName (string) -- 検索するロール名。
リクエストの例:
GET /security/1.0/roles/{roleName} HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
単一ロール。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "name": "string", "accessPolicy": { "scopeType": "string", "allowedOperations": [ { "resourceType": "string", "operations": [ "string" ] } ] } }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
GET/security/1.0/roleNames¶ システムで定義されているすべてのロールの名前を返します。
情報提供および開発者による使用が目的です。
LDAP ユーザーによる呼び出しが可能です。
リクエストの例:
GET /security/1.0/roleNames HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
システムで定義されているロールの名前。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "string" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
RBAC - RoleBinding の CRUD¶
-
POST/security/1.0/principals/{principal}/roles/{roleName}¶ 特定のクラスターまたは指定されたスコープについて、クラスタースコープが指定されたロールにプリンシパルをバインドします。
Admins による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ユーザーのバインド対象となる、クラスタースコープが指定されたロールの名前。
リクエストの例:
POST /security/1.0/principals/{principal}/roles/{roleName} HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 204 No Content -- ロールが付与されました
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
DELETE/security/1.0/principals/{principal}/roles/{roleName}¶ 指定されたスコープ/クラスターのプリンシパルから（クラスターまたはリソーススコープが指定された）ロールを削除します。
ユーザーにそのロールが割り当てられていない場合、処理は行われません。
Admins による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ロールの名前。
リクエストの例:
DELETE /security/1.0/principals/{principal}/roles/{roleName} HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 204 No Content -- ロールが削除されました。
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/principals/{principal}/roles/{roleName}/resources¶ 指定されたロールを使用して、指定されたスコープ/クラスターのプリンシパルのロールバインディングを検索します。
Admins による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ロールの名前。
リクエストの例:
POST /security/1.0/principals/{principal}/roles/{roleName}/resources HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
許可されました
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "resourceType": "Topic", "name": "clicksTopic1", "patternType": "LITERAL" }, { "resourceType": "Topic", "name": "orders-2019", "patternType": "PREFIXED" } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/principals/{principal}/roles/{roleName}/bindings¶ 指定されたロールを使用して、指定されたスコープ/クラスターのプリンシパルにリソースを段階的に付与します。
Admins+ResourceOwners による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ロールの名前。
リクエストの例:
POST /security/1.0/principals/{principal}/roles/{roleName}/bindings HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "resourcePatterns": [ { "resourceType": "string", "name": "string", "patternType": "string" } ] }
ステータスコード: - 204 No Content -- 許可されました
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
DELETE/security/1.0/principals/{principal}/roles/{roleName}/bindings¶ 指定されたロールを使用して、指定されたスコープ/クラスターのプリンシパルからリソースを段階的に削除します。
Admins+ResourceOwners による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ロールの名前。
リクエストの例:
DELETE /security/1.0/principals/{principal}/roles/{roleName}/bindings HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "resourcePatterns": [ { "resourceType": "string", "name": "string", "patternType": "string" } ] }
ステータスコード: - 204 No Content -- リソースが削除されました
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
PUT/security/1.0/principals/{principal}/roles/{roleName}/bindings¶ 既存のリソース付与を上書きします。
Admins+ResourceOwners による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- roleName (string) -- ロールの名前。
リクエストの例:
PUT /security/1.0/principals/{principal}/roles/{roleName}/bindings HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "resourcePatterns": [ { "resourceType": "string", "name": "string", "patternType": "string" } ] }
ステータスコード: - 204 No Content -- リソースが設定されました
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
RBAC - RoleBinding の概要¶
-
POST/security/1.0/lookup/principals/{principal}/roleNames¶ プリンシパルのロール名の有効なリストを返します。
グループの場合は、バインドされているロールです。
ユーザーの場合は、特定のユーザーに付与されたロールと、ユーザーのグループに付与されたロールの組み合わせです。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
リクエストの例:
POST /security/1.0/lookup/principals/{principal}/roleNames HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
ロール名のリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "Cluster Admin", "Security Admin" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/lookup/principal/{principal}/resources¶ 指定されたスコープ/クラスターのプリンシパルのリソースバインディングを検索します。
ユーザーが属するグループからのバインディングが含まれます。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
リクエストの例:
POST /security/1.0/lookup/principal/{principal}/resources HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
プリンシパルからロール、ロールからリソースへのネストされたマップ。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "User:alice": { "DeveloperRead": [ { "resourceType": "Topic", "name": "billing-invoices", "patternType": "LITERAL" } ] }, "Group:Investors": { "DeveloperRead": [ { "resourceType": "Topic", "name": "investing-", "patternType": "PREFIXED" } ] } }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/lookup/role/{roleName}¶ 指定されたスコープに対して指定されたロールを持つ KafkaPrincipal を検索します。
Admins による呼び出しが可能です。
パラメーター: - roleName (string) -- 検索するロール名。
リクエストの例:
POST /security/1.0/lookup/role/{roleName} HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
完全修飾された KafkaPrincipal のリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "User:alice", "Group:FinanceAdmin" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/lookup/role/{roleName}/resource/{resourceType}/name/{resourceName}¶ 指定されたスコープの指定されたリソースに対する指定されたロールを持つ KafkaPrincipal を検索します。
Admins による呼び出しが可能です。
パラメーター: - roleName (string) -- 検索するロール名。
- resourceType (string) -- 検索するリソースのタイプ。
- resourceName (string) -- 検索するリソースの名前。
リクエストの例:
POST /security/1.0/lookup/role/{roleName}/resource/{resourceType}/name/{resourceName} HTTP/1.1 Host: example.com Content-Type: application/json { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
完全修飾された KafkaPrincipal のリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "User:alice", "Group:FinanceAdmin" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
Kafka ACL の管理¶
-
POST/security/1.0/acls¶ 指定された AclBinding に対応する Kafka ACL を作成します。
Admins+AclUsers による呼び出し可能。
リクエストの例:
POST /security/1.0/acls HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusters": { "kafka-cluster": "string" } }, "aclBinding": { "pattern": { "resourceType": "UNKNOWN", "name": "string", "patternType": "UNKNOWN" }, "entry": { "principal": "string", "host": "string", "operation": "UNKNOWN", "permissionType": "UNKNOWN" } } }
ステータスコード: - 204 No Content -- AclBinding が追加されました。
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
DELETE/security/1.0/acls¶ 指定されたフィルターに従って Kafka ACL を削除します。
Admins+AclUsers による呼び出し可能。
リクエストの例:
DELETE /security/1.0/acls HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusters": { "kafka-cluster": "string" } }, "aclBindingFilter": { "patternFilter": { "resourceType": "UNKNOWN", "name": "string", "patternType": "UNKNOWN" }, "entryFilter": { "principal": "string", "host": "string", "operation": "UNKNOWN", "permissionType": "UNKNOWN" } } }
ステータスコード: - 200 OK --
AclBinding が削除されました。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "pattern": { "resourceType": "UNKNOWN", "name": "string", "patternType": "UNKNOWN" }, "entry": { "principal": "string", "host": "string", "operation": "UNKNOWN", "permissionType": "UNKNOWN" } } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
-
POST/security/1.0/acls:search¶ 指定されたフィルターに従って Kafka ACL をリストします。
Admins+AclUsers による呼び出し可能。
リクエストの例:
POST /security/1.0/acls:search HTTP/1.1 Host: example.com Content-Type: application/json { "scope": { "clusters": { "kafka-cluster": "string" } }, "aclBindingFilter": { "patternFilter": { "resourceType": "UNKNOWN", "name": "string", "patternType": "UNKNOWN" }, "entryFilter": { "principal": "string", "host": "string", "operation": "UNKNOWN", "permissionType": "UNKNOWN" } } }
ステータスコード: - 200 OK --
指定された AclBindingFilter に一致するすべての AclBinding を返します。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "pattern": { "resourceType": "UNKNOWN", "name": "string", "patternType": "UNKNOWN" }, "entry": { "principal": "string", "host": "string", "operation": "UNKNOWN", "permissionType": "UNKNOWN" } } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
- 200 OK --
クラスターレジストリ¶
-
GET/security/1.0/registry/clusters¶ レジストリ内のすべてのクラスターのリストを返します。オプションで、クラスタータイプでフィルター処理できます。
呼び出し元のプリンシパルに、完全なクラスター情報を表示するアクセス許可がない場合、一部の情報（"hosts"、"protocol" など）は編集されます。
Admins+User による呼び出しが可能です。
クエリのパラメーター: - clusterType (string) -- オプションで、クラスタータイプでフィルター処理できます。
リクエストの例:
GET /security/1.0/registry/clusters HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
クラスターのリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "clusterName": "string", "scope": { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "hosts": [ { "host": "string", "port": 1 } ], "protocol": "SASL_PLAINTEXT" } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/registry/clusters¶ 指定されたクラスターを定義/上書きします。
クラスターの名前とスコープの組み合わせが、レジストリ内の既存のクラスターと矛盾する場合、409（矛盾）が発生する可能性があります。
Admins による呼び出しが可能です。
リクエストの例:
POST /security/1.0/registry/clusters HTTP/1.1 Host: example.com Content-Type: application/json [ { "clusterName": "string", "scope": { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "hosts": [ { "host": "string", "port": 1 } ], "protocol": "SASL_PLAINTEXT" } ]
ステータスコード: - 204 No Content -- クラスターが追加されました。
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
GET/security/1.0/registry/clusters/{clusterName}¶ クラスターが存在し、呼び出し元のプリンシパルに表示されていると仮定して、単一の名前付きクラスターの情報を返します。
Admins+User による呼び出しが可能です。
パラメーター: - clusterName (string) -- クラスターの名前（スペースのない ASCII 印刷可能文字）。
リクエストの例:
GET /security/1.0/registry/clusters/{clusterName} HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
指定されたクラスター（存在していて、表示するためのアクセス許可が呼び出し元にある場合）。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "clusterName": "string", "scope": { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "hosts": [ { "host": "string", "port": 1 } ], "protocol": "SASL_PLAINTEXT" }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
DELETE/security/1.0/registry/clusters/{clusterName}¶ 指定されたクラスターをレジストリから削除します。
Admins による呼び出しが可能です。
パラメーター: - clusterName (string) -- クラスターの名前（スペースのない ASCII 印刷可能文字）。
ステータスコード: - 204 No Content -- クラスターが削除されました。
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
監査ログ構成¶
-
GET/security/1.0/audit/config¶ 送信先トピックのライブ保持時間ポリシー値（``retention_ms``）を含む、監査ログ構成全体を取得します。
Metadata Service（MDS）クラスターとクラスターレジストリ内のすべての Kafka クラスターに対する "AuditAdmin" ロールが必要です。
Admins による呼び出しが可能です。
リクエストの例:
GET /security/1.0/audit/config HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
監査ログ構成全体。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "destinations": { "topics": { "confluent-audit-log-events_general_allowed_events": { "retention_ms": 2592000000 }, "confluent-audit-log-events_general_denied_events": { "retention_ms": 7776000000 }, "confluent-audit-log-events_finance_reads": { "retention_ms": 157680000000 } } }, "excluded_principals": [ "User:Alice", "User:service_account_id" ], "default_topics": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" }, "routes": { "crn://mds1.example.com/kafka=*/topic=*": { "management": { "allowed": "", "denied": "" }, "authorize": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" } }, "crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/topic=finance-*": { "consume": { "allowed": "confluent-audit-log-events_finance_reads", "denied": "confluent-audit-log-events_general_denied_events" }, "interbroker": { "allowed": "", "denied": "" } } }, "metadata": { "resource_version": "ASNFZ4mrze8BI0VniavN7w", "updated_at": "2019-09-09T12:34:56Z" } }
- 200 OK --
-
PUT/security/1.0/audit/config¶ MDS クラスターおよびクラスターレジストリに認識されているすべての Kafka クラスターに対する監査ログ構成全体をアップデートします。
また、送信先クラスターで不足している送信先トピックを作成し、必要に応じて送信先トピックの保持時間ポリシーをアップデートします。
MDS クラスターとクラスターレジストリ内のすべての Kafka クラスターに対する "AuditAdmin" ロールが必要です。
リクエストの JSON 本文の
resource_versionが現在のバージョンと一致しない場合、409（矛盾）のエラーステータスが発生する可能性があります。Admins による呼び出しが可能です。
リクエストの例:
PUT /security/1.0/audit/config HTTP/1.1 Host: example.com Content-Type: application/json { "destinations": { "topics": { "confluent-audit-log-events_general_allowed_events": { "retention_ms": 2592000000 }, "confluent-audit-log-events_general_denied_events": { "retention_ms": 7776000000 }, "confluent-audit-log-events_finance_reads": { "retention_ms": 157680000000 } } }, "excluded_principals": [ "User:Alice", "User:service_account_id" ], "default_topics": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" }, "routes": { "crn://mds1.example.com/kafka=*/topic=*": { "management": { "allowed": "", "denied": "" }, "authorize": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" } }, "crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/topic=finance-*": { "consume": { "allowed": "confluent-audit-log-events_finance_reads", "denied": "confluent-audit-log-events_general_denied_events" }, "interbroker": { "allowed": "", "denied": "" } } }, "metadata": { "resource_version": "ASNFZ4mrze8BI0VniavN7w", "updated_at": "2019-09-09T12:34:56Z" } }
ステータスコード: - 200 OK --
現在の監査ログ構成の仕様
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "destinations": { "bootstrap_servers": [ "string" ], "topics": {} }, "excluded_principals": [ "string" ], "default_topics": { "allowed": "string", "denied": "string" }, "routes": {}, "metadata": { "resource_version": "string", "updated_at": "2022-12-15T18:42:31.458627", "modified_since": "2022-12-15T18:42:31.458627" } }
- 409 Conflict --
同時変更により競合が発生しました。応答は、現行の監査ログ構成になります。
応答の例:
HTTP/1.1 409 Conflict Content-Type: application/json { "destinations": { "bootstrap_servers": [ "string" ], "topics": {} }, "excluded_principals": [ "string" ], "default_topics": { "allowed": "string", "denied": "string" }, "routes": {}, "metadata": { "resource_version": "string", "updated_at": "2022-12-15T18:42:31.458627", "modified_since": "2022-12-15T18:42:31.458627" } }
- 200 OK --
-
GET/security/1.0/audit/routes¶ 照会されたリソースまたはそのサブリソースと一致する、現在定義されているすべてのルートをリストします。
複数のルートがリソースに一致する場合がありますが、リソースに関連するイベントに対して最も明確なルートのみが選択されます。このエンドポイントでは、実際に選択されるかどうか、より明確なルートを優先して無視されるかどうかに関係なく、一致するすべてのルートが返されます。
Metadata Service（MDS）クラスターとクラスターレジストリ内のすべての Kafka クラスターに対する "AuditAdmin" ロールが必要です。
Admins による呼び出しが可能です。
監査ログ構成ルートの CRN パターンには、ワイルドカードを含めることができます。このため、
crn://mds.example.com/kafka=*/topic=finance-*のような CRN パターンを持つルートは、アドレスcrn://mds.example.com/kafka=abc123/topic=finance-depositsのトピックに関連付けられたイベントまたはcrn://mds.example.com/kafka=xyz789/topic=finance-chargebacksのトピックに関連付けられたイベントに一致しますが、crn://mds.example.com/kafka=abc123/topic=server-deploymentsのトピックに関連付けられたイベントとは一致しません。したがって、ルートの CRN パターンは、パターンのワイルドカードの場所に基づいて、複数のリソースのイベントと一致する可能性があります。特定のリソースの CRN に一致するさまざまな CRN パターンで、複数のルートを書き込むこともできます。たとえば、
crn://mds.example.com/kafka=abc123/topic=finance-chargebacksのリソースは、以下のルート CRN パターンのいずれかと一致します。crn://mds.example.com/kafka=*/topic=*crn://mds.example.com/kafka=abc123/topic=*crn://mds.example.com/kafka=*/topic=finance-*
イベントに一致するルートが複数存在する場合は、最も明確な CRN パターンを持つルートが選択されます。最も明確な CRN パターンは、1 つ目のワイルドカードより前の部分の長さが最も長いパターンです。上の例では、
crn://mds.example.com/kafka=abc123/topic=*が該当します。比較結果が同等レベルになる場合は、両方のパターンに共通して存在するプレフィックスを無視します。たとえば、
crn://mds.example.com/kafka=*/topic=finance-*の方がcrn://mds.example.com/kafka=*/topic=*より明確です。このエンドポイントでは、実際に選択されるかどうか、より明確なルートを優先して無視されるかどうかに関係なく、照会されたリソースまたはそのサブリソースと一致する、現在定義されているすべてのルートがリストされます。
次のようなクエリパターン ...
crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=qa-test... は、以下のすべてのルートと一致します。
crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=qa-test/connector=from-db4crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=qa-test/connector=*crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=*/connector=*crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=qa-*crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=*crn://mds1.example.com/kafka=*/connect=qa-*crn://mds1.example.com/kafka=*/connect=qa-*/connector=*一方、以下のいずれのルートとも一致しません。
crn://mds1.example.com/kafka=*/ksql=*crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=stg-*crn://mds1.example.com/kafka=zyxwv-UTSRQPO_98765432/connect=qa-*crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/topic=qa-*クエリのパラメーター: - q (string) -- Confluent リソース名（CRN）。
リクエストの例:
GET /security/1.0/audit/routes HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
一致したルートとそのルール
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "default_topics": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" }, "routes": { "crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=qa-test/connector=from-db4": { "management": { "allowed": "", "denied": "" } }, "crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/connect=*": { "authorize": { "allowed": "confluent-audit-log-events_abc-connector-allowed", "denied": "confluent-audit-log-events_abc-connector-denied" } } } }
-
GET/security/1.0/audit/lookup¶ この CRN に関するメッセージがどのようにルーティングされるかを説明するルートを返します。
Metadata Service（MDS）クラスターとクラスターレジストリ内のすべての Kafka クラスターに対する "AuditAdmin" ロールが必要です。
監査ログ構成ルートの CRN パターンには、ワイルドカードを含めることができます。このため、
crn://mds.example.com/kafka=*/topic=finance-*のような CRN パターンを持つルートは、アドレスcrn://mds.example.com/kafka=abc123/topic=finance-depositsのトピックに関連付けられたイベントまたはcrn://mds.example.com/kafka=xyz789/topic=finance-chargebacksのトピックに関連付けられたイベントに一致しますが、crn://mds.example.com/kafka=abc123/topic=server-deploymentsのトピックに関連付けられたイベントとは一致しません。したがって、ルートの CRN パターンは、パターンのワイルドカードの場所に基づいて、複数のリソースのイベントと一致する可能性があります。特定のリソースの CRN に一致するさまざまな CRN パターンで、複数のルートを書き込むこともできます。たとえば、
crn://mds.example.com/kafka=abc123/topic=finance-chargebacksのリソースは、以下のルート CRN パターンのいずれかと一致します。crn://mds.example.com/kafka=*/topic=*crn://mds.example.com/kafka=abc123/topic=*crn://mds.example.com/kafka=*/topic=finance-*
イベントに一致するルートが複数存在する場合は、最も明確な CRN パターンを持つルートが選択されます。最も明確な CRN パターンは、1 つ目のワイルドカードより前の部分の長さが最も長いパターンです。上の例では、
crn://mds.example.com/kafka=abc123/topic=*が該当します。比較結果が同等レベルになる場合は、両方のパターンに共通して存在するプレフィックスを無視します。たとえば、
crn://mds.example.com/kafka=*/topic=finance-*の方がcrn://mds.example.com/kafka=*/topic=*より明確です。このエンドポイントは、構成されたすべての監査ログルートの一致ルールと優先ルールを解決し、特定の CRN に関するメッセージのルーティング方法を説明する、選択された（最も明確な）一致ルートを返します。Admins による呼び出しが可能です。
クエリのパラメーター: - crn (string) -- Confluent リソース名（CRN）。
リクエストの例:
GET /security/1.0/audit/lookup HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
システムによって選択および使用されるルートの CRN パターン（または文字列
"default"）と、さまざまな監査ログイベントカテゴリに関するルートのルール。カテゴリには、produce、consume、interbroker、authorize、authentication、management、heartbeat`、describeがあります。必要に応じて、サーバーはデフォルト値との組み合わせにより、ルールに不足している値またはnull値を補完します。authentication、authorizeおよびmanagementのカテゴリについては、default_topicsで指定された送信先トピックがデフォルト値になります。その他すべてのカテゴリについては、空の文字列がデフォルト値になります。ルールが空の文字列に解決される場合は、イベントが破棄されることを示します。応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "route": "crn://mds1.example.com/kafka=abcde_FGHIJKL-01234567/topic=finance-*", "categories": { "authorize": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" }, "consume": { "allowed": "", "denied": "confluent-audit-log-events_finance_denied" }, "describe": { "allowed": "", "denied": "" }, "heartbeat": { "allowed": "", "denied": "" }, "interbroker": { "allowed": "", "denied": "" }, "management": { "allowed": "confluent-audit-log-events_general_allowed_events", "denied": "confluent-audit-log-events_general_denied_events" }, "produce": { "allowed": "confluent-audit-log-events_finance_produce_allowed", "denied": "confluent-audit-log-events_finance_denied" } } }
プライベート RBAC UI - Cluster Visibility¶
-
POST/security/1.0/lookup/principals/{principal}/visibility¶ 指定されたプリンシパルについて、Kafka とそのサブクラスターの可視性を判断するための Confluent Control Center のエンドポイント。
目的は、実際に存在するクラスター ID でこのエンドポイントが呼び出されることです。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
リクエストの例:
POST /security/1.0/lookup/principals/{principal}/visibility HTTP/1.1 Host: example.com Content-Type: application/json [ { "kafka-cluster": "string", "connect-clusters": [ "string" ], "schema-registry-clusters": [ "string" ], "ksql-clusters": [ "string" ] } ]
ステータスコード: - 200 OK --
クラスター ID を返し、ユーザーにロールが関連付けられているかどうかを true/false で返します。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "kafka-cluster": { "id": "string", "visible": true, "clusterName": "string" }, "connect-clusters": [ { "id": "string", "visible": true, "clusterName": "string" } ], "schema-registry-clusters": [ { "id": "string", "visible": true, "clusterName": "string" } ], "ksql-clusters": [ { "id": "string", "visible": true, "clusterName": "string" } ] }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
GET/security/1.0/lookup/managed/clusters/principal/{principal}¶ ユーザーが表示できるロールバインディングのスコープを特定します。
存在したことがないか、以前に存在していたスコープおよびクラスターからのロールバインディング（つまり、廃止されたが、引き続きシステムに定義されているロールバインディング）が含まれる場合があります。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
クエリのパラメーター: - clusterType (string) -- クラスタータイプでフィルター処理されます。
リクエストの例:
GET /security/1.0/lookup/managed/clusters/principal/{principal} HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
スコープのリスト
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
プライベート RBAC UI - My RoleBindings¶
-
GET/security/1.0/lookup/rolebindings/principal/{principal}¶ ロールバインディングを持つすべてのスコープとクラスターについて、指定されたプリンシパルのロールバインディングをすべてリストします。
この操作では、ロールバインディングデータを見ているだけであり、クラスターが実際に存在することを意味するものではない点に注意してください。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
クエリのパラメーター: - clusterType (string) -- クラスタータイプでフィルター処理されます。
リクエストの例:
GET /security/1.0/lookup/rolebindings/principal/{principal} HTTP/1.1 Host: example.com
ステータスコード: - 200 OK --
スコープごとの、ユーザーのロールバインディングのリスト。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ { "scope": { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "rolebindings": {} } ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/lookup/rolebindings/principal/{principal}¶ 指定されたプリンシパルとスコープのロールバインディングをすべてリストします。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
リクエストの例:
POST /security/1.0/lookup/rolebindings/principal/{principal} HTTP/1.1 Host: example.com Content-Type: application/json { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
スコープごとの項目
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "scope": { "clusterName": "string", "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "rolebindings": {} }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
プライベート RBAC UI - Manage RoleBindings¶
-
POST/security/1.0/lookup/managed/clusters/principal/{principal}¶ 指定されたスコープに対してユーザーが持っているロールバインディングの能力（表示/管理）を特定します。
ロールバインディングの追加/削除ボタンへのアクセスを制御するために、Confluent Control Center UI によって使用されます。
Admins+ResourceOwners による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
リクエストの例:
POST /security/1.0/lookup/managed/clusters/principal/{principal} HTTP/1.1 Host: example.com Content-Type: application/json { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
指定されたスコープに対してユーザーが持っているロールバインディングの能力。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "cluster": [ "string" ], "resources": {} }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
-
POST/security/1.0/lookup/managed/rolebindings/principal/{principal}¶ このユーザーが表示および管理できるロールバインディングを特定します。
Admins+ResourceOwners による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
クエリのパラメーター: - resourceType (string) -- リソースタイプでフィルター処理されます。
リクエストの例:
POST /security/1.0/lookup/managed/rolebindings/principal/{principal} HTTP/1.1 Host: example.com Content-Type: application/json { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
このユーザーが管理できるロールバインディング。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "scope": { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }, "cluster_role_bindings": {}, "resource_role_bindings": {} }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
プライベート RBAC UI - Creation Guidelines¶
-
POST/security/1.0/lookup/principal/{principal}/resource/{resourceType}/operation/{operation}¶ このプリンシパルが作成できるリソースとロールバインディングの概要を示します。
Admins+User による呼び出しが可能です。
パラメーター: - principal (string) -- ユーザーまたはグループを示す完全修飾の KafkaPrincipal 文字列。
- resourceType (string) -- 作成するリソースのタイプ、または新しいロールバインディングを作成するときに指定するリソースのタイプ。
- operation (string) -- 実際のリソースを作成する場合は "Create"、ユーザーのロールバインディングを作成する場合は "AlterAccess"。
リクエストの例:
POST /security/1.0/lookup/principal/{principal}/resource/{resourceType}/operation/{operation} HTTP/1.1 Host: example.com Content-Type: application/json { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
リソースまたはロールバインディングを作成するために使用される、ユーザーのロールバインディングのビュー。重複が排除され、情報が圧縮されています。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json { "result": "SOME", "resourcePatterns": [ { "resourceType": "Topic", "name": "billing-invoices", "patternType": "LITERAL" }, { "resourceType": "Topic", "name": "investing-", "patternType": "PREFIXED" } ] }
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }
プライベート RBAC UI - Cached User Store Information¶
-
POST/security/1.0/rbac/principals¶ MDS でキャッシュされたユーザーとグループのリスト。
指定されたスコープでロールバインディング管理者が使用します。
Admins+ResourceOwners による呼び出しが可能です。ブローカーの super.users による呼び出し不可能。
クエリのパラメーター: - type (string) -- リクエストされたプリンシパルのタイプ。
リクエストの例:
POST /security/1.0/rbac/principals HTTP/1.1 Host: example.com Content-Type: application/json { "clusters": { "kafka-cluster": "string", "connect-cluster": "string", "ksql-cluster": "string", "schema-registry-cluster": "string" } }
ステータスコード: - 200 OK --
リクエストされたタイプのプリンシパルのリスト、またはすべてのプリンシパル。
応答の例:
HTTP/1.1 200 OK Content-Type: application/json [ "Group:admin", "Group:developers", "Group:users", "User:alice", "User:bob", "User:charlie", "User:david" ]
- default --
エラー応答
応答の例:
HTTP/1.1 default - Content-Type: application/json { "status_code": 1, "error_code": 1, "type": "string", "message": "string", "errors": [ { "error_type": "string", "message": "string" } ] }