4.5.4. 试用红帽单点登录授权服务

流程

1. 使用 Red Hat Single Sign-On Operator 安装 Red Hat Single Sign-On 服务器，如 Red Hat Single Sign-On 文档中的服务器安装和配置 中所述。
2. 等待红帽单点登录实例运行。

3. 获取外部主机名，以便能够访问管理控制台。

   NS=sso
   oc get ingress keycloak -n $NS

   在本例中，我们假定红帽单点登录服务器正在 sso 命名空间中运行。

4. 获取 admin 用户的密码。

   oc get -n $NS pod keycloak-0 -o yaml | less

   密码存储为 secret，因此获取 Red Hat Single Sign-On 实例的配置 YAML 文件，以标识 secret 的名称(secretKeyRef.name)。

5. 使用机密的名称获取明文密码。

   SECRET_NAME=credential-keycloak
   oc get -n $NS secret $SECRET_NAME -o yaml | grep PASSWORD | awk '{print $2}' | base64 -D

   在本例中，我们假设 secret 的名称是 credentials -keycloak。

6. 使用用户名 admin 和您获取的密码登录管理控制台。

   使用 https://HOSTNAME 访问 OpenShift 入口。

   现在，您可以使用管理控制台将示例域上传到红帽单点登录。

7. 单击 Add Realm 以 导入示例域。

8. 添加 example /security/keycloak-authorization/kafka-authz-realm.json 文件，然后单击 Create。

   现在，在管理控制台中，kafka-authz 作为当前域。

   默认视图显示 Master 域。

9. 在 Red Hat Single Sign-On Admin Console 中，进入 Clients > kafka > Authorization > Settings，并检查 Decision Strategy 是否已设置为 Affirmative。

   一个策略意味着，客户端必须至少满足一个策略才能访问 Kafka 集群。

10. 在红帽单点管理控制台中，前往 组、用户、角色和 客户端 以查看域配置。

    组

    组用于创建用户组 和设置用户权限。组是分配了名称的用户组。它们用于将用户划分到地理、组织或部门单元中。组可以链接到 LDAP 身份提供程序。您可以通过自定义 LDAP 服务器 admin 用户界面让用户成为组的成员，例如，授予 Kafka 资源的权限。

    用户

    用户 用于创建用户。本例中定义了 alice 和 bob。Alice 是 ClusterManager 组的成员，bob 是 ClusterManager-my-cluster 组的成员。用户可以存储在 LDAP 身份提供商中。

    角色

    角色 将用户或客户端标记为具有特定权限。角色是类似于组的概念。它们通常用于为用户 添加 组织角色，并具有必要的权限。角色不能存储在 LDAP 身份提供商中。如果 LDAP 是必需的，您可以改为使用组，并将红帽单点登录角色添加到组，以便在为用户分配组时也获得相应的角色。

    客户端

    客户端 可以具有特定的配置。在本例中，配置了 kafka、kafka-cli、team-a-client 和 team-b-client 客户端。

    • kafka 客户端供 Kafka 代理用于执行必要的 OAuth 2.0 通信，以进行访问令牌验证。此客户端还包含授权服务资源定义、策略和授权范围，用于在 Kafka 代理上执行授权。授权配置在 Authorization 选项卡的 kafka 客户端中定义，在 Settings 选项卡中打开 授权启用 时可看到该配置。
    • kafka-cli 客户端是一个公共客户端，在使用用户名和密码进行身份验证时供 Kafka 命令行工具使用，以获取访问令牌或刷新令牌。
    • team-a-client 和 team-b-client 客户端是机密客户端，代表对某些 Kafka 主题有部分访问权限的服务。

11. 在 Red Hat Single Sign-On Admin Console 中，进入 Authorization > Permissions，以查看使用为域定义的资源和策略所授予的权限。

    例如，kafka 客户端有以下权限：

    Dev Team A can write to topics that start with x_ on any cluster
    Dev Team B can read from topics that start with x_ on any cluster
    Dev Team B can update consumer group offsets that start with x_ on any cluster
    ClusterManager of my-cluster Group has full access to cluster config on my-cluster
    ClusterManager of my-cluster Group has full access to consumer groups on my-cluster
    ClusterManager of my-cluster Group has full access to topics on my-cluster

    Dev 团队 A

    Dev 团队 A 域角色可以写入任何群集上以 x_ 开头的主题。这结合了名为 Topic:x_*、Describe 和 Write 范围以及 Dev Team A 策略 的资源。Dev 团队 A 策略 与具有名为 Dev Team A 的域角色的所有用户匹配。

    Dev 团队 B

    Dev 团队 B 域角色可以从任何群集上以 x_ 开头的主题中读取。这结合了 主题：x_*、Group:x_* 资源、Describe 和 Read 范围以及 Dev Team B 策略。Dev 团队 B 策略匹配具有名为 Dev Team B 的域角色的所有用户。匹配的用户和客户端能够从主题中读取，并为名称以 x_ 开头的主题和消费者组更新所消耗的偏移量。