6.8. 使用基于 OAuth 2.0 令牌的授权
Apache Kafka 的流支持通过 Red Hat Single Sign-On Authorization Services 使用基于 OAuth 2.0 令牌的授权,它允许您集中管理安全策略和权限。
Red Hat Single Sign-On 中定义的安全策略和权限用于授予对 Kafka 代理上资源的访问权限。用户和客户端与允许对 Kafka 代理执行特定操作的策略进行匹配。
Kafka 允许所有用户默认对代理进行完全访问,并提供 AclAuthorizer
和 StandardAuthorizer
插件来配置基于访问控制列表(ACL)的授权。由这些插件管理的 ACL 规则用于根据 用户名 授予或拒绝对资源的访问,这些规则存储在 Kafka 集群本身中。但是,红帽单点登录基于 OAuth 2.0 令牌的授权在您希望实现对 Kafka 代理的访问控制方面具有更大的灵活性。另外,您可以将 Kafka 代理配置为使用 OAuth 2.0 授权和 ACL。
6.8.1. OAuth 2.0 授权机制
Apache Kafka 的 Streams 中的 OAuth 2.0 授权使用 Red Hat Single Sign-On 服务器授权服务 REST 端点通过 Red Hat Single Sign-On 扩展基于令牌的身份验证,通过在特定用户上应用定义的安全策略来扩展基于令牌的权限,并为该用户提供授予不同资源的权限列表。策略使用角色和组来匹配用户的权限。OAuth 2.0 授权根据从 Red Hat Single Sign-On Authorization Services 用户获得的授予者列表在本地强制实施权限。
6.8.1.1. Kafka 代理自定义授权器
Red Hat Single Sign-On authorizer (KeycloakAuthorizer
)提供 Apache Kafka 的 Streams。为了可以使用 Red Hat Single Sign-On 提供的授权服务的 Red Hat Single Sign-On REST 端点,您可以在 Kafka 代理上配置自定义授权器。
授权程序根据需要从授权服务器获取授予权限的列表,并在 Kafka Broker 上本地强制实施授权,为每个客户端请求做出快速授权决策。
6.8.2. 配置 OAuth 2.0 授权支持
这个步骤描述了如何使用 Red Hat Single Sign-On Authorization Services 将 Kafka 代理配置为使用 OAuth 2.0 授权服务。
开始前
考虑某些用户所需的访问权限或希望限制某些用户。您可以使用 Red Hat Single Sign-On 组、角色、客户端 和 用户在 Red Hat Single Sign-On 中配置访问权限的组合。
通常,组用于根据机构部门或地理位置匹配用户。和 角色用于根据其功能匹配用户。
使用红帽单点登录,您可以在 LDAP 中存储用户和组,而客户端和角色不能以这种方式存储。存储和对用户数据的访问可能是您选择配置授权策略的一个因素。
无论在 Kafka 代理上实现的授权是什么,超级用户始终对 Kafka 代理具有不受限制的访问。
先决条件
- Apache Kafka 的流必须配置为在 Red Hat Single Sign-On 中使用 OAuth 2.0 进行基于令牌的身份验证。设置授权时,您可以使用相同的 Red Hat Single Sign-On 服务器端点。
- 您需要了解如何管理 Red Hat Single Sign-On Authorization Services 的策略和权限,如 Red Hat Single Sign-On 文档所述。
流程
- 访问 Red Hat Single Sign-On Admin 控制台,或使用 Red Hat Single Sign-On Admin CLI 为设置 OAuth 2.0 身份验证时创建的 Kafka 代理客户端启用授权服务。
- 使用 Authorization Services 为客户端定义资源、授权范围、策略和权限。
- 通过分配角色和组,将权限绑定到用户和客户端。
将 Kafka 代理配置为使用 Red Hat Single Sign-On 授权。
将以下内容添加到 Kafka
server.properties
配置文件中,以在 Kafka 中安装授权器:authorizer.class.name=io.strimzi.kafka.oauth.server.authorizer.KeycloakAuthorizer principal.builder.class=io.strimzi.kafka.oauth.server.OAuthKafkaPrincipalBuilder
为 Kafka 代理添加配置以访问授权服务器和授权服务。
在此我们显示作为额外属性添加到
server.properties
的示例配置,但您也可以使用大写或大写的命名规则将它们定义为环境变量。strimzi.authorization.token.endpoint.uri="https://<auth_server_address>/auth/realms/REALM-NAME/protocol/openid-connect/token" 1 strimzi.authorization.client.id="kafka" 2
(可选)为特定 Kafka 集群添加配置。
例如:
strimzi.authorization.kafka.cluster.name="kafka-cluster" 1
- 1
- 特定 Kafka 集群的名称。名称用于目标权限,因此可以在同一 Red Hat Single Sign-On 域中管理多个集群。默认值为
kafka-cluster
。
(可选)与简单授权决定:
strimzi.authorization.delegate.to.kafka.acl="true" 1
- 1
- 如果 Red Hat Single Sign-On Authorization Services 策略无法访问,将授权委派给 Kafka
AclAuthorizer
。默认值为false
。
(可选)将 TLS 连接的配置添加到授权服务器。
例如:
strimzi.authorization.ssl.truststore.location=<path_to_truststore> 1 strimzi.authorization.ssl.truststore.password=<my_truststore_password> 2 strimzi.authorization.ssl.truststore.type=JKS 3 strimzi.authorization.ssl.secure.random.implementation=SHA1PRNG 4 strimzi.authorization.ssl.endpoint.identification.algorithm=HTTPS 5
(可选)配置从授权服务器刷新授权。授予刷新作业的工作原理,方法是枚举活跃的令牌并请求每个令牌的最新授权。
例如:
strimzi.authorization.grants.refresh.period.seconds="120" 1 strimzi.authorization.grants.refresh.pool.size="10" 2 strimzi.authorization.grants.max.idle.time.seconds="300" 3 strimzi.authorization.grants.gc.period.seconds="300" 4 strimzi.authorization.reuse.grants="false" 5
(可选)在与授权服务器通信时配置网络超时。
例如:
strimzi.authorization.connect.timeout.seconds="60" 1 strimzi.authorization.read.timeout.seconds="60" 2 strimzi.authorization.http.retries="2" 3
- 1
- 连接到 Red Hat Single Sign-On 令牌端点时的连接超时(以秒为单位)。默认值为
60
。 - 2
- 连接到 Red Hat Single Sign-On 令牌端点时读取超时(以秒为单位)。默认值为
60
。 - 3
- 重新尝试(不暂停)授权服务器的 HTTP 请求失败的次数上限。默认值为
0,
表示不会执行重试。要有效地使用这个选项,请考虑减少strimzi.authorization.connect.timeout.seconds
和strimzi.authorization.read.timeout.seconds
选项的超时时间。但请注意,重试可能会阻止当前 worker 线程可用于其他请求,如果太多请求停滞,则可能会导致 Kafka 代理无响应。
(可选)为令牌验证和授权启用 OAuth 2.0 指标:
oauth.enable.metrics="true" 1
- 1
- 控制是否启用或禁用 OAuth 指标。默认值为
false
。
(可选)从请求中删除
Accept
标头:oauth.include.accept.header="false" 1
- 1
- 如果包含标头在与授权服务器通信时导致问题,则设置为
false
。默认值为true
。
- 通过以客户端或具有特定角色的用户访问 Kafka 代理来验证配置的权限,确保它们具有必要的访问权限,或者没有应该具有访问权限。