Schema Registry セキュリティプラグインのインストールと構成

インストール

重要

このソフトウェアは、Confluent エンタープライズライセンス を取得することで使用できます。このソフトウェアは、ライセンスキーがなくても 30 日間試用できます。既にご契約されている場合は、詳細について Confluent サポート(support@confluent.io)にお問い合わせください。

Confluent セキュリティプラグインは、Confluent Platform コンポーネントの拡張です。ZIP および TAR アーカイブを使用している場合、セキュリティプラグインはデフォルトでインストールされます。ただし、DEB または RPM パッケージを使用している場合は、手動でインストールする必要があります。

デプロイされた Schema Registry のクラスパスに以下の JAR ファイルが含まれている必要があります。Schema Registry セキュリティプラグインのデフォルトの場所は、以下のとおりです。

<path-to-confluent>/share/java/confluent-security/schema-registry/confluent-security-plugins-common-<version>.jar
<path-to-confluent>/share/java/confluent-security/schema-registry/confluent-schema-registry-security-plugin-<version>.jar

ZIP および TAR アーカイブ

ZIP または TAR アーカイブ を使用して Confluent Platform をインストールした場合、セキュリティプラグインはデフォルトでインストールされ、個々のコンポーネントディレクトリの <path-to-confluent>/share/java/ にファイルが保存されます。

Ubuntu および Debian

Confluent Platform を Ubuntu または Debian 環境に インストールした場合は、次のコマンドを使用して、別途プラグインをインストールする必要があります。

sudo apt-get update && sudo apt-get install confluent-security

RHEL および CentOS

Confluent Platform を RHEL、CentOS または Fedora ベースの環境に インストールした場合は、次のコマンドを使用して、別途プラグインをインストールする必要があります。

sudo yum install confluent-security

プラグインのアクティブ化

インストール後、Schema Registry 構成ファイル(/etc/schema-registry/schema-registry.properties )に次の行を追加することで、プラグインをアクティブにすることができます。

resource.extension.class=io.confluent.kafka.schemaregistry.security.SchemaRegistrySecurityResourceExtension

resource.extension.class

SchemaRegistryResourceExtension インターフェイスの有効な実装の完全修飾クラス名。ユーザー定義リソース(フィルターなど)を挿入する際に使用できます。一般に、ログ記録、セキュリティなど、カスタム機能を追加する際に使用されます。(非推奨となった schema.registry.resource.extension.class の代わりに、resource.extension.class を使用してください。)

  • 型: string
  • デフォルト: ""
  • 重要度: 低

注釈

  • プラグインを有効にするには、resource.extension.class を構成する必要があります。
  • TLS/SSL 認証メカニズムを使用するには、ssl.client.authenticationREQUESTED または REQUIRED に設定する必要があります。「Schema Registry の構成オプション」も参照してください。
  • inter.instance.protocol を使用し、https を設定する必要があります。設定しない場合、セカンダリからプライマリへの転送はすべて失敗します。「Schema Registry のセキュリティ概要」の「HTTPS 用の追加構成」も参照してください。(schema.registry.inter.instance.protocol は非推奨です。 inter.instance.protocol を使用してください。)
  • セカンダリからプライマリへの転送には、ssl.keystore.location の X500 プリンシパルが使用されます。このユーザーにはスーパーユーザーのアクセス権が必要であるため、通常の Schema Registry のアクセスには使用しないようにする必要があります。

認証メカニズム

Schema Registry に対する受信リクエストの認証メカニズムは、confluent.schema.registry.auth.mechanism の構成で決まります。TLS/SSL と Jetty の両方の認証メカニズムがサポートされています。

ロールベースアクセス制御 を使用する場合、Schema Registry では、RBAC 認可用に Schema Registry クライアントによって HTTP 基本認証資格情報(またはトークン)が提供されることを想定します。RBAC の有効化と構成を行うまで Confluent Platform 全体で TLS/SSL 証明書認証に依存していた場合、Kafka 以外の Confluent Platform コンポーネントでは基本認証資格情報(LDAP ユーザーなど)も指定する必要があることに注意してください(Schema Registry などの Confluent Platform コンポーネントには REST エンドポイントがあり、RBAC を使用する場合は、mTLS 認証から派生したプリンシパルの使用がサポートされないため)。具体的には、Schema Registry の場合は HTTP 基本認証 のベアラー トークンを指定し、basic.auth.user.info および basic.auth.credentials.source を含める必要があります。RBAC の使用時に使用する認証方法の詳細については、「RBAC 認証オプション」を参照してください。

認証メカニズムが設定されていない場合、すべてのリクエストは HTTP エラーコード 403 で拒否されます。

この認可の仕組みおよび構成方法の詳細については、「Schema Registry の認可」を参照してください。

ライセンスクライアント認証

プリンシパル伝播を使用する場合は、SASL OAUTHBEARER(RBAC)、SASL PLAIN、SASL SCRAM および mTLS のライセンスクライアント認証を構成する必要があります。詳細については、以下のドキュメントを参照してください。

ライセンスクライアント認可

プリンシパル伝播を使用する場合は、RBAC および ACL の認可を構成する必要があります。

注釈

Confluent Platform 6.2.1 以降では、_confluent-command 内部トピックが提供されており、Schema Registry、REST Proxy、Confluent Server などの(従来は _confluent-license が使用されていた)コンポーネントで、_confluent-license トピックの代わりに使用することが推奨されています。今後は両方のトピックがサポートされます。以下に、いくつかのガイドラインを示します。

  • 新しいデプロイ(Confluent Platform 6.2.1 以降)では、以下に示すように、デフォルトで _confluent-command が使用されます。
  • 既存のクラスターでは、手動で変更しない限り、引き続き _confluent-license が使用されます。
  • Confluent Platform 6.2.1 以降で新しく作成されたクラスターでは、デフォルトで _confluent-command トピックが作成されます。_confluent-license トピックは、既にそれが適用されている既存のクラスターでのみ、引き続き使用されます。
  • RBAC による認可 次のコマンドを実行して、コンポーネントユーザーの ResourceOwner を Confluent ライセンストピックのリソース(デフォルト名は _confluent-command)に追加します。

    confluent iam rbac role-binding create \
    --role ResourceOwner \
    --principal User:<service-account-id> \
    --resource Topic:_confluent-command \
    --kafka-cluster-id <kafka-cluster-id>
    
  • ACL による認可 次のコマンドを実行して Kafka 認可を構成します。その際、ブートストラップサーバー、クライアント構成、サービスアカウント ID を指定します。これにより _confluent-command トピックの作成、読み取り、書き込みが許可されます。

    kafka-acls --bootstrap-server <broker-listener> --command-config <client conf> \
    --add --allow-principal User:<service-account-id>  --operation Create --operation Read --operation Write \
    --topic _confluent-command
    

構成

ちなみに

Confluent Platform のライセンス情報全般については、「Confluent Platform ライセンス」を参照してください。

confluent.license

Confluent では、各契約者にライセンスキーを発行します。ライセンスキーは、コピーアンドペーストできる短いテキストです。ライセンスキーがなくても、Confluent セキュリティプラグインを 30 日間試用できます。既にご契約済みであってもライセンスキーをお持ちでない場合は、Confluent サポート(support@confluent.io)にお問い合わせください。

  • 型: string
  • デフォルト: ""
  • 重要度: 高

confluent.schema.registry.authorizer.class

Schema Registry リクエストの認可に使用される実装。SchemaRegistryAuthorizer インターフェイスの実装となっている必要があります。

  • 型: string
  • デフォルト: ""
  • 重要度: 高

confluent.schema.registry.acl.topic

Schema Registry の操作用の ACL を保存するために使用されるトピック。これは省略可能です。この構成が使用された場合、トピック名は kafkastore.topic として派生され、_acl というサフィックスが使用されます。

  • 型: string

confluent.topic.acl.super.users

スーパーユーザーになることができるユーザーをセミコロンで区切ったリスト。読み取りまたは書き込みの互換性などのサブジェクトを含まないグローバルな操作を実行するには、必ずスーパーユーザーになる必要があります。たとえば、admin1;admin2 では、admin1 と admin2 の両方がスーパーユーザーになります。

  • 型: string
  • デフォルト: ""
  • 重要度: 中

confluent.schema.registry.auth.mechanism

Schema Registry リクエストの認証に使用されるメカニズム。認証メカニズムからのプリンシパルが、構成されているオーソライザーを使用したオプションの認可に使用されます。

  • 型: string
  • デフォルト: "SSL"
  • 重要度: 低

confluent.schema.registry.auth.ssl.principal.mapping.rules

HTTPS に使用されます。クライアント証明書の識別名(DN)を短い名前にマッピングするためのルールのリスト。ルールは順番に評価され、プリンシパル名と一致する最初のルールが、短い名前へのマッピングに使用されます。リスト内のそれ以降のルールはすべて無視されます。デフォルトでは、X.500 証明書の DN がプリンシパルになります。詳細については、「mTLS から SASL への認証情報の伝播」を参照してください。

  • 型: list
  • デフォルト: "DEFAULT"
  • 重要度: 低