红帽全球峰会14.4. 使用基于 OAuth 2.0 令牌的身份验证
AMQ Streams 支持使用 OAUTHBEARER 和 PLAIN 机制使用 OAuth 2.0 身份验证。
OAuth 2.0 启用应用程序之间的基于令牌的标准化身份验证和授权，使用中央授权服务器签发对资源有限访问权限的令牌。
您可以配置 OAuth 2.0 身份验证，然后配置 OAuth 2.0 授权。
Kafka 代理和客户端都需要配置为使用 OAuth 2.0。OAuth 2.0 身份验证也可以与基于 simple 或 OPA 的 Kafka 授权 一起使用。
使用基于 OAuth 2.0 令牌的身份验证时，应用程序客户端可以在不公开帐户凭据的情况下访问应用服务器（称为 资源服务器）上的资源。
应用程序客户端通过访问令牌作为身份验证方法传递，应用服务器也可以用来决定要授予的访问权限级别。授权服务器处理访问权限的授予和查询有关访问权限的查询。
在 AMQ Streams 的上下文中：
- Kafka 代理作为 OAuth 2.0 资源服务器
- Kafka 客户端充当 OAuth 2.0 应用程序客户端
Kafka 客户端在 Kafka 代理验证。代理和客户端根据需要与 OAuth 2.0 授权服务器通信，以获取或验证访问令牌。
对于 AMQ Streams 的部署，OAuth 2.0 集成提供：
- Kafka 代理的服务器端 OAuth 2.0 支持
- Kafka MirrorMaker、Kafka Connect 和 Kafka Bridge 的客户端 OAuth 2.0 支持
14.4.1. OAuth 2.0 身份验证机制
AMQ Streams 支持 OAUTHBEARER 和 PLAIN 机制进行 OAuth 2.0 身份验证。这两种机制都允许 Kafka 客户端与 Kafka 代理建立经过身份验证的会话。客户端、授权服务器和 Kafka 代理之间的身份验证流因每种机制而异。
我们建议您将客户端配置为尽可能使用 OAUTHBEARER。OAUTHBEARER 提供比 PLAIN 更高的安全性，因为客户端凭证不会与 Kafka 代理共享。考虑仅在不支持 OAUTHBEARER 的 Kafka 客户端中使用 PLAIN。
您可以将 Kafka 代理监听程序配置为使用 OAuth 2.0 身份验证来连接客户端。如果需要，您可以在同一 oauth 侦听器上使用 OAUTHBEARER 和 PLAIN 机制。支持每个机制的属性必须在 oauth 侦听器配置中明确指定。
OAUTHBEARER 概述
OAUTHBEARER 在 oauth 侦听器配置中自动启用用于 Kafka 代理。您可以将 enableOauthBearer 属性设置为 true，但这不是强制要求。
# ...
authentication:
type: oauth
# ...
enableOauthBearer: true
# ...
authentication:
type: oauth
# ...
enableOauthBearer: true许多 Kafka 客户端工具使用在协议级别为 OAUTHBEARER 提供基本支持的库。为了支持应用程序开发，AMQ Streams 为上游 Kafka Client Java 库（但不适用于其他库）提供了一个 OAuth 回调处理器。因此，您不需要自行编写回调处理程序。应用客户端可以使用回调处理程序来提供访问令牌。使用 Go 等其他语言编写的客户端必须使用自定义代码连接到授权服务器并获取访问令牌。
使用 OAUTHBEARER 时，客户端发起带有 Kafka 代理进行凭证交换的会话，其中凭证采用由回调处理器提供的 bearer 令牌的形式。使用回调，您可以以三种方式之一配置令牌置备：
- 客户端 ID 和 Secret （使用 OAuth 2.0 客户端凭证 机制）
- 一个长期的访问令牌，在配置时手动获取
- 一个长期的刷新令牌，在配置时手动获取
OAUTHBEARER 身份验证只能由支持协议级别的 OAUTHBEARER 机制的 Kafka 客户端使用。
PLAIN 概述
要使用 PLAIN，您必须在 oauth 侦听器配置中为 Kafka 代理启用它。
在以下示例中，除了 OAUTHBEARER 外，PLAIN 会被启用，这默认是启用的。如果只使用 PLAIN，您可以通过将 enableOauthBearer 设置为 false 来禁用 OAUTHBEARER。
PLAIN 是所有 Kafka 客户端工具使用的简单身份验证机制。要启用 PLAIN 以用于 OAuth 2.0 身份验证，AMQ Streams 提供了 OAuth 2.0 over PLAIN 服务器端的回调。
使用 PLAIN 的 AMQ Streams 实现，客户端凭证不会存储在 ZooKeeper 中。相反，客户端凭证会在兼容授权服务器后进行集中处理，这与使用 OAUTHBEARER 身份验证类似。
当与 OAuth 2.0 over PLAIN 回调一起使用时，Kafka 客户端使用以下方法之一与 Kafka 代理进行身份验证：
- 客户端 ID 和 secret （使用 OAuth 2.0 客户端凭证机制）
- 一个长期的访问令牌，在配置时手动获取
对于这两种方法，客户端必须提供 PLAIN username 和 password 属性，将凭证传递给 Kafka 代理。客户端使用这些属性传递客户端 ID 和 secret 或用户名和访问令牌。
客户端 ID 和 secret 用于获取访问令牌。
访问令牌作为 password 属性值传递。您可以使用或没有 $accessToken: 前缀来传递访问令牌。
-
如果您在监听器配置中配置令牌端点(
tokenEndpointUri)，则需要前缀。 -
如果您没有在监听器配置中配置令牌端点(
tokenEndpointUri)，则不需要前缀。Kafka 代理将密码解释为原始访问令牌。
如果将密码设置为访问令牌，则必须将用户名设置为 Kafka 代理从访问令牌获取的相同的主体名称。您可以使用 userNameClaim,fallbackUserNameClaim,fallbackUsernamePrefix, 和 userInfoEndpointUri 属性在监听器中指定用户名提取选项。用户名提取过程还取决于您的授权服务器；特别是，它将客户端 ID 映射到帐户名称。
OAuth over PLAIN 不支持 密码授权机制。您只能通过 SASL PLAIN 机制 'proxy' 来 包括客户端凭证 (clientId + secret)或访问令牌，如上所述。
14.4.2. OAuth 2.0 Kafka 代理配置
OAuth 2.0 的 Kafka 代理配置涉及：
- 在授权服务器中创建 OAuth 2.0 客户端
- 在 Kafka 自定义资源中配置 OAuth 2.0 身份验证
与授权服务器的关系，Kafka 代理和 Kafka 客户端都被视为 OAuth 2.0 客户端。
14.4.2.1. 授权服务器上的 OAuth 2.0 客户端配置
要配置 Kafka 代理以验证会话启动期间收到的令牌，建议的做法是在授权服务器中创建一个 OAuth 2.0 client 定义（配置为 confidential），并启用了以下客户端凭证：
-
客户端 ID
kafka（例如） - 客户端 ID 和 Secret 作为身份验证机制
在使用授权服务器的非公共内省端点时，您只需要使用客户端 ID 和 secret。在使用公共授权服务器端点时，通常不需要凭据，如快速本地 JWT 令牌验证一样。
14.4.2.2. Kafka 集群中的 OAuth 2.0 身份验证配置
要在 Kafka 集群中使用 OAuth 2.0 身份验证，例如，使用验证方法 oauth 指定 Kafka 集群自定义资源的 tls 侦听器配置：
评估 OAuth 2.0 的身份验证方法类型
您可以在监听器中配置 OAuth 2.0 身份验证。我们建议将 OAuth 2.0 身份验证与 TLS 加密一起使用(tls: true)。如果没有加密，连接容易通过令牌保护和未经授权的访问。
您可以使用 type: oauth 为安全传输层配置 外部监听程序，以便与客户端通信。
使用带有外部监听程序的 OAuth 2.0
tls 属性默认为 false，因此必须启用它。
当您将验证类型定义为 OAuth 2.0 时，您可以根据验证类型添加配置，可以是 fast local JWT validation 或 token validation using an introspection endpoint。
为监听器配置 OAuth 2.0 的步骤带有描述和示例，请参考为 Kafka 代理配置 OAuth 2.0 支持。
14.4.2.3. 快速的本地 JWT 令牌验证配置
快速本地 JWT 令牌验证会在本地检查 JWT 令牌签名。
本地检查可确保令牌：
-
使用一个访问令牌的
Bearer的(typ)声明值符合类型 - 有效（未过期）
-
具有与
validIssuerURI匹配的签发者
在配置监听器时，您可以指定 validIssuerURI 属性，以便任何未由授权服务器发布的令牌都会被拒绝。
授权服务器不需要在快速本地 JWT 令牌验证过程中联系。您可以通过指定 jwksEndpointUri 属性（由 OAuth 2.0 授权服务器公开的端点）来激活快速本地 JWT 令牌验证。端点包含验证已签名的 JWT 令牌的公钥，这些令牌由 Kafka 客户端作为凭证发送。
所有与授权服务器通信都应使用 TLS 加密来执行。
您可以将证书信任存储配置为 AMQ Streams 项目命名空间中的 OpenShift Secret，并使用 tlsTrustedCertificates 属性指向包含信任存储文件的 OpenShift Secret。
您可能希望配置 userNameClaim 以正确提取 JWT 令牌中的用户名。如果需要，您可以使用 JsonPath 表达式，如 "['user.info'].['user.id']"，从令牌中的嵌套 JSON 属性检索用户名。
如果要使用 Kafka ACL 授权，则需要在身份验证过程中使用用户名来识别用户。( JWT 令牌中的 子 声明通常是唯一 ID，而不是用户名。)
快速本地 JWT 令牌验证配置示例
14.4.2.4. OAuth 2.0 内省端点配置
使用 OAuth 2.0 内省端点进行令牌验证会将接收的访问令牌视为不透明。Kafka 代理向内省端点发送访问令牌，该端点使用验证所需的令牌信息做出响应。最重要的是，如果特定访问令牌有效，它会返回最新的信息，以及令牌何时过期的信息。
要配置基于 OAuth 2.0 内省的验证，您可以指定一个 introspectionEndpointUri 属性，而不是为快速本地 JWT 令牌验证指定的 jwksEndpointUri 属性。根据授权服务器，通常必须指定 clientId 和 clientSecret，因为内省端点通常受到保护。
内省端点配置示例
14.4.3. Kafka 代理的会话重新身份验证
您可以将 oauth 监听程序配置为对 Kafka 客户端和 Kafka 代理之间的 OAuth 2.0 会话使用 Kafka 会话重新身份验证。这个机制在定义的时间后强制实施客户端和代理之间经过身份验证的会话的过期。当会话过期时，客户端会立即通过重复使用现有连接而不是丢弃它来启动新的会话。
会话重新身份验证默认为禁用。要启用它，您可以在 oauth 侦听器配置中为 maxSecondsWithoutReauthentication 设置时间值。相同的属性用于为 OAUTHBEARER 和 PLAIN 身份验证配置会话重新身份验证。有关配置示例，请参阅 第 14.4.6.2 节 “为 Kafka 代理配置 OAuth 2.0 支持”。
会话重新身份验证必须由客户端使用的 Kafka 客户端库支持。
会话重新身份验证可用于快速 本地 JWT 或 内省端点 令牌验证。
客户端重新身份验证
当代理的经过身份验证的会话过期时，客户端必须通过向代理发送一个新的有效访问令牌来重新验证到现有会话，而无需丢弃连接。
如果令牌验证成功，则使用现有连接启动新的客户端会话。如果客户端无法重新验证，代理会在进一步尝试发送或接收消息时关闭连接。如果代理上启用了重新身份验证机制，则使用 Kafka 客户端库 2.2 或更高版本的 Java 客户端会自动重新验证。
如果使用，会话重新身份验证也适用于刷新令牌。当会话过期时，客户端会使用其刷新令牌来刷新访问令牌。然后，客户端使用新的访问令牌重新验证现有会话。
OAUTHBEARER 和 PLAIN 的会话到期
配置会话重新身份验证后，会话到期对于 OAUTHBEARER 和 PLAIN 身份验证是不同的。
对于 OAUTHBEARER 和 PLAIN，使用客户端 ID 和 secret 方法：
-
代理的经过身份验证的用户会话将在配置的
maxSeconds withoutReauthentication下过期。 - 如果访问令牌在配置的时间前过期，会话将提前过期。
对于 PLAIN，使用长期访问令牌方法：
-
代理的经过身份验证的用户会话将在配置的
maxSeconds withoutReauthentication下过期。 - 如果访问令牌在配置的时间前过期，则重新身份验证将失败。虽然尝试尝试会话重新身份验证，但 PLAIN 没有刷新令牌的机制。
如果没有配置 maxSecondsWithoutReauthentication，OAUTHBEARER 和 PLAIN 客户端可以无限期地连接到代理，而无需重新验证。经过身份验证的会话不会因为访问令牌到期而终止。但是，这可在配置授权时考虑，例如，使用 keycloak 授权或安装自定义授权器。
14.4.4. OAuth 2.0 Kafka 客户端配置
Kafka 客户端被配置为：
- 从授权服务器获取有效访问令牌（客户端 ID 和 Secret）所需的凭证
- 使用授权服务器提供的工具获取有效的长期访问令牌或刷新令牌
发送到 Kafka 代理的唯一信息是访问令牌。用于与授权服务器进行身份验证的凭证从不会发送到代理。
当客户端获取访问令牌时，不需要进一步与授权服务器通信。
最简单的机制是使用客户端 ID 和 Secret 进行身份验证。使用长期的访问令牌或长期的刷新令牌会增加复杂性，因为对授权服务器工具还有额外的依赖。
如果您使用长期的访问令牌，您可能需要在授权服务器中配置客户端来提高令牌的最大生命周期。
如果 Kafka 客户端没有直接配置访问令牌，客户端会在 Kafka 会话发起授权服务器的过程中交换访问令牌的凭证。Kafka 客户端交换：
- 客户端 ID 和 Secret
- 客户端 ID、刷新令牌和（可选）secret
- 使用客户端 ID 和（可选）secret 的用户名和密码
14.4.5. OAuth 2.0 客户端身份验证流
OAuth 2.0 身份验证流程取决于底层 Kafka 客户端和 Kafka 代理配置。流还必须由使用的授权服务器支持。
Kafka 代理监听程序配置决定客户端如何使用访问令牌进行身份验证。客户端可以传递客户端 ID 和机密来请求访问令牌。
如果侦听器配置为使用 PLAIN 身份验证，客户端可以通过客户端 ID 和 secret 或用户名和访问令牌进行身份验证。这些值作为 PLAIN 机制 username 和 password 属性传递。
侦听器配置支持以下令牌验证选项：
- 您可以根据 JWT 签名检查和本地令牌内省使用快速本地令牌验证，而无需联系授权服务器。授权服务器提供带有公共证书的 JWKS 端点，用于验证令牌中的签名。
- 您可以使用调用授权服务器提供的令牌内省端点。每次建立新的 Kafka 代理连接时，代理会将从客户端接收的访问令牌传递给授权服务器。Kafka 代理检查响应，以确认令牌是否有效。
授权服务器可能只允许使用不透明访问令牌，这意味着无法进行本地令牌验证。
也可以为以下类型的身份验证配置 Kafka 客户端凭证：
- 使用之前生成的长期访问令牌直接进行本地访问
- 与授权服务器联系，以获取要发布的新访问令牌（使用客户端 ID 和 secret，或刷新令牌，或者用户名和密码）
14.4.5.1. 使用 SASL OAUTHBEARER 机制的客户端身份验证流示例
您可以使用 SASL OAUTHBEARER 机制为 Kafka 身份验证使用以下通信流。
使用客户端 ID 和 secret 的客户端以及代理委派到授权服务器的验证
- Kafka 客户端使用客户端 ID 和 secret 从授权服务器请求访问令牌，以及可选的刷新令牌。或者，客户端也可以使用用户名和密码进行身份验证。
- 授权服务器生成新的访问令牌。
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递访问令牌。
- Kafka 代理通过使用自己的客户端 ID 和 secret，在授权服务器上调用令牌内省端点来验证访问令牌。
- 如果令牌有效，则会建立 Kafka 客户端会话。
使用客户端 ID 和 secret 的客户端，代理执行快速本地令牌验证
- Kafka 客户端使用令牌端点、使用客户端 ID 和 secret 以及刷新令牌（可选）从令牌端点验证。或者，客户端也可以使用用户名和密码进行身份验证。
- 授权服务器生成新的访问令牌。
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递访问令牌。
- Kafka 代理使用 JWT 令牌签名检查和本地令牌内省验证访问令牌。
使用长期访问令牌的客户端，带有代理委派验证到授权服务器
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递长期访问令牌。
- Kafka 代理通过使用自己的客户端 ID 和 secret，在授权服务器上调用令牌内省端点来验证访问令牌。
- 如果令牌有效，则会建立 Kafka 客户端会话。
使用长期访问令牌的客户端，代理执行快速本地验证
- Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递长期访问令牌。
- Kafka 代理使用 JWT 令牌签名检查和本地令牌内省验证访问令牌。
快速的本地 JWT 令牌签名验证仅适用于短期的令牌，因为如果已撤销令牌，就不会通过授权服务器检查该授权服务器。令牌到期时间写入到令牌，但可以随时进行撤销，因此不能在不联系授权服务器的情况下被考虑。任何发布的令牌都将被视为有效，直到过期为止。
14.4.5.2. 使用 SASL PLAIN 机制的客户端身份验证流示例
您可以使用 OAuth PLAIN 机制对 Kafka 身份验证使用以下通信流。
使用客户端 ID 和 secret 的客户端以及代理获取客户端的访问令牌
-
Kafka 客户端或传递一个
clientId作为用户名，以及一个secret作为密码。 -
Kafka 代理使用令牌端点将
clientId和secret传递给授权服务器。 - 如果客户端凭据无效，授权服务器会返回一个新的访问令牌或错误。
Kafka 代理使用以下方法之一验证令牌：
- 如果指定了令牌内省端点，Kafka 代理会通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功，则会建立会话。
- 如果使用本地令牌内省，则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。
使用没有客户端 ID 和 secret 的长期访问令牌的客户端
- Kafka 客户端会传递用户名和密码。密码提供在运行客户端前手动配置的访问令牌值。
密码通过或不使用
$accessToken:字符串前缀来传递，具体取决于 Kafka 代理侦听程序是否配置了令牌端点来进行身份验证。-
如果配置了令牌端点，则密码应加上前缀
$accessToken:，以便代理知道 password 参数包含访问令牌，而不是客户端 secret。Kafka 代理将用户名解释为帐户用户名。 -
如果没有在 Kafka 代理监听程序上配置令牌端点（强制
no-client-credentials 模式），则密码应在没有前缀的情况下提供访问令牌。Kafka 代理将用户名解释为帐户用户名。在这个模式中，客户端不使用客户端 ID 和 secret，password参数始终解释为原始访问令牌。
-
如果配置了令牌端点，则密码应加上前缀
Kafka 代理使用以下方法之一验证令牌：
- 如果指定了令牌内省端点，Kafka 代理会通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功，则会建立会话。
- 如果使用本地令牌内省，则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。
14.4.6. 配置 OAuth 2.0 身份验证
OAuth 2.0 用于在 Kafka 客户端和 AMQ Streams 组件间交互。
要将 OAuth 2.0 用于 AMQ Streams，您必须：
14.4.6.1. 配置 OAuth 2.0 授权服务器
此流程描述了一般需要配置授权服务器以与 AMQ Streams 集成的内容。
这些说明不特定于产品。
这些步骤取决于所选的授权服务器。有关如何设置 OAuth 2.0 访问的信息，请参阅产品文档的授权服务器。
如果您已经部署了授权服务器，您可以跳过部署步骤并使用您的当前部署。
流程
- 将授权服务器部署到集群中。
访问授权服务器的 CLI 或管理控制台，以便为 AMQ Streams 配置 OAuth 2.0。
现在，准备授权服务器以用于 AMQ Streams。
-
配置
kafka-broker客户端。 - 为应用程序的每个 Kafka 客户端组件配置客户端。
接下来要做什么
部署和配置授权服务器后，将 Kafka 代理配置为使用 OAuth 2.0。
14.4.6.2. 为 Kafka 代理配置 OAuth 2.0 支持
此流程描述了如何配置 Kafka 代理，以便代理监听程序可以使用授权服务器使用 OAuth 2.0 身份验证。
我们建议通过一个带有 tls: true 的监听程序在加密接口上使用 OAuth 2.0。不建议使用 plain 监听程序。
如果授权服务器使用由可信 CA 签名的证书并匹配 OAuth 2.0 服务器主机名，则 TLS 连接可以使用默认设置。否则，您可能需要使用正确的证书或禁用证书主机名验证来配置信任存储。
在配置 Kafka 代理时，有两个选项用于在新连接的 Kafka 客户端的 OAuth 2.0 身份验证过程中验证访问令牌：
开始前
有关为 Kafka 代理监听程序配置 OAuth 2.0 身份验证的更多信息，请参阅：
先决条件
- AMQ Streams 和 Kafka 正在运行
- 部署 OAuth 2.0 授权服务器
流程
在编辑器中更新
Kafka资源的 Kafka 代理配置(Kafka.spec.kafka)。oc edit kafka my-cluster
oc edit kafka my-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 配置 Kafka 代理
监听程序配置。每种侦听器的配置不必相同，因为它们相互独立。
此处的示例显示了为外部监听器配置的配置选项。
示例 1：配置快速本地 JWT 令牌验证
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 侦听器类型设置为
oauth。 - 2
- 用于身份验证的令牌签发者的 URI。
- 3
- 用于本地 JWT 验证的 JWKS 证书端点的 URI。
- 4
- 包含用于识别用户的实际用户名的令牌声明（或密钥）。其值取决于授权服务器。如有必要，可以使用类似
"['user.info'].['user.id']"的 JsonPath 表达式，从令牌内的嵌套 JSON 属性检索用户名。 - 5
- （可选）激活 Kafka 重新验证机制，该机制强制会话到期时间与访问令牌相同的长度。如果指定的值小于访问令牌保留的时间，则客户端必须在实际令牌到期前重新验证。默认情况下，当访问令牌过期时，会话不会过期，客户端也不会尝试重新身份验证。
- 6
- （可选）与授权服务器进行 TLS 连接的可信证书。
- 7
- （可选）禁用 TLS 主机名验证。默认为
false。 - 8
- JWKS 证书在过期前被视为有效。默认为
360秒。如果您指定了较长的时间，请考虑允许访问撤销的证书的风险。 - 9
- JWKS 证书刷新之间的周期。间隔必须至少超过到期间隔的 60 秒。默认值为
300秒。 - 10
- 连续尝试刷新 JWKS 公钥之间的最小暂停（以秒为单位）。当遇到未知签名密钥时，JWKS 密钥刷新在常规定期调度后调度，且至少在最后一次刷新尝试后出现指定暂停。刷新密钥遵循 exponential backoff 规则，重试不成功刷新，且持续增加暂停，直到它到达
jwksRefreshSeconds为止。默认值为 1。
示例 2：使用内省端点配置令牌验证
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 根据您如何应用 OAuth 2.0 身份验证和授权服务器类型，您可以使用额外的（可选）配置设置：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 如果您的授权服务器不提供
iss声明，则无法执行签发者检查。在这种情况下，将checkIssuer设置为false，且不指定validIssuerUri。默认为true。 - 2
- 如果您的授权服务器提供
aud(audience)声明，并且希望强制进行受众检查，请将checkAudience设置为true。Audience 检查标识令牌的预期接收者。因此，Kafka 代理将拒绝在其aud声明中没有clientId的令牌。默认为false。 - 3
- 授权服务器可能无法提供单个属性来识别常规用户和客户端。当客户端以自己的名称进行身份验证时，服务器可能会提供 客户端 ID。当用户使用用户名和密码进行身份验证来获取刷新令牌或访问令牌时，除了客户端 ID 外，服务器可能会提供一个 username 属性。如果主用户 ID 属性不可用，则使用这个 fallback 选项指定要使用的用户名声明(attribute)。如有必要，可以使用 JsonPath 表达式（如
"['client.info'].['client.id']"来检索回退用户名，以从令牌内嵌套的 JSON 属性检索用户名。 - 4
- 在适用
fallbackUserNameClaim时，可能还需要防止用户名声明的值和回退用户名声明之间的名称冲突。请考虑存在名为producer的客户端存在的情况，但也存在名为producer的常规用户。为了区分这两者，您可以使用此属性向客户端的用户 ID 添加前缀。 - 5
- （仅在使用
introspectionEndpointUri时适用）取决于您使用的授权服务器，内省端点可能会或不返回 令牌类型 属性，或者可以包含不同的值。您可以指定来自内省端点的响应必须包含有效的令牌类型值。 - 6
- （仅在使用
introspectionEndpointUri时适用）授权服务器可以配置或实施，以便在 Introspection Endpoint 响应中提供任何可识别的信息。要获取用户 ID，您可以将userinfo端点的 URI 配置为回退。userNameClaim、fallbackUserNameClaim和fallbackUserNamePrefix设置应用于userinfo端点的响应。 - 7
- 把它设置为
false，以禁用侦听器上的 OAUTHBEARER 机制。至少需要启用 PLAIN 或 OAUTHBEARER 之一。默认为true。 - 8
- 设置为
true，以便在侦听器上启用 PLAIN 身份验证，该监听程序支持所有平台上的客户端。 - 9
- PLAIN 机制的其他配置。如果指定，客户端可以通过在使用
$accessToken:前缀将访问令牌作为密码传递来通过 PLAIN 进行身份验证。对于生产环境，请始终使用https://urls。 - 10
- 可以通过将其设置为 JsonPath 过滤器查询，在验证过程中对 JWT 访问令牌实施其他自定义规则。如果访问令牌不包含必要的数据，它将被拒绝。使用
introspectionEndpointUri时，自定义检查将应用到内省端点响应 JSON。 - 11
- 一个
audience参数传递给令牌端点。在获取用于代理身份验证的访问令牌时，需要使用 audience。它还在使用clientId和secret的 PLAIN 客户端验证中用于 OAuth 2.0 的客户端名称。这只会影响获取令牌的能力，以及令牌的内容，具体取决于授权服务器。它不会影响监听器的令牌验证规则。 - 12
- 传递给令牌端点的
scope参数。获取访问令牌进行代理身份验证时使用的 scope。它还在使用clientId和secret的 PLAIN 客户端验证中用于 OAuth 2.0 的客户端名称。这只会影响获取令牌的能力，以及令牌的内容，具体取决于授权服务器。它不会影响监听器的令牌验证规则。 - 13
- 连接到授权服务器时的连接超时（以秒为单位）。默认值为 60。
- 14
- 连接到授权服务器时读取超时（以秒为单位）。默认值为 60。
- 15
- 将失败的 HTTP 请求重试到授权服务器的次数上限。默认值为
0，表示不会执行重试。要有效地使用这个选项，请考虑减少connectTimeoutSeconds和readTimeoutSeconds选项的超时时间。但请注意，重试可能会阻止当前 worker 线程可用于其他请求，如果太多请求停滞，则可能会导致 Kafka 代理无响应。 - 16
- 尝试另一个到授权服务器的 HTTP 请求重试前等待的时间。默认情况下，这个时间被设置为零，这意味着不会应用暂停。这是因为导致失败请求的许多问题是针对每个请求的网络粘合或代理问题，可以快速解决。但是，如果您的授权服务器处于压力下或高流量，您可能希望将此选项设置为值 100 ms 或更多，以减少服务器上的负载，并增加成功重试的可能性。
- 17
- 用于从 JWT 令牌或内省端点响应中提取组信息的 JsonPath 查询。默认不设置这个选项。通过配置此选项，自定义授权器可以根据用户组做出授权决策。
- 18
- 当作为单一分隔的字符串返回时，用于解析组信息的分隔符。默认值为 ','(comma)。
- 19
- 有些授权服务器在客户端发送
Accept: application/json标头时遇到问题。通过设置includeAcceptHeader: false，不会发送标头。默认为true。
- 保存并退出编辑器，然后等待滚动更新完成。
检查日志中的更新，或通过监视 pod 状态转换：
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -woc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow 滚动更新将代理配置为使用 OAuth 2.0 身份验证。
接下来要做什么
14.4.6.3. 将 Kafka Java 客户端配置为使用 OAuth 2.0
配置 Kafka producer 和消费者 API，以使用 OAuth 2.0 与 Kafka 代理交互。在客户端 pom.xml 文件中添加回调插件，然后为 OAuth 2.0 配置您的客户端。
在客户端配置中指定以下内容：
SASL （简单身份验证和安全层）安全协议：
-
SASL_SSL用于通过 TLS 加密连接进行身份验证 SASL_PLAINTEXT用于通过未加密的连接进行身份验证将
SASL_SSL用于生产环境，SASL_PLAINTEXT仅用于本地开发。使用SASL_SSL时，需要额外的ssl.truststore配置。安全连接(https://)需要 truststore 配置到 OAuth 2.0 授权服务器。要验证 OAuth 2.0 授权服务器，请将授权服务器的 CA 证书添加到客户端配置的信任存储中。您可以使用 PEM 或 PKCS #12 格式配置信任存储。
-
Kafka SASL 机制：
-
OAUTHBEARER用于使用 bearer 令牌交换的凭证 -
PLAIN传递客户端凭证(clientId + secret)或访问令牌
-
实现 SASL 机制的 JAAS (Java 身份验证和授权服务)模块：
-
org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule实现 OAuthbearer 机制 -
org.apache.kafka.common.security.plain.PlainLoginModule实现普通机制
为了可以使用 OAuthbearer 机制，还必须将自定义
io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler类添加为回调处理程序。JaasClientOauthLoginCallbackHandler处理 OAuth 回调到授权服务器，以便在客户端登录期间处理访问令牌。这可启用自动令牌续订，确保在用户不干预的情况下进行持续身份验证。另外，它使用 OAuth 2.0 密码授权方法为客户端处理登录凭证。-
SASL 验证方法，它支持以下验证方法：
- OAuth 2.0 客户端凭证
- OAuth 2.0 密码授权（已弃用）
- 访问令牌
- 刷新令牌
将 SASL 身份验证属性添加为 JAAS 配置 (
sasl.jaas.config和sasl.login.callback.handler.class)。如何配置身份验证属性取决于您用来访问 OAuth 2.0 授权服务器的身份验证方法。在此过程中，属性在属性文件中指定，然后加载到客户端配置中。
您还可以将身份验证属性指定为环境变量，或指定为 Java 系统属性。对于 Java 系统属性，您可以使用 setProperty 设置它们，并使用 -D 选项在命令行中传递它们。
先决条件
- AMQ Streams 和 Kafka 正在运行
- 部署和配置 OAuth 2.0 授权服务器以 OAuth 访问 Kafka 代理
- 为 OAuth 2.0 配置 Kafka 代理
流程
将支持 OAuth 2.0 的客户端库添加到 Kafka 客户端的
pom.xml文件中：<dependency> <groupId>io.strimzi</groupId> <artifactId>kafka-oauth-client</artifactId> <version>0.14.0.redhat-00006</version> </dependency>
<dependency> <groupId>io.strimzi</groupId> <artifactId>kafka-oauth-client</artifactId> <version>0.14.0.redhat-00006</version> </dependency>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过在属性文件中指定以下配置来配置客户端属性：
- 安全协议
- SASL 机制
JAAS 模块和身份验证属性，具体取决于所使用的方法
例如，我们可以将以下内容添加到
client.properties文件中：客户端凭证机制属性
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SASL_SSL安全协议用于 TLS 加密连接。仅对本地开发使用SASL_PLAINTEXT。- 2
- 指定为
OAUTHBEARER或PLAIN的 SASL 机制。 - 3
- 用于安全访问 Kafka 集群的 truststore 配置。
- 4
- 授权服务器令牌端点的 URI。
- 5
- 客户端 ID，这是在授权服务器中创建客户端时使用的名称。
- 6
- 在授权服务器中创建客户端时创建的 客户端 secret。
- 7
- 该位置包含授权服务器的公钥证书(
truststore.p12)。 - 8
- 用于访问 truststore 的密码。
- 9
- truststore 类型。
- 10
- （可选）从令牌端点请求令牌的
范围。授权服务器可能需要客户端来指定范围。 - 11
- （可选）从令牌端点请求令牌的
听众。授权服务器可能需要客户端来指定受众。
密码授予机制属性
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 访问令牌属性
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Kafka 客户端长期的访问令牌。
刷新令牌属性
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在 Java 客户端代码中输入 OAUTH 2.0 身份验证的客户端属性。
显示客户端属性输入示例
Properties props = new Properties(); try (FileReader reader = new FileReader("client.properties", StandardCharsets.UTF_8)) { props.load(reader); }Properties props = new Properties(); try (FileReader reader = new FileReader("client.properties", StandardCharsets.UTF_8)) { props.load(reader); }Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 验证 Kafka 客户端是否可以访问 Kafka 代理。
14.4.6.4. 为 Kafka 组件配置 OAuth 2.0
此流程描述了如何将 Kafka 组件配置为使用授权服务器使用 OAuth 2.0 身份验证。
您可以为以下配置身份验证：
- Kafka Connect
- Kafka MirrorMaker
- Kafka Bridge
在这种情况下，Kafka 组件和授权服务器在同一集群中运行。
开始前
有关为 Kafka 组件配置 OAuth 2.0 身份验证的更多信息，请参阅 KafkaClientAuthenticationOAuth 模式参考。schema 引用包括配置选项示例。
先决条件
- AMQ Streams 和 Kafka 正在运行
- 部署和配置 OAuth 2.0 授权服务器以 OAuth 访问 Kafka 代理
- 为 OAuth 2.0 配置 Kafka 代理
流程
创建客户端 secret，并将它作为环境变量挂载到组件。
例如，这里为 Kafka Bridge 创建客户端
Secret：Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
clientSecret密钥必须采用 base64 格式。
创建或编辑 Kafka 组件的资源，以便为身份验证属性配置 OAuth 2.0 身份验证。
对于 OAuth 2.0 身份验证，您可以使用以下选项：
- 客户端 ID 和 secret
- 客户端 ID 和刷新令牌
- 访问令牌
- 用户名和密码
- TLS
例如，以下 OAuth 2.0 使用客户端 ID 和 secret 和 TLS 分配给 Kafka Bridge 客户端：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 根据您如何应用 OAuth 2.0 身份验证以及授权服务器类型，您可以使用其他配置选项：
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- （可选）禁用 TLS 主机名验证。默认为
false。 - 2
- 如果授权服务器没有在 JWT 令牌内返回
typ（类型）声明，您可以应用checkAccessTokenType: false来跳过令牌类型检查。默认为true。 - 3
- 如果使用不透明令牌，您可以应用
accessTokenIsJwt: false，以便访问令牌不被视为 JWT 令牌。 - 4
- （可选）从令牌端点请求令牌的
范围。授权服务器可能需要客户端来指定范围。在这种情况下，它都是any。 - 5
- （可选）从令牌端点请求令牌的
听众。授权服务器可能需要客户端来指定受众。在本例中，是kafka。 - 6
- （可选）连接到授权服务器时的连接超时（以秒为单位）。默认值为 60。
- 7
- （可选）连接到授权服务器时读取超时（以秒为单位）。默认值为 60。
- 8
- （可选）重试对授权服务器的失败 HTTP 请求的次数上限。默认值为
0，表示不会执行重试。要有效地使用这个选项，请考虑减少connectTimeoutSeconds和readTimeoutSeconds选项的超时时间。但请注意，重试可能会阻止当前 worker 线程可用于其他请求，如果太多请求停滞，则可能会导致 Kafka 代理无响应。 - 9
- （可选）尝试对授权服务器进行另一个重试失败的 HTTP 请求前等待的时间。默认情况下，这个时间被设置为零，这意味着不会应用暂停。这是因为导致失败请求的许多问题是针对每个请求的网络粘合或代理问题，可以快速解决。但是，如果您的授权服务器处于压力下或高流量，您可能希望将此选项设置为值 100 ms 或更多，以减少服务器上的负载，并增加成功重试的可能性。
- 10
- （可选）有些授权服务器在客户端发送
Accept: application/json标头时遇到问题。通过设置includeAcceptHeader: false，不会发送标头。默认为true。
将更改应用到 Kafka 资源的部署。
oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow 检查日志中的更新，或通过监视 pod 状态转换：
oc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -woc logs -f ${POD_NAME} -c ${CONTAINER_NAME} oc get pod -wCopy to Clipboard Copied! Toggle word wrap Toggle overflow 滚动更新配置组件，以使用 OAuth 2.0 身份验证与 Kafka 代理交互。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}