Confluent Cloud Gateway 1.3.0、中央ガバナンスとOAuth交換を追加

Confluent Cloud Gateway 1.3.0が公開されました。スキーマレジストリと連携してメッセージをGatewayで検証する中央ガバナンス機能、異なるIDプロバイダー間のOAuth認証交換、CyberArk Conjurのシークレット保存先対応などが追加されています。

要点

• 中央ガバナンス機能はEarly Accessで、Docker配備のみが対象です。
• キーと値に対し、スキーマID、詳細スキーマ、フィールド暗号化、全体暗号化のポリシーを設定できます。
• SASL/OAUTHBEARERによるOAuth間の認証交換に対応しました。
• CyberArk Conjurをシークレット保存先として利用できます。
• fencingフィルターを認証交換より先に処理するよう順序が変わりました。

今回のリリースノートで語られていること

中央ガバナンス機能は、Kafkaクラスターへ届く前にGatewayがメッセージを検証し、スキーマレジストリの規則へ適合しないレコードを止める仕組みです。レコードのキーと値へ独立したポリシーを設定でき、スキーマIDの存在確認、内容を含むスキーマ検証、フィールド単位の暗号化、ペイロード全体の暗号化という4種類が示されています。Avro、JSONスキーマ、Protobufを使うレコードが対象で、トピックごとの上書きにも対応します。

この機能はEarly Accessで、現時点ではDockerを使った配備だけが対象です。設定項目名、強制レベル、YAML構造は一般提供までに変わる可能性があり、後方互換性も保証されていません。本番の標準設定として固定する段階ではなく、検証環境でポリシーの拒否条件、既存生産者への影響、更新時の移行方法を確認する位置付けです。

認証交換では、クライアント側とKafka側で異なるIDプロバイダーを使う構成に対し、SASL/OAUTHBEARERを利用できるようになりました。また、シークレット保存先としてCyberArk Conjurが追加されています。fencingフィルターは認証交換より先に実行されるようになり、経路が遮断されている場合にBROKER_NOT_AVAILABLEを早く返し、原因を判別しやすくします。

実務上は、中央でポリシーを強制すると、個々の生産者が同じ検証を実装しなくても不適合データを入口で止められる一方、Gatewayの設定ミスが複数トピックへ同時に影響する可能性があります。段階導入では、監視対象だけのポリシーから始め、拒否されるレコードと既存スキーマの差を観測してから強制へ切り替える方法が考えられます。トピック固有の上書きが全体方針を弱めないよう、設定変更の承認と監査記録も合わせて用意する必要があります。

この更新が関係する人

Confluent Gatewayを通じて複数のKafkaクラスターへ接続する基盤担当者、スキーマレジストリでガバナンスを管理するチーム、OAuthやCyberArk Conjurを使うセキュリティ担当者に関係します。メッセージ不備を下流で修復するのではなく、入口で止めたい組織が主な対象です。

実務で確認したいポイント

• Early Accessを本番経路へ適用できるか、変更許容度を確認する。
• キーと値、トピックごとのポリシー優先順位を試験する。
• 不適合レコードの拒否、通知、再送、監査ログの運用を決める。
• OAuth交換時の発行者、対象者、権限、トークン更新を検証する。
• fencing時のエラー変更が監視や自動復旧へ与える影響を確認する。

結局、今回の更新をどう読むべきか

1.3.0は、Gatewayを接続経路だけでなく、スキーマと暗号化ポリシーを中央で強制する地点へ広げる更新です。ただし中心機能はEarly Accessで設定互換性も確定していません。まずDockerの検証環境で既存生産者への影響と拒否後の運用を確認し、一般提供まで設定を固定しすぎないことが重要です。