本页介绍了客户端应用连接到 Google Cloud Managed Service for Apache Kafka 代理时受支持的身份验证方法。
对于在 Google Cloud Google Kubernetes Engine、Compute Engine、Cloud Run 或 Cloud Run 函数等服务上运行的 Google Cloud Managed Service for Apache Kafka 客户端应用，您可以使用以下身份验证选项：
SASL/OAUTHBEARER（推荐）：这是 Google Cloud中最顺畅、最安全的客户端身份验证方法。它使用应用默认凭据 (ADC) 自动查找与环境关联的服务账号身份。这样一来，您无需管理和分发静态凭据文件（例如服务账号密钥）。
SASL/PLAIN：这是一种在早期开发阶段很有用的方法。 客户端使用长期有效的服务账号密钥进行身份验证。
mTLS：如果贵组织的标准是基于证书的身份验证，则可以选择此选项。 Google Cloud上的应用已配置客户端证书和密钥。
对于在 Google Cloud之外运行的客户端应用（例如在本地数据中心或其他云服务提供商中运行的应用），请考虑以下身份验证方法。根据组织的安全状况和现有的身份基础架构，选择最合适的方法。
使用 SASL/OAUTHBEARER 的工作负载身份联合（推荐）：这是外部客户端最安全的方法。借助此功能，您可以向外部系统（例如 AWS、Microsoft Azure 或 ADFS 等本地身份提供方）中的身份授予模拟Google Cloud 服务账号的权限。客户端不再需要管理长期有效的服务账号密钥，而是使用其首选凭据来获取短期有效的 Google Cloud 访问令牌。然后，客户端使用此令牌进行身份验证，这可显著降低与静态凭据文件相关的安全风险。
mTLS：此方法与提供方无关，如果您的组织已使用公钥基础架构 (PKI) 来管理服务身份的 TLS 证书，则此方法非常适合。它允许客户端在没有 Google Cloud特定身份的情况下进行身份验证。不过，与使用服务账号密钥类似，此方法需要您管理长期有效凭据（例如客户端证书）的生命周期和分发。
使用服务账号密钥的 SASL/PLAIN：此方法为外部客户端提供了一种直接以 Google Cloud 身份进行身份验证的方式。您下载服务账号密钥 JSON 文件，并在客户端的 SASL/PLAIN 配置中使用该文件。对于生产工作负载，我们通常不建议使用此方法，因为此方法需要在客户端管理和保护长期有效的静态凭据。
SASL 与 mTLS 之间的功能比较
Managed Service for Apache Kafka 的主要身份验证机制是 SASL（简单身份验证和安全层），它直接与Google Cloud的身份服务集成。作为基准，SASL 使用 Google Cloud IAM 主账号（例如服务账号）对客户端进行身份验证。对于授权，SASL 提供了灵活性：您可以使用精细的 IAM 角色和 Kafka 的访问控制列表 (ACL) 来管理对集群的访问权限。
相比之下，mTLS 提供了一种与提供商无关的身份验证方法，不依赖于 Google Cloud IAM。相反，mTLS 会根据客户端的 TLS 证书对客户端进行身份验证，其中身份是从证书的主题名称派生出来的。
这种区别导致授权处理方式存在关键差异。与 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 Service 中创建一个链接到外部 CA 的从属 CA，从而集成该信任根。
下表比较了各种身份验证方法的功能。
| 功能 | SASL/OAUTHBEARER | SASL/PLAIN | mTLS |
|---|---|---|---|
| 主要身份 | 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上的客户端；使用工作负载身份联合的外部客户端 | 简单客户端、测试场景或需要使用服务账号密钥的旧版系统。 | 与提供商无关；非常适合本地、多云或现有 PKI 应用。 |
| 客户端配置 | 具有专用登录处理程序类 (Java) 或本地身份验证服务器（非 Java）的 JAAS 配置 | 使用标准 PlainLoginModule 的 JAAS 配置 (Java) | 密钥库和信任库属性（例如 security.protocol=SSL） |
| 集群可用性 | 所有集群 | 所有集群 | 2025 年 6 月 24 日之后创建的集群 |
选择 SASL 还是 mTLS
身份验证方法的选择取决于组织的安全政策和现有基础设施。对于大多数使用场景，我们建议将 SASL 与 Google Cloud IAM 搭配使用。
使用 Google Cloud IAM 或 Workload Identity Federation 的 SASL 可提供最灵活且集成度最高的身份验证和授权体验。它使用 Google Cloud的身份系统作为管理权限的唯一可信来源。如果您想执行以下操作，请选择此路径：
使用熟悉的Google Cloud IAM 角色集中管理 Kafka 客户端的权限。
避免在客户端上管理静态凭据。
允许来自其他云平台（如 AWS、Azure）或本地身份提供方（如 Okta 或 ADFS）的客户端使用工作负载身份联合进行身份验证。此方法提供了一种安全、与云平台无关的身份解决方案，无需切换到其他身份验证协议。
如果您的组织对基于证书的身份验证有严格要求，请选择 mTLS。如果您要迁移已使用 TLS 证书进行身份验证的现有本地 Kafka 部署，或者公司政策要求所有应用都使用客户端证书，则需要这样做。虽然 mTLS 可提供强大的传输级安全性，但请注意，mTLS 客户端的授权必须仅通过 Kafka ACL 进行管理，这与 Google Cloud IAM 是分开的。
配置 SASL/PLAIN 或 SASL/OAUTHBEARER 的工作流程
配置客户端以将 SASL 身份验证与 Managed Service for Apache Kafka 搭配使用，需要向客户端的身份授予权限，然后根据所选的 SASL 机制配置客户端应用。以下是所需工作流程的概览。如需详细了解如何配置 SASL，请参阅配置 SASL 身份验证。
授予 IAM 权限。您必须先向客户端用于身份验证的服务账号授予 Managed Kafka Client (
roles/managedkafka.client) 角色。此角色提供连接到项目内 Kafka 集群所需的managedkafka.clusters.connect权限。配置 Kafka 客户端。具体的客户端配置取决于您使用的是 SASL/OAUTHBEARER 机制还是 SASL/PLAIN 机制。
对于 SASL/OAUTHBEARER（推荐）：此机制使用应用默认凭据 ADC。配置取决于客户的语言：
Java 客户端：将专用 Google Cloud 身份验证库添加到应用的类路径中。然后，配置 Kafka 客户端属性以使用提供的
GcpLoginCallbackHandler类，该类会自动使用 ADC 处理身份验证。GcpLoginCallbackHandler是一个与 Kafka 的 OAUTHBEARER 身份验证机制搭配使用的类，专门设计用于 Managed Service for Apache Kafka。它负责处理从 Google 的身份提供商处获取 JSON Web 令牌 (JWT) 的过程，使 Kafka 客户端能够使用 ADC 向服务进行身份验证。非 Java 客户端：在客户端的机器上运行提供的本地身份验证服务器。此服务器使用 ADC 来提取凭据，并将其提供给 Kafka 客户端。然后，客户端会配置为从该本地服务器的端点获取其身份验证令牌。
对于 SASL/PLAIN
此机制使用用户名和密码组合。必须将客户端应用配置为使用 SASL_SSL 安全协议、PLAIN 机制和指定
PlainLoginModule类的 JAAS 配置。用户名是服务账号的电子邮件地址。密码可通过以下两种方式之一生成：
通过对服务账号密钥 JSON 文件进行 base64 编码。
通过获取短期有效的访问令牌。
配置授权。客户端使用 SASL 成功进行身份验证后，其访问权限将由集群上 IAM 角色或 Kafka ACL 中定义的权限控制。
SASL 限制
SASL 身份验证方法具有以下限制：
SASL 身份验证与 IAM 主账号密不可分。它不适合需要严格分离Google Cloud 身份或使用非 Google 身份的组织，除非您配置工作负载身份联合。
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 池的资源标识符来启用 mTLS。我们还建议配置
ssl.principal.mapping.rules代理属性，以创建简化的正文名称，供 ACL 使用。您可以使用 Google Cloud CLI 命令执行此操作。配置 Kafka 客户端。从 CA 获取客户端证书，并将其安装在客户端环境中，例如 Java 密钥库中。然后，必须为客户端应用配置正确的安全协议 (SSL) 和密钥库位置，才能连接到集群的专用 mTLS 引导端口
9192。监控 mTLS。设置完成后，监控
managedkafka.googleapis.com/mtls_truststore_update_count指标，以验证集群是否成功从 CA 服务池刷新其 CA 证书（集群会定期尝试这样做）。您还可以使用 Cloud Logging。
mTLS 限制
mTLS 功能具有以下限制：
您只能在 2025 年 6 月 24 日之后创建的 Managed Service for Apache Kafka 集群上使用 mTLS 功能。
您必须使用 Kafka ACL 为 mTLS 主账号配置授权。 您无法使用 IAM 角色绑定来授权 mTLS 客户端。
该服务仅对提供由 CA Service 管理的证书的客户端进行身份验证。不过，您可以在 CA Service 中创建一个链接到外部 CA 的从属 CA，从而集成外部信任根。
您可以将集群配置为最多信任 10 个 CA 池。