搜索

6.6. 使用基于 OAuth 2.0 令牌的授权

download PDF

如果您在 Red Hat Single Sign-On 中使用 OAuth 2.0 进行基于令牌的身份验证,您还可以使用 Red Hat Single Sign-On 来配置授权规则来限制客户端对 Kafka 代理的访问。身份验证建立用户的身份。授权决定该用户的访问权限级别。

Apache Kafka 的流支持通过 Red Hat Single Sign-On Authorization Services 使用基于 OAuth 2.0 令牌的授权,它允许您集中管理安全策略和权限。

Red Hat Single Sign-On 中定义的安全策略和权限用于授予对 Kafka 代理上资源的访问权限。用户和客户端与允许对 Kafka 代理执行特定操作的策略进行匹配。

Kafka 允许所有用户默认对代理进行完全访问,并提供 AclAuthorizerStandardAuthorizer 插件来配置基于访问控制列表(ACL)的授权。由这些插件管理的 ACL 规则用于根据 用户名 授予或拒绝对资源的访问,这些规则存储在 Kafka 集群本身中。但是,红帽单点登录基于 OAuth 2.0 令牌的授权在您希望实现对 Kafka 代理的访问控制方面具有更大的灵活性。另外,您可以将 Kafka 代理配置为使用 OAuth 2.0 授权和 ACL。

6.6.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.6.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.6.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 文档所述

流程

  1. 访问 Red Hat Single Sign-On Admin 控制台,或使用 Red Hat Single Sign-On Admin CLI 为设置 OAuth 2.0 身份验证时创建的 Kafka 代理客户端启用授权服务。
  2. 使用 Authorization Services 为客户端定义资源、授权范围、策略和权限。
  3. 通过分配角色和组,将权限绑定到用户和客户端。
  4. 将 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
  5. 为 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
    1
    到 Red Hat Single Sign-On 的 OAuth 2.0 令牌端点 URL。对于生产环境,请始终使用 https:// urls。
    2
    在启用了授权服务的 Red Hat Single Sign-On 中 OAuth 2.0 客户端定义的客户端 ID。通常,kafka 被用作 ID。
  6. (可选)为特定 Kafka 集群添加配置。

    例如:

    strimzi.authorization.kafka.cluster.name="kafka-cluster" 1
    1
    特定 Kafka 集群的名称。名称用于目标权限,因此可以在同一 Red Hat Single Sign-On 域中管理多个集群。默认值为 kafka-cluster
  7. (可选)与简单授权决定:

    strimzi.authorization.delegate.to.kafka.acl="true" 1
    1
    如果 Red Hat Single Sign-On Authorization Services 策略无法访问,将授权委派给 Kafka AclAuthorizer。默认值为 false
  8. (可选)将 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
    1
    包含证书的信任存储的路径。
    2
    truststore 的密码。
    3
    truststore 类型。如果没有设置,则使用默认的 Java 密钥存储类型。
    4
    随机数生成器实施。如果没有设置,则使用 Java platform SDK 默认。
    5
    主机名验证。如果设置为空字符串,则会关闭主机名验证。如果没有设置,则默认值为 HTTPS,它会强制对服务器证书进行主机名验证。
  9. (可选)配置从授权服务器刷新授权。授予刷新作业的工作原理,方法是枚举活跃的令牌并请求每个令牌的最新授权。

    例如:

    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
    1
    指定授权服务器的授予的频率(默认为每分钟一次)。要关闭刷新以进行调试,请将 设置为 "0"
    2
    指定授予刷新作业使用的线程池大小(并行级别)。默认值为 "5"
    3
    缓存中闲置授权的时间(以秒为单位)。默认值为 300。
    4
    连续运行作业之间的时间(以秒为单位)。默认值为 300。
    5
    控制是否为新会话获取最新的授权。禁用后,从 Red Hat Single Sign-On 检索并缓存该用户的权限。默认值为 true
  10. (可选)在与授权服务器通信时配置网络超时。

    例如:

    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.secondsstrimzi.authorization.read.timeout.seconds 选项的超时时间。但请注意,重试可能会阻止当前 worker 线程可用于其他请求,如果太多请求停滞,则可能会导致 Kafka 代理无响应。
  11. (可选)为令牌验证和授权启用 OAuth 2.0 指标:

    oauth.enable.metrics="true" 1
    1
    控制是否启用或禁用 OAuth 指标。默认值为 false
  12. (可选)从请求中删除 Accept 标头:

    oauth.include.accept.header="false" 1
    1
    如果包含标头在与授权服务器通信时导致问题,则设置为 false。默认值为 true
  13. 通过以客户端或具有特定角色的用户访问 Kafka 代理来验证配置的权限,确保它们具有必要的访问权限,或者没有应该具有访问权限。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.