5.4. 使用基于 OAuth 2.0 令牌的身份验证

1. Kafka 客户端使用客户端 ID 和 secret 从授权服务器请求访问令牌，以及可选的刷新令牌。
2. 授权服务器生成新的访问令牌。
3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递访问令牌。
4. Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
5. 如果令牌有效，则建立 Kafka 客户端会话。

1. Kafka 客户端使用令牌端点的授权服务器验证，使用客户端 ID 和 secret，以及可选的刷新令牌。
2. 授权服务器生成新的访问令牌。
3. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递访问令牌。
4. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。

1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递长期的访问令牌。
2. Kafka 代理使用自己的客户端 ID 和 secret 调用授权服务器上的令牌内省端点来验证访问令牌。
3. 如果令牌有效，则建立 Kafka 客户端会话。

1. Kafka 客户端使用 SASL OAUTHBEARER 机制通过 Kafka 代理进行身份验证，以传递长期的访问令牌。
2. Kafka 代理使用 JWT 令牌签名检查和本地令牌内省在本地验证访问令牌。

1. Kafka 客户端以用户名和 secret 作为密码通过 clientId。
2. Kafka 代理使用令牌端点将 clientId 和 secret 传递给授权服务器。
3. 如果客户端凭据无效，授权服务器会返回一个全新的访问令牌或错误。

4. Kafka 代理使用以下方法之一验证令牌：

   1. 如果指定了令牌内省端点，则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功，则会建立一个会话。
   2. 如果使用本地令牌内省，则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

1. Kafka 客户端通过用户名和密码。密码提供在运行客户端之前手动和配置的访问令牌的值。

2. 密码通过 或不使用 $accessToken: 字符串前缀传递，具体取决于 Kafka 代理监听程序配置了用于身份验证的令牌端点。

   1. 如果配置了令牌端点，密码应以 $accessToken: 前缀，以便代理知道 password 参数包含访问令牌而不是客户端 secret。Kafka 代理将用户名解释为帐户用户名。
   2. 如果没有在 Kafka 代理监听器上配置令牌端点（强制使用 no-client-credentials 模式），密码应该提供没有前缀的访问令牌。Kafka 代理将用户名解释为帐户用户名。在这个模式中，客户端不使用客户端 ID 和 secret，密码 参数始终被解释为原始访问令牌。

3. Kafka 代理使用以下方法之一验证令牌：

   1. 如果指定了令牌内省端点，则 Kafka 代理通过调用授权服务器上的端点来验证访问令牌。如果令牌验证成功，则会建立一个会话。
   2. 如果使用了本地令牌内省，则不会向授权服务器发出请求。Kafka 代理使用 JWT 令牌签名检查在本地验证访问令牌。

流程

1. 将授权服务器部署到集群中。

2. 访问授权服务器的 CLI 或管理控制台，以便为 AMQ Streams 配置 OAuth 2.0。

   现在，准备授权服务器以用于 AMQ Streams。

3. 配置 kafka-broker 客户端。
4. 为应用程序的每个 Kafka 客户端组件配置客户端。

流程

1. 在编辑器中更新 Kafka 资源的 Kafka 代理配置(Kafka.spec.kafka)。

   oc edit kafka my-cluster

   Copy to Clipboard Toggle word wrap

2. 配置 Kafka 代理 监听程序 配置。

   每种侦听器的配置不一定是相同的，因为它们是独立的。

   此处的示例显示了为外部监听器配置的配置选项。

   示例 1：配置快速本地 JWT 令牌验证

   #...
   - name: external
     port: 9094
     type: loadbalancer
     tls: true
     authentication:
       type: oauth 

   1

   
       validIssuerUri: <https://<auth-server-address>/auth/realms/external> 

   2

   
       jwksEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/certs> 

   3

   
       userNameClaim: preferred_username 

   4

   
       maxSecondsWithoutReauthentication: 3600 

   5

   
       tlsTrustedCertificates: 

   6

   
       - secretName: oauth-server-cert
         certificate: ca.crt
       disableTlsHostnameVerification: true 

   7

   
       jwksExpirySeconds: 360 

   8

   
       jwksRefreshSeconds: 300 

   9

   
       jwksMinRefreshPauseSeconds: 1 

   10

   Copy to Clipboard Toggle word wrap

   1

   侦听器类型设置为 oauth。

   2

   用于身份验证的令牌签发者的 URI。

   3

   用于本地 JWT 验证的 JWKS 证书端点的 URI。

   4

   在令牌中包含实际用户名的令牌声明（或密钥）。用户名是用于标识用户的 主体。userNameClaim 值将取决于身份验证流和使用的授权服务器。

   5

   （可选）激活 Kafka 重新身份验证机制，以强制实施与访问令牌相同的长度。如果指定值小于访问令牌过期的时间，那么客户端必须在实际令牌到期前重新进行身份验证。默认情况下，当访问令牌过期时，会话不会过期，客户端也不会尝试重新身份验证。

   6

   （可选）用于 TLS 连接授权服务器的可信证书。

   7

   （可选）禁用 TLS 主机名验证。默认为 false。

   8

   JWKS 证书在过期前被视为有效的持续时间。默认为 360 秒。如果您指定较长的时间，请考虑允许访问撤销证书的风险。

   9

   JWKS 证书刷新之间的周期。间隔必须至少的 60 秒少于到期间隔。默认值为 300 秒。

   10

   连续尝试刷新 JWKS 公钥之间的最短暂停时间（以秒为单位）。当遇到未知签名密钥时，JWKS 键刷新会在常规常规调度外调度，且至少在上次刷新后至少指定暂停。刷新键遵循 exponential backoff 规则，重试失败刷新，并增加暂停，直到它达到 jwksRefreshSeconds。默认值为 1。

   示例 2：使用内省端点配置令牌验证

   - name: external
     port: 9094
     type: loadbalancer
     tls: true
     authentication:
       type: oauth
       validIssuerUri: <https://<auth-server-address>/auth/realms/external>
       introspectionEndpointUri: <https://<auth-server-address>/auth/realms/external/protocol/openid-connect/token/introspect> 

   1

   
       clientId: kafka-broker 

   2

   
       clientSecret: 

   3

   
         secretName: my-cluster-oauth
         key: clientSecret
       userNameClaim: preferred_username 

   4

   
       maxSecondsWithoutReauthentication: 3600 

   5

   Copy to Clipboard Toggle word wrap

   1

   令牌内省端点的 URI。

   2

   用于标识客户端的客户端 ID。

   3

   客户端 Secret 和客户端 ID 用于身份验证。

   4

   在令牌中包含实际用户名的令牌声明（或密钥）。用户名是用于标识用户的 主体。userNameClaim 值将取决于所使用的授权服务器。

   5

   （可选）激活 Kafka 重新身份验证机制，以强制实施与访问令牌相同的长度。如果指定值小于访问令牌过期的时间，那么客户端必须在实际令牌到期前重新进行身份验证。默认情况下，当访问令牌过期时，会话不会过期，客户端也不会尝试重新身份验证。

   根据您应用 OAuth 2.0 身份验证以及授权服务器的类型，您可以使用额外的（可选）配置设置：

     # ...
     authentication:
       type: oauth
       # ...
       checkIssuer: false 

   1

   
       checkAudience: true 

   2

   
       fallbackUserNameClaim: client_id 

   3

   
       fallbackUserNamePrefix: client-account- 

   4

   
       validTokenType: bearer 

   5

   
       userInfoEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/userinfo 

   6

   
       enableOauthBearer: false 

   7

   
       enablePlain: true 

   8

   
       tokenEndpointUri: https://OAUTH-SERVER-ADDRESS/auth/realms/external/protocol/openid-connect/token 

   9

   
       customClaimCheck: "@.custom == 'custom-value'" 

   10

   
       clientAudience: AUDIENCE 

   11

   
       clientScope: SCOPE 

   12

   
       connectTimeoutSeconds: 60 

   13

   
       readTimeoutSeconds: 60 

   14

   
       groupsClaim: "$.groups" 

   15

   
       groupsClaimDelimiter: "," 

   16

   Copy to Clipboard Toggle word wrap

   1

   如果您的授权服务器不提供 声明，则无法执行签发者检查。在这种情况下，将 checkIssuer 设为 false，且不 指定有效的IssuerUri。默认为 true。

   2

   如果您的授权服务器 提供了一个ud (udience)申索，并且希望强制执行听众检查，则将 checkAudience 设置为 true。受众检查确定令牌的预期接收者。因此，Kafka 代理将拒绝在其 aud 声明中没有 clientId 的令牌。默认为 false。

   3

   授权服务器可能无法提供单一属性来识别常规用户和客户端。当客户端在其自己的名称中进行身份验证时，该服务器可能会提供 客户端 ID。当用户使用用户名和密码进行身份验证时，若要获取刷新令牌或访问令牌，服务器在客户端 ID 之外可能会提供 用户名 属性。如果主用户 ID 属性不可用，则使用此回退选项指定要使用的用户名声明(attribute)。

   4

   在适用 fallbackUserNameClaim 时，可能需要防止用户名声明的值和回退用户名声明之间的名称冲突。例如存在名为 producer 的客户端，但存在一个名为 producer 的普通用户。为了区分这两者，您可以使用此属性为客户端的用户 ID 添加前缀。

   5

   （仅适用于使用 introspectionEndpointUri）取决于您使用的授权服务器，内省端点可能会返回 令牌类型 属性，或者可能包含不同的值。您可以指定来自内省端点要包含的响应的有效令牌类型值。

   6

   （仅适用于使用 introspectionEndpointUri）授权服务器配置或实施，这样在 Introspection Endpoint 响应中不提供任何可识别的信息。要获取用户 ID，您可以将 userinfo 端点的 URI 配置为回退。userNameClaim、freUserNameClaim 和 fallbackUserNamePrefix 设置应用于 userinfo 端点的响应。

   7

   将其设置为 false，以禁用监听器上的 OAUTHBEARER 机制。必须至少启用 PLAIN 或 OAUTHBEARER 之一。默认为 true。

   8

   设置为 true，以在监听器上启用 PLAIN 身份验证，在所有平台上的客户端都受支持。

   9

   用于 PLAIN 机制的其他配置。如果指定，客户端可以使用 $accessToken: 前缀将访问令牌作为 密码 传递，通过 PLAIN 进行身份验证。对于生产环境，始终使用 https:// urls。

   10

   可以在验证过程中对 JWT 访问令牌实施额外的自定义规则，方法是将其设置为 JsonPath 过滤器查询。如果访问令牌不包含必要的数据，则会被拒绝。在使用 introspectionEndpointUri 时，自定义检查将应用到内省端点响应 JSON。

   11

   一个 audience 参数传递给令牌端点。在获取用于代理身份验证的访问令牌时，需要使用 使用者。它还使用在 PLAIN 客户端身份验证中使用 clientId 和 secret 的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力，以及令牌的内容，具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。

   12

   传递给令牌端点的 scope 参数。获取访问令牌进行代理身份验证时使用的 范围。它还使用在 PLAIN 客户端身份验证中使用 clientId 和 secret 的 OAuth 2.0 客户端名称。这只会影响获取令牌的能力，以及令牌的内容，具体取决于授权服务器。它不会受到监听程序影响令牌验证规则。

   13

   连接授权服务器时出现连接超时（以秒为单位）。默认值为 60。

   14

   连接到授权服务器时读取超时（以秒为单位）。默认值为 60。

   15

   JsonPath 查询，用于从 JWT 令牌或内省端点响应中提取组信息。默认情况下不设置。这可以由自定义授权者用来根据用户组做出授权决策。

   16

   以单个分隔字符串返回时用于解析组信息的分隔符。默认值为 ','(comma)。

3. 保存并退出编辑器，然后等待滚动更新完成。

4. 检查日志中的更新，或者查看 pod 状态转换：

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   Copy to Clipboard Toggle word wrap

   滚动更新将代理配置为使用 OAuth 2.0 身份验证。

流程

1. 将支持 OAuth 2.0 的客户端程序库添加到 Kafka 客户端的 pom.xml 文件中：

   <dependency>
    <groupId>io.strimzi</groupId>
    <artifactId>kafka-oauth-client</artifactId>
    <version>0.10.0.redhat-00014</version>
   </dependency>

   Copy to Clipboard Toggle word wrap

2. 为回调配置系统属性：

   例如：

   System.setProperty(ClientConfig.OAUTH_TOKEN_ENDPOINT_URI, “https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token”); 

   1

   
   System.setProperty(ClientConfig.OAUTH_CLIENT_ID, "<client_name>"); 

   2

   
   System.setProperty(ClientConfig.OAUTH_CLIENT_SECRET, "<client_secret>"); 

   3

   
   System.setProperty(ClientConfig.OAUTH_SCOPE, "<scope_value>") 

   4

   
   System.setProperty(ClientConfig.OAUTH_AUDIENCE, "<audience_value") 

   5

   Copy to Clipboard Toggle word wrap

   1

   授权服务器令牌端点的 URI。

   2

   客户端 ID，这是在授权服务器中创建 客户端 时使用的名称。

   3

   在授权服务器中创建 客户端 secret。

   4

   （可选）从令牌端点请求令牌 的范围。授权服务器可能需要客户端指定范围。

   5

   （可选 ） 用于从令牌端点请求令牌的使用者。授权服务器可能需要客户端指定受众。

3. 在 Kafka 客户端配置中，在 TLS 加密连接中启用 OAUTHBEARER 或 PLAIN 机制。

   例如：

   为 Kafka 客户端启用 OAUTHBEARER

   props.put("sasl.jaas.config", "org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;");
   props.put("security.protocol", "SASL_SSL");
   props.put("sasl.mechanism", "OAUTHBEARER");
   props.put("sasl.login.callback.handler.class", "io.strimzi.kafka.oauth.client.JaasClientOauthLoginCallbackHandler");

   Copy to Clipboard Toggle word wrap

   为 Kafka 客户端启用 PLAIN

   props.put("sasl.jaas.config", "org.apache.kafka.common.security.plain.PlainLoginModule required username=\"$CLIENT_ID_OR_ACCOUNT_NAME\" password=\"$SECRET_OR_ACCESS_TOKEN\" ;");
   props.put("security.protocol", "SASL_SSL"); 

   1

   
   props.put("sasl.mechanism", "PLAIN");

   Copy to Clipboard Toggle word wrap

   1

   此处我们使用 SASL_SSL 接管 TLS 连接。仅限本地开发使用 SASL_PLAINTEXT 而不是未加密的连接。

4. 验证 Kafka 客户端是否可以访问 Kafka 代理。

流程

1. 创建客户端 secret，并将其作为环境变量挂载到组件中。

   例如，我们为 Kafka Bridge 创建客户端 Secret ：

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Secret
   metadata:
    name: my-bridge-oauth
   type: Opaque
   data:
    clientSecret: MGQ1OTRmMzYtZTllZS00MDY2LWI5OGEtMTM5MzM2NjdlZjQw 

   1

   Copy to Clipboard Toggle word wrap

   1

   clientSecret 键必须采用 base64 格式。

2. 创建或编辑 Kafka 组件的资源，以便为身份验证属性配置 OAuth 2.0 身份验证。

   对于 OAuth 2.0 身份验证，您可以使用：

   • 客户端 ID 和 secret
   • 客户端 ID 和刷新令牌
   • 访问令牌
   • TLS

   KafkaClientAuthenticationOAuth 模式参考提供了每个 的示例。

   例如，这里的 OAuth 2.0 使用客户端 ID 和 secret 分配给 Kafka Bridge 客户端：

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     # ...
     authentication:
       type: oauth 

   1

   
       tokenEndpointUri: https://<auth-server-address>/auth/realms/master/protocol/openid-connect/token 

   2

   
       clientId: kafka-bridge
       clientSecret:
         secretName: my-bridge-oauth
         key: clientSecret
       tlsTrustedCertificates: 

   3

   
       - secretName: oauth-server-cert
         certificate: tls.crt

   Copy to Clipboard Toggle word wrap

   1

   身份验证类型设置为 oauth。

   2

   用于身份验证的令牌端点的 URI。

   3

   TLS 连接到授权服务器的可信证书。

   根据您应用 OAuth 2.0 身份验证以及授权服务器的类型，您可以使用其他配置选项：

   # ...
   spec:
     # ...
     authentication:
       # ...
       disableTlsHostnameVerification: true 

   1

   
       checkAccessTokenType: false 

   2

   
       accessTokenIsJwt: false 

   3

   
       scope: any 

   4

   
       audience: kafka 

   5

   
       connectTimeoutSeconds: 60 

   6

   
       readTimeoutSeconds: 60 

   7

   Copy to Clipboard Toggle word wrap

   1

   （可选）禁用 TLS 主机名验证。默认为 false。

   2

   如果授权服务器没有在 JWT 令牌中返回 typ （类型）声明，您可以应用 checkAccessTokenType: false 来跳过令牌类型检查。默认为 true。

   3

   如果使用不透明令牌，您可以应用 accessTokenIsJwt: false，以便访问令牌不会被视为 JWT 令牌。

   4

   （可选）从令牌端点请求令牌 的范围。授权服务器可能需要客户端指定范围。在这种情况下，它都是 any。

   5

   （可选 ） 用于从令牌端点请求令牌的使用者。授权服务器可能需要客户端指定受众。在本例中，是 kafka。

   6

   （可选）连接到授权服务器时连接超时（以秒为单位）。默认值为 60。

   7

   （可选）连接到授权服务器时读取超时（以秒为单位）。默认值为 60。

3. 将更改应用到 Kafka 资源的部署。

   oc apply -f your-file

   Copy to Clipboard Toggle word wrap

4. 检查日志中的更新，或者查看 pod 状态转换：

   oc logs -f ${POD_NAME} -c ${CONTAINER_NAME}
   oc get pod -w

   Copy to Clipboard Toggle word wrap

   滚动更新配置组件，以使用 OAuth 2.0 身份验证与 Kafka 代理交互。