4.5.4. Red Hat Single Sign-On の Authorization Services の試行

手順

1. Red Hat Single Sign-On ドキュメントの「Server Installation and Configuration」の説明にしたがって、Red Hat Single Sign-On Operator を使用して Red Hat Single Sign-On サーバーをインストールします。
2. Red Hat Single Sign-On インスタンスが実行されるまで待ちます。

3. 管理コンソールにアクセスできるように外部ホスト名を取得します。

   NS=sso
   oc get ingress keycloak -n $NS

   この例では、Red Hat Single Sign-On サーバーが sso namespace で実行されていることを前提としています。

4. admin ユーザーのパスワードを取得します。

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

   パスワードはシークレットとして保存されるため、Red Hat Single Sign-On インスタンスの設定 YAML ファイルを取得して、シークレット名(secretKeyRef.name)を特定します。

5. シークレットの名前を使用して、クリアテキストのパスワードを取得します。

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

   この例では、シークレットの名前が credential-keycloak であることを前提としています。

6. ユーザー名 admin と取得したパスワードを使用して、管理コンソールにログインします。

   https://HOSTNAME を使用して OpenShift Ingress にアクセスします。

   管理コンソールを使用して、サンプルレルムを Red Hat Single Sign-On にアップロードできるようになりました。

7. Add Realm をクリックして、サンプルレルムをインポートします。

8. examples/security/keycloak-authorization/kafka-authz-realm.json ファイルを追加してから Create をクリックします。

   これで、管理コンソールの現在のレルムとして kafka-authz が含まれるようになりました。

   デフォルトビューには、Master レルムが表示されます。

9. Red Hat Single Sign-On 管理コンソールで Clients > kafka > Authorization > Settings の順に移動し、Decision Strategy が Affirmative に設定されていることを確認します。

   肯定的な (Affirmative) ポリシーとは、クライアントが Kafka クラスターにアクセスするためには少なくとも 1 つのポリシーが満たされている必要があることを意味します。

10. Red Hat Single Sign-On 管理コンソールで、Groups、Users、Roles、および Clients と移動して、レルム設定を表示します。

    グループ

    Groups は、ユーザーグループの作成やユーザー権限の設定に使用します。グループは、名前が割り当てられたユーザーのセットです。地域、組織、または部門単位に区分するために使用されます。グループは LDAP アイデンティティープロバイダーにリンクできます。Kafka リソースにパーミッションを付与するなど、カスタム LDAP サーバー管理ユーザーインターフェースを使用して、ユーザーをグループのメンバーにすることができます。

    ユーザー

    Users は、ユーザーを作成するために使用されます。この例では、aliceとbobが定義されています。aliceはClusterManagerグループのメンバーであり、bobはClusterManager-my-clusterグループのメンバーです。ユーザーは LDAP アイデンティティープロバイダーに保存できます。

    ロール

    Rolesは、ユーザーやクライアントが特定の権限を持っていることを示すものです。ロールはグループに似た概念です。通常ロールは、組織ロールでユーザーを タグ付け するために使用され、必要なパーミッションを持ちます。ロールは LDAP アイデンティティープロバイダーに保存できません。LDAP が必須である場合は、代わりにグループを使用し、Red Hat Single Sign-On ロールをグループに追加して、ユーザーにグループを割り当てるときに対応するロールも取得するようにします。

    Clients

    Clientsは特定の構成を持つことができます。この例では、kafka、kafka-cli、team-a-client、team-b-clientの各クライアントが設定されています。

    • kafkaクライアントは、Kafkaブローカーがアクセストークンの検証に必要なOAuth 2.0 通信を行うために使用されます。このクライアントには、Kafka ブローカーで承認を実行するために使用される承認サービスリソース定義、ポリシー、および承認スコープも含まれます。認証設定はkafkaクライアントの Authorization タブで定義され、Settings タブでAuthorization Enabled をオンにすると表示されます。
    • kafka-cli クライアントは、アクセストークンまたは更新トークンを取得するためにユーザー名とパスワードを使用して認証するときに Kafka コマンドラインツールによって使用されるパブリッククライアントです。
    • team-a-client および team-b-client クライアントは、特定の Kafka トピックに部分的にアクセスできるサービスを表す機密クライアントです。

11. Red Hat Single Sign-On 管理コンソールで、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 Team A

    Dev チーム A レルムロールは、任意のクラスターで x_ で始まるトピックに書き込みできます。これは、Topic:x_*というリソース、DescribeとWriteのスコープ、そしてDev Team Aのポリシーを組み合わせたものです。Dev Team Aポリシーは、Dev Team Aというレルムロールを持つすべてのユーザーにマッチします。

    Dev Team B

    Dev チーム B レルムロールは、任意のクラスターで x_ で始まるトピックから読み取ることができます。これは、Topic:x_*、 Group:x_*のリソース、DescribeとReadのスコープ、およびDev Team Bのポリシーを組み合わせたものです。Dev Team Bポリシーは、Dev Team Bというレルムロールを持つすべてのユーザーにマッチします。一致するユーザーおよびクライアントはトピックから読み取りでき、名前が x_ で始まるトピックおよびコンシューマーグループの消費されたオフセットを更新できます。