このページでは、Google Cloud Managed Service for Apache Kafka ブローカーに接続するクライアント アプリケーションでサポートされている認証方法について説明します。
Google Kubernetes Engine、Compute Engine、Cloud Run、Cloud Run 関数などの Google Cloud サービスで実行されている Google Cloud Managed Service for Apache Kafka クライアント アプリケーションには、次の認証オプションがあります。
SASL/OAUTHBEARER（推奨）: Google Cloud内のクライアントにとって最もシームレスで安全な方法です。アプリケーションのデフォルト認証情報（ADC）を使用して、環境に関連付けられたサービス アカウント ID を自動的に検索します。これにより、サービス アカウント キーなどの静的認証情報ファイルを管理して配布する必要がなくなります。
SASL/PLAIN: これは初期の開発に役立つ方法です。クライアントは、有効期間の長いサービス アカウント キーを使用して認証します。
mTLS: 組織の標準が証明書ベースの認証である場合は、このオプションを使用します。 Google Cloudのアプリケーションがクライアント証明書と鍵で構成されている。
オンプレミスのデータセンターや別のクラウド プロバイダなど、 Google Cloudの外部で実行されているクライアント アプリケーションの場合は、次の認証方法を検討してください。組織のセキュリティ ポスチャーと既存の ID インフラストラクチャに基づいて、最適な方法を選択します。
SASL/OAUTHBEARER を使用した Workload Identity 連携（推奨）: 外部クライアントにとって最も安全な方法です。これにより、AWS、Microsoft Azure などの外部システムや、ADFS などのオンプレミス ID プロバイダの ID に、Google Cloud サービス アカウントの権限を借用する権限を付与できます。クライアントは、有効期間の長いサービス アカウント キーを管理する代わりに、優先する認証情報を使用して有効期間の短い Google Cloud アクセス トークンを取得します。クライアントはこのトークンを認証に使用します。これにより、静的認証情報ファイルに関連するセキュリティ リスクが大幅に軽減されます。
mTLS: この方法はプロバイダに依存せず、組織がすでに公開鍵基盤（PKI）を使用してサービス ID の TLS 証明書を管理している場合に適しています。これにより、クライアントは Google Cloud固有の ID なしで認証できます。ただし、このアプローチでは、サービス アカウント キーを使用する場合と同様に、クライアント証明書などの有効期間が長い認証情報のライフサイクルと配布を管理する必要があります。
サービス アカウント キーを使用した SASL/PLAIN: このメソッドを使用すると、外部クライアントが Google Cloud ID として直接認証できます。サービス アカウント キーの JSON ファイルをダウンロードして、クライアントの SASL/PLAIN 構成で使用します。この方法は、クライアントサイドで有効期間の長い静的認証情報の管理と保護が必要になるため、一般的に本番環境のワークロードにはおすすめしません。
SASL と mTLS の機能の比較
Managed Service for Apache Kafka の主な認証メカニズムは SASL（Simple Authentication and Security Layer）です。これはGoogle Cloudの ID サービスと直接統合されています。ベースラインとして、SASL はサービス アカウントなどの Google Cloud IAM プリンシパルを使用してクライアントを認証します。認証に関して、SASL は柔軟性を提供します。きめ細かい IAM ロールと Kafka のアクセス制御リスト（ACL）を使用して、クラスタへのアクセスを管理できます。
一方、mTLS は Google Cloud IAM に依存しないプロバイダに依存しない認証方法を提供します。代わりに、mTLS は TLS 証明書に基づいてクライアントを認証します。ID は証明書のサブジェクト名から派生します。
この違いにより、認可の処理方法に大きな違いが生じます。SASL プリンシパルとは異なり、mTLS プリンシパルは Kafka ACL を使用してのみ承認する必要があります。 Google Cloud IAM ロールで管理することはできません。
クラスタの Kafka ACL を構成することを強くおすすめします。ACL が設定されていない場合、デフォルトの Kafka の動作では、SASL または mTLS を使用しているかどうかにかかわらず、認証されたすべてのプリンシパルにクラスタへのフルアクセス権が付与されます。Kafka ACL の構成方法については、Managed Service for Apache Kafka ACL を作成するをご覧ください。
Managed Service for Apache Kafka は、CA Service にある認証局によって発行されたクライアント証明書を使用した mTLS 認証をサポートしています。組織で外部ルート オブ トラストを使用している場合は、外部 CA に連結する下位 CA を CA Service 内に作成することで、外部ルート オブ トラストを統合できます。
次の表は、認証方法の機能を比較したものです。
| 機能 | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| メインの ID | Google Cloud IAM プリンシパル | Google Cloud IAM プリンシパル | 証明書のサブジェクト名 |
| 認証情報の種類 | アプリケーションのデフォルト認証情報（ADC）または OAuth 2.0 トークン | Base64 でエンコードされたサービス アカウント キー | クライアント証明書と秘密鍵 |
| 認証方法 | Google Cloud IAM ロールまたは Kafka ACL | Google Cloud IAM ロールまたは Kafka ACL | Kafka ACL のみ |
| ユースケース | Google Cloudのクライアント。Workload Identity 連携を使用する外部クライアント | サービス アカウント キーの使用が必要なシンプルなクライアント、テスト シナリオ、またはレガシー システム。 | プロバイダに依存しないため、オンプレミス、マルチクラウド、既存の PKI アプリケーションに最適です。 |
| クライアント構成 | 専用のログイン ハンドラ クラス（Java）またはローカル認証サーバー（非 Java）を使用した JAAS 構成 | 標準の PlainLoginModule を使用した JAAS 構成（Java） | キーストアとトラストストアのプロパティ（例: security.protocol=SSL） |
| クラスタの可用性 | すべてのクラスタ | すべてのクラスタ | 2025 年 6 月 24 日より後に作成されたクラスタ |
SASL と mTLS の選択
認証方法の選択は、組織のセキュリティ ポリシーと既存のインフラストラクチャに基づいて行います。ほとんどのユースケースでは、 Google Cloud IAM で SASL を使用することをおすすめします。
Google Cloud IAM または Workload Identity 連携を使用した SASL は、認証と認可に最も柔軟で統合されたエクスペリエンスを提供します。権限の管理には、 Google Cloudの ID システムが信頼できる唯一の情報源として使用されます。このパスは、次のような場合に選択します。
使い慣れたGoogle Cloud IAM ロールを使用して、Kafka クライアントの権限を一元管理します。
クライアントで静的認証情報を管理しないようにします。
AWS、Azure などの他のクラウドや、Okta や ADFS などのオンプレミス ID プロバイダのクライアントが Workload Identity 連携を使用して認証できるようにします。この方法では、別の認証プロトコルに切り替える必要がなく、安全でクラウドに依存しない ID ソリューションが提供されます。
組織に証明書ベースの認証に関する厳格な要件がある場合は、mTLS を選択します。この必要性は、ID に TLS 証明書をすでに使用している既存のオンプレミス Kafka デプロイを移行する場合、または企業ポリシーでクライアント証明書がすべてのアプリケーションに義務付けられている場合に発生します。mTLS は強力なトランスポート レベルのセキュリティを提供しますが、mTLS クライアントの認可は Kafka ACL でのみ管理する必要があることに注意してください。これは Google Cloud IAM とは異なります。
SASL/PLAIN または SASL/OAUTHBEARER を構成するワークフロー
Managed Service for Apache Kafka で SASL 認証を使用するようにクライアントを構成するには、クライアントの ID に権限を付与し、選択した SASL メカニズムに基づいてクライアント アプリケーションを構成します。必要なワークフローの概要は次のとおりです。SASL の構成方法について詳しくは、SASL 認証を構成するをご覧ください。
IAM 権限を付与する。まず、クライアントが認証に使用するサービス アカウントに Managed Kafka クライアント（
roles/managedkafka.client）ロールを付与する必要があります。このロールは、プロジェクト内の Kafka クラスタに接続するために必要なmanagedkafka.clusters.connect権限を付与します。Kafka クライアントを構成します。具体的なクライアント構成は、SASL/OAUTHBEARER メカニズムと SASL/PLAIN メカニズムのどちらを使用するかによって異なります。
SASL/OAUTHBEARER（推奨）の場合: このメカニズムは、アプリケーションのデフォルト認証情報 ADC を使用します。構成はクライアントの言語によって異なります。
Java クライアント: 特殊な Google Cloud 認証ライブラリをアプリケーションのクラスパスに追加します。次に、提供された
GcpLoginCallbackHandlerクラスを使用するように Kafka クライアント プロパティを構成します。このクラスは、ADC を使用した認証を自動的に処理します。GcpLoginCallbackHandlerは、Kafka の OAUTHBEARER 認証メカニズムで使用されるクラスで、Managed Service for Apache Kafka での使用を想定して設計されています。Google の ID プロバイダから JSON Web Token（JWT）を取得するプロセスを処理し、Kafka クライアントが ADC を使用してサービスを認証できるようにします。Java 以外のクライアント: 提供されたローカル認証サーバーをクライアントのマシンで実行します。このサーバーは ADC を使用して認証情報を取得し、Kafka クライアントに提供します。クライアントは、このローカル サーバーのエンドポイントから認証トークンを取得するように構成されます。
SASL/PLAIN の場合
このメカニズムでは、ユーザー名とパスワードの組み合わせを使用します。クライアント アプリケーションは、SASL_SSL セキュリティ プロトコル、PLAIN メカニズム、
PlainLoginModuleクラスを指定する JAAS 構成を使用するように構成する必要があります。ユーザー名はサービス アカウントのメールアドレスです。パスワードは次のいずれかの方法で生成できます。
サービス アカウント キーの JSON ファイルを base64 でエンコードします。
有効期間の短いアクセス トークンを取得します。
認可を構成する。クライアントが SASL を使用して正常に認証されると、クラスタの IAM ロールまたは Kafka ACL で定義された権限によってアクセスが制御されます。
SASL の制限事項
SASL 認証方法には次の制限があります。
SASL 認証は、本質的に IAM プリンシパルに関連付けられています。Workload Identity 連携を構成しない限り、Google Cloud ID との厳密な分離が必要な組織や、Google 以外の ID を使用する組織には適していません。
SASL は認証にクライアント証明書を使用しません。既存の PKI を使用してアプリケーションを識別する組織には適していません。
mTLS を構成するワークフロー
Managed Service for Apache Kafka の mTLS を構成するには、認証局、Kafka クラスタ、Kafka クライアントを構成します。mTLS の構成方法の詳細な手順については、mTLS 認証を構成するをご覧ください。
認証局（CA）を構成します。まず、Certificate Authority Service（CA Service）で CA プールを作成して構成する必要があります。別のプロジェクトにある CA プールを作成する場合は、これらのプールにアクセスする権限を Managed Service for Apache Kafka サービス エージェント（
service-PROJECT_NUMBER@gcp-sa-managedkafka.iam.gserviceaccount.com）に付与してください。CA プール内にルート証明書と下位証明書を作成する必要があります。Kafka クラスタを構成します。構成済みの CA プールのリソース ID を指定して、mTLS を有効にするようにクラスタを作成または更新します。また、ACL で使用する簡略化されたプリンシパル名を作成するために、
ssl.principal.mapping.rulesブローカー プロパティを構成することをおすすめします。これを行うには、Google Cloud CLI コマンドを使用します。Kafka クライアントを構成します。CA からクライアント証明書を取得し、クライアントの環境（Java キーストアなど）にインストールします。次に、クライアント アプリケーションを正しいセキュリティ プロトコル（SSL）とキーストアの場所で構成して、クラスタの専用 mTLS ブートストラップ ポート（
9192）に接続する必要があります。mTLS をモニタリングする。設定後、
managedkafka.googleapis.com/mtls_truststore_update_count指標をモニタリングして、クラスタが CA Service プールから CA 証明書を定期的に更新していることを確認します。Cloud Logging を使用することもできます。
mTLS の制限事項
mTLS 機能には次の制限があります。
mTLS 機能は、2025 年 6 月 24 日以降に作成された Managed Service for Apache Kafka クラスタでのみ使用できます。
Kafka ACL を使用して、mTLS プリンシパルの認可を構成する必要があります。IAM ロール バインディングを使用して mTLS クライアントを承認することはできません。
このサービスは、CA Service によって管理される証明書を提示するクライアントのみを認証します。ただし、外部 CA に連結する下位 CA を CA Service 内に作成することで、外部ルート オブ トラストを統合できます。
最大 10 個の CA プールを信頼するようにクラスタを構成できます。