Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

3.5. ロールベースのアクセス制御

ロールベースのアクセス制御の基本は、JBoss EAPSecurity Architectureガイドの ロールベースのアクセス制御 と 管理インターフェイスへの RBAC の追加 で説明されています。

3.5.1. ロールベースのアクセス制御の有効化
リンクのコピー

デフォルトでは、Role-Based Access Control (RBAC) システムが無効になっています。有効にするには、provider 属性を simple から rbac に変更します。provider は、management 要素の access-control 要素の属性です。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。稼働中のサーバーで RBAC を無効化または有効化した場合、サーバー設定をリロードして変更を反映する必要があります。

警告

プロバイダーを rbac に変更する前に、RBAC ロールのいずれかにマッピングされるユーザーを含めるようにしてください (Administrator または SuperUser ロールのいずれかが望ましい)。シャットダウンして XML 設定を編集する以外に、インストールを管理する方法はありません。JBoss EAP に同梱される標準 XML 設定のいずれかで開始した場合、$local ユーザーは SuperUser ロールにマッピングされ、local 認証スキームが有効になります。これにより、JBoss EAP プロセスと同じシステムで CLI を実行するユーザーに、完全な管理パーミッションを付与できます。リモート CLI ユーザーと Web ベースの管理コンソールユーザーには、パーミッションが与えられません。

プロバイダーを rbac に切り替える前に、$local 以外のユーザーをマッピングすることが推奨されます。プロバイダーが simple に設定されている場合でも、rbac プロバイダーに関連付けられたすべての設定を実行できます。

一度有効にすると、無効化できるのは Administrator または SuperUser ロールのユーザーのみとなります。デフォルトでは、サーバーと同じマシンで実行される場合、管理 CLI は SuperUser ロールとして実行されます。

RBAC を有効化する CLI

管理 CLI で RBAC を有効にするには、アクセス承認リソースの write-attribute 操作で provider 属性を rbac に設定します。 

/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

reload
Copy to Clipboard Toggle word wrap

マネージドドメインでは、アクセス制御設定はドメイン全体の設定の一部です。そのため、リソースアドレスは上記のリソースアドレスと同じですが、管理 CLI はマスタードメインコントローラーに接続されます。 

/core-service=management/access=authorization:write-attribute(name=provider,value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    },
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-reload" => true,
                "process-state" => "reload-required"
            }
        }}
    }}}}
}

reload --host=master
Copy to Clipboard Toggle word wrap
注記

スタンドアロンサーバーと同様に、変更を有効にするには、リロードまたは再起動が必要です。マネージドドメインでは、ドメインのすべてのホストおよびサーバーは、マスタードメインコントローラーから、リロードまたは再起動する必要があります。

RBAC を無効にする管理 CLI コマンド

管理 CLI で RBAC を無効化にするには、アクセス承認リソースの write-attribute 操作で provider 属性を simple に設定します。 

/core-service=management/access=authorization:write-attribute(name=provider, value=simple)
Copy to Clipboard Toggle word wrap
RBAC を有効または無効にする XML 設定

サーバーがオフラインの場合、XML 設定を編集して RBAC を有効または無効にすることができます。これを行うには、管理要素の access-control 要素の provider 属性を編集します。この値を rbac に設定して有効にし、simple で無効にします。

例: RBAC を有効または無効にする XML 設定

<management>
  <access-control provider="rbac">
    <role-mapping>
      <role name="SuperUser">
        <include>
          <user name="$local"/>
        </include>
      </role>
    </role-mapping>
  </access-control>
</management>
Copy to Clipboard Toggle word wrap

3.5.2. Permission Combination Policy の変更
リンクのコピー

Permission Combination Policy は、ユーザーが複数のロールが割り当てられているかどうかの判断方法を決定します。permissive または reject に設定できます。デフォルトは permissive です。

permissive に設定すると、アクションを許可するユーザーにロールが割り当てられていると、そのアクションが許可されます。

rejecting に設定すると、複数のロールがユーザーに割り当てられている場合、アクションは許可されません。つまり、このポリシーが rejecting に設定されていると、各ユーザーには単一のロールのみを割り当てる必要があります。ポリシーが rejecting に設定されている場合、複数のロールを持つユーザーは管理コンソールまたは管理 CLI を使用できません。

Permission Combination Policy は、permission-combination-policy 属性を permissive または rejecting のいずれかに設定して設定します。これは、管理 CLI を使用するか、サーバーがオフラインの場合にはサーバー設定 XML ファイルを編集して実行できます。Permission-combination-policy 属性は access-control 要素の一部で、access-control 要素は management 要素にあります。

Permission Combination Policy の設定

アクセス承認リソースの write-attribute 操作を使用して、permission-combination-policy 属性を必要なポリシー名に設定します。 

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
Copy to Clipboard Toggle word wrap

有効なポリシー名は rejecting および permissive になります。

例: Permission Combination Policy を拒否する管理 CLI コマンド

/core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
Copy to Clipboard Toggle word wrap

サーバーがオフラインの場合、XML 設定を編集してパーミッションの組み合わせポリシー (permission combination policy) 値を変更できます。これを行うには、access-control 要素の permission-combination-policy 属性を編集します。

例: Permission Combination Policy を拒否する XML 設定

<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>
Copy to Clipboard Toggle word wrap

3.5.3. ロールの管理
リンクのコピー

RBAC (Role-Based Access Control) を有効にすると、管理ユーザーが許可されている内容は、ユーザーが割り当てられているロールによって決まります。JBoss EAP 7 は、ユーザーおよびグループメンバーシップの両方に基づた包含と除外のシステムを使用して、ユーザーが所属するロールを決定します。

ユーザーは、以下の場合にロールに割り当てられると見なされます。

  • ロールに含めるユーザーとしてリスト表示される、または
  • ロールに含まれるようにリスト表示されるグループのメンバー。

また、ユーザーが以下を実行しない場合、ユーザーはロールに割り当てられると見なされます。

  • ロールから除外するユーザーとしてリスト、または
  • ロールから除外されるリストのグループのメンバーです。

除外は包含よりも優先されます。

ユーザーおよびグループのロール包含および除外の設定は、管理コンソールと管理 CLI の両方を使用して設定できます。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

3.5.3.1. 管理 CLI を使用したユーザーロール割り当ての設定
リンクのコピー

ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization に位置します。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

ロール割り当て設定の表示

read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。 

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "Administrator",
        "Deployer",
        "Maintainer",
        "Monitor",
        "Operator",
        "SuperUser"
    ]
}
Copy to Clipboard Toggle word wrap

指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。 

/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
Copy to Clipboard Toggle word wrap
新規ロールの追加

この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。

add 操作で、新しいロール設定を追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME:add
Copy to Clipboard Toggle word wrap

ROLENAME は、Auditor などの新規マッピングに使用されるロールの名前です。

例: 新規ロール設定の管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor:add
Copy to Clipboard Toggle word wrap

ロールに含まれるユーザーの追加

この手順では、ロールの、含まれるリストにユーザーを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロール、追加リストにユーザーエントリーを追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。
  • username は、max などの包含リストに追加されるユーザーの名前です。

例: ロールに含まれるユーザーの管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:add(name=max, type=USER)
Copy to Clipboard Toggle word wrap

ユーザーをロールで除外したものとして追加

この手順では、ロールの除外リストにユーザーを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロールの除外リストにユーザーエントリーを追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • USERNAME は、max などの除外リストに追加されているユーザーの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。

例: ロールで除外される管理 CLI コマンドユーザー

/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:add(name=max, type=USER)
Copy to Clipboard Toggle word wrap

ユーザーロール包含設定の削除

この手順では、ロールマッピングからユーザー包含エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。

例: ユーザーロールの包含設定を削除する管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=user-max:remove
Copy to Clipboard Toggle word wrap

注記

包含のリストからユーザーを削除しても、ユーザーはシステムから削除されません。また、ロールがそのユーザーに割り当てられないようにします。ロールはグループメンバーシップに基づいて依然として割り当てられる可能性があります。

ユーザーロール除外の設定の削除

この手順では、ロールマッピングからユーザー除外エントリーを削除する方法を説明します。

削除操作でエントリーを削除します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、user-USERNAME (例: user-max) などのエイリアスの命名規則を使用することを推奨します。 
/core-service=management/access=authorization/role-mapping=Auditor/exclude=user-max:remove
Copy to Clipboard Toggle word wrap
注記

除外のリストからユーザーを削除しても、ユーザーはシステムから削除されません。また、そのロールが必ずそのユーザーに割り当てられるようになるわけではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

3.5.4. Elytron サブシステムを使用したユーザーロール割り当ての設定
リンクのコピー

ロールの管理セクションで説明しているように、ユーザーのロールマッピングを直接追加することに加え、elytron サブシステムによって提供されるアイデンティティーから直接取得されるように RBAC ロールを設定することもできます。

RBAC システムを設定して elytron サブシステムによって提供されるロールを使用するには、以下を実行します。 

/core-service=management/access=authorization:write-attribute(name=use-identity-roles,value=true)
Copy to Clipboard Toggle word wrap
重要

この機能を使用するには RBAC が有効にされており、プリンシパルには RBAC ロールがなければなりません。

3.5.5. ロールおよびユーザーグループ
リンクのコピー

ユーザーグループは、1 人以上のユーザーに割り当てることのできる任意のラベルです。管理インターフェイスを使用して認証を行う場合、管理インターフェイスのセキュア化方法に応じて、ユーザーには elytron サブシステムまたはコア管理認証のいずれかからグループが割り当てられます。RBAC システムは、所属するユーザーグループに応じて、自動的にロールをユーザーに割り当てるように設定できます。また、グループメンバーシップに基づいてロールからユーザーを除外することもできます。

3.5.6. 管理 CLI を使用したグループロール割り当ての設定
リンクのコピー

ロールに含まれる、またはロールから除外されるグループは、管理コンソールおよび管理 CLI で設定できます。このトピックでは、管理 CLI の使用についてのみ説明します。

ユーザーおよびグループのロールへのマッピングの設定は、role-mapping 要素として /core-service=management/access=authorization の管理 API に位置します。

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

グループロール割り当て設定の表示

read-children-names 操作を使用して、設定されたロールの完全なリストを取得します。 

/core-service=management/access=authorization:read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "Administrator",
        "Deployer",
        "Maintainer",
        "Monitor",
        "Operator",
        "SuperUser"
    ]
}
Copy to Clipboard Toggle word wrap

指定した role-mapping の read-resource 操作を使用して、特定のロールの完全な詳細を取得します。 

/core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
Copy to Clipboard Toggle word wrap
新規ロールの追加

この手順では、ロールの role-mapping エントリーを追加する方法を説明します。これは、ロールを設定する前に行う必要があります。

add 操作で、新しいロール設定を追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME:add
Copy to Clipboard Toggle word wrap
ロールに含まれるグループの追加

この手順では、ロールの包含リストにグループを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に実行する必要があります。

add 操作を使用して、ロール、追加リストにグループエントリーを追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • GROUPNAME は、investigators など、包含リストに追加されるグループの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。

例: ロールに含まれるグループを追加する管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:add(name=investigators, type=GROUP)
Copy to Clipboard Toggle word wrap

ロールの除外としてグループを追加

この手順では、ロールの除外リストにグループを追加する方法を説明します。

ロールの設定が行われていない場合は、そのロールの role-mapping エントリーを最初に作成する必要があります。

add 操作を使用して、ロールの除外リストにグループエントリーを追加します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • GROUPNAME は、supervisors など、包含リストに追加されるグループの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。

例: ロールの除外としてグループを追加する管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:add(name=supervisors, type=GROUP)
Copy to Clipboard Toggle word wrap

グループロール包含設定の削除

この手順では、ロールマッピングからグループ包含エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-investigators) などのエイリアスの命名規則を使用することを推奨します。

例: グループロールの包含設定を削除する管理 CLI コマンド

/core-service=management/access=authorization/role-mapping=Auditor/include=group-investigators:remove
Copy to Clipboard Toggle word wrap

注記

包含のリストからグループを削除しても、グループはシステムから削除されません。また、ロールがこのグループのユーザーに割り当てられないようにします。このロールは、引き続きグループのユーザーに割り当てられます。

ユーザーグループ除外エントリーの削除

この手順では、ロールマッピングからグループ除外エントリーを削除する方法を説明します。

remove 操作を使用してエントリーを削除します。 

/core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
Copy to Clipboard Toggle word wrap
  • ROLENAME は、Auditor などの、設定されるているロールの名前です。
  • ALIAS は、このマッピングの一意の名前です。Red Hat は、group-GROUPNAME (例: group-supervisors) などのエイリアスの命名規則を使用することを推奨します。 
/core-service=management/access=authorization/role-mapping=Auditor/exclude=group-supervisors:remove
Copy to Clipboard Toggle word wrap
注記

除外のリストからグループを削除しても、システムからそのグループは削除されません。また、ロールがグループのメンバーに割り当てられることを保証する訳ではありません。依然としてロールはグループメンバーシップに基づいて除外される可能性があります。

3.5.7. LDAP での RBAC の使用
リンクのコピー

LDAP で RBAC を使用する基本と、JBoss EAP が LDAP で RBAC を使用するよう設定する方法は、JBoss EAP アイデンティティー管理の設定方法 の LDAP および RBAC セクションを参照してください。

3.5.8. スコープ指定されたロール
リンクのコピー

スコープ指定されたロールは、標準的なロールのパーミッションを付与するユーザー定義のロールです。ただし、JBoss EAP マネージドドメインの 1 つ以上のサーバーグループまたはホストに対してのみ適用されます。スコープ指定されたロールでは、管理ユーザーに、必要なサーバーグループまたはホストのみに制限されるパーミッションを付与することができます。

重要

スコープ指定されたロールは、Administrator または SuperUser ロールが割り当てられているユーザーが作成できます。

これらは、以下の 5 つの特性によって定義されます。

  • 一意な名前。
  • ベースとなる標準ロール。
  • サーバーグループまたはホストに適用される場合。
  • 制限されたサーバーグループまたはホストのリスト。
  • すべてのユーザーが自動的に組み込まれるかどうか。デフォルトは false です。

作成すると、スコープ指定されたロールは標準ロールと同じ方法でユーザーおよびグループに割り当てることができます。

スコープ指定されたロールを作成しても、新しいパーミッションを定義することはできません。スコープ指定されたロールは、制限されたスコープ内で既存のロールのパーミッションを適用する場合にのみ使用できます。たとえば、スコープ指定されたロールは、単一のサーバーグループに制限されている Deployer ロールに基づいて作成できます。

ロールには、以下の 2 つのスコープのみを使用できます。

ホストスコープ指定ロール
ホストスコープ指定ロールは、そのロールのパーミッションは単一または複数のホストに制限されます。つまり、アクセスは関連する /host=*/ リソースツリーに提供されますが、他のホストに固有のリソースは非表示になります。
サーバーグループスコープ指定ロール
サーバーグループスコープ指定ロールは、そのロールのパーミッションを 1 つ以上のサーバーグループに制限します。また、ロールのパーミッションは、指定した server-groups に関連付けられたプロファイル、ソケットバインディンググループ、サーバー設定、およびサーバーリソースにも適用されます。サーバーグループに論理的に関連していないものの内部のサブリソースは、ユーザーには認識できません。
重要

ユーザービリティーを強化する管理モデルのシンプルなビューを提供するために、server-group および host のスコープ指定されたロールに一部のリソースがアドレス指定できなくなります。これは、機密データを保護するためにアドレス指定できないリソースとは異なります。

host スコープ指定されたロールの場合は、ロールに指定されたサーバーグループに関連していなければ、管理モデルの /host=* 部分のリソースが表示されないことを意味します。

server-group のスコープ指定ロールの場合は、ロールに指定されたサーバーグループに関連しない場合、管理モデルの profile、socket-binding-group、deployment、deployment-overlay、server-group、server-config、server の部分のリソースが表示されないことを意味します。

3.5.8.1. 管理 CLI からのスコープ指定されたロールの設定
リンクのコピー

重要

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

新しいスコープ指定されたロールの追加

スコープ設定されたロールを新たに追加するには、以下の操作を行う必要があります。 

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:add
Copy to Clipboard Toggle word wrap 
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:add(base-role=BASE-ROLE, server-groups=[SERVER-GROUP-NAME])
Copy to Clipboard Toggle word wrap

NEW-SCOPED-ROLE、BASE-ROLE、および SERVER-GROUP-NAME を適切な情報に置き換えます。

スコープ指定ロールマッピングの表示および編集

スコープ設定ロールの詳細 (メンバーを含む) は、以下のコマンドを使用して表示できます。 

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:read-resource(recursive=true)
Copy to Clipboard Toggle word wrap

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの詳細を編集するには、write-attribute コマンドを使用できます。以下に例を示します。 

/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:write-attribute(name=include-all, value=true)
Copy to Clipboard Toggle word wrap

NEW-SCOPED-ROLE を適切な情報に置き換えます。

スコープ指定ロールの削除
/core-service=management/access=authorization/role-mapping=NEW-SCOPED-ROLE:remove
Copy to Clipboard Toggle word wrap 
/core-service=management/access=authorization/server-group-scoped-role=NEW-SCOPED-ROLE:remove
Copy to Clipboard Toggle word wrap

NEW-SCOPED-ROLE を適切な情報に置き換えます。

重要

ユーザーまたはグループが割り当てられている場合、スコープ指定ロールは削除できません。最初にロールの割り当てを削除してから、スコープ指定ロールを削除します。

ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は 標準ロールの追加と削除 と同じプロセスに従います。

3.5.8.2. 管理コンソールからのスコープ指定ロールの設定
リンクのコピー

重要

この設定を実行できるのは、SuperUser または Administrator ロールのユーザーのみです。

管理コンソールのスコープ指定ロール設定は、以下の手順で確認できます。

  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. Roles をクリックして、スコープ指定されたロールを含め、すべてのロールを表示します。

以下の手順では、スコープ指定ロールの設定タスクを実行する方法について説明します。

新しいスコープ指定されたロールの追加
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. Roles を選択し、Add (+) ボタンをクリックします。
  4. Host Scoped Role または Server Group Scoped Role を選択します。

  5. 以下の詳細を指定します。

    • Name: スコープ指定の新しいロールの一意の名前。
    • Base Role: このロールがパーミッションを元にするロール。
    • Hosts または Server Groups。ロールが制限されているホストまたはサーバーグループのリスト。追加中のスコープ指定ロールの種類による。複数のエントリーを選択できます。
    • Include All: このロールがすべてのユーザーを自動的に含めるかどうか。デフォルトは OFF です。
  6. Add をクリックして新規ロールを作成します。
スコープ指定されたロールの編集
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 編集するスコープ指定ロールをクリックし、Edit をクリックします。
  5. 変更する詳細を更新して、Save ボタンをクリックします。
スコープ指定されたロールメンバーの表示
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 対象のスコープ指定ロールをクリックして、包含メンバーおよび除外メンバーを表示します。
スコープ指定ロールの削除
  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックします。
  4. 対象のスコープ対象のロールをクリックし、ドロップダウンから Remove をクリックします。
  5. Yes をクリックし、その割り当てをすべて削除します。
ユーザーの追加および削除

スコープ指定ロールへのユーザーの追加および削除は標準ロールの追加と削除と同じプロセスに従います。ユーザーのスコープ指定ロールを更新するには、以下を実行します。

  1. 管理コンソールにログインします。
  2. Access Control タブをクリックします。
  3. 左側の Roles メニューをクリックし、対象のスコープ指定ロールをクリックします。
  4. メンバーを含めるにはプラス (+) ボタンを選択し、メンバーを除外するにはマイナス (-) ボタンを選択します。

3.5.9. 制約の設定
リンクのコピー

3.5.9.1. 機密性制約の設定
リンクのコピー

各機密性制約は、機密であるとみなされるリソースのセットを定義します。通常、機密リソースとは、パスワードなどの秘密のリソースや、ネットワーキング、JVM 設定、システムプロパティーなどのサーバーに重大な影響を与えるリソースのことです。アクセス制御システム自体も機密であると見なされます。リソースの機密性は、どのロールが特定のリソースの読み取り、書き込み、またはアドレス指定できるかを制限します。

機密性制約設定は /core-service=management/access=authorization/constraint=sensitivity-classification にあります。

管理モデル内で、それぞれの機密性制約は分類として識別されます。分類はタイプにグループ化されます。各分類には apply-to 要素があります。これは分類設定が適用されるパスパターンのリストです。

機密性制約を設定するには、write-attribute 操作を使用して configured-requires-read、configured-requires-write、configured-requires-addressable 属性を設定します。操作のタイプを機密に設定するには、属性の値を true に設定します。機密にしない場合は値を false に設定します。デフォルトでは、これらの属性は設定されず、default-requires-read、default-requires-write、default-requires-addressable の値が使用されます。設定した属性が適用されると、デフォルトではなく、その値が使用されます。デフォルト値は変更できません。

例: 読み取りシステムプロパティーを機密操作にする

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:write-attribute(name=configured-requires-read,value=true)
Copy to Clipboard Toggle word wrap

例: 結果

/core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property:read-resource
Copy to Clipboard Toggle word wrap 

{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/core-service=platform-mbean/type=runtime" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}
Copy to Clipboard Toggle word wrap

ロールと、実行できる各操作は、属性の設定によって異なります。これは、以下の表で説明されています。

Expand
表3.2 機密性制約設定の結果
値requires-readrequires-writerequires-addressable

true

読み取りは機密です。Auditor、Administrator、SuperUser のみを読み取ることができます。

書き込みは機密です。Administrator および SuperUser のみが書き込み可能です。

アドレス指定は機密です。Auditor、Administrator、SuperUser のみがアドレス指定できます。

false

読み取りは機密ではありません。すべての管理ユーザーが読み取り可能です。

書き込みは機密ではありません。Maintainer、 Administrator、および SuperUser のみが書き込み可能です。また、Deployer はリソースをアプリケーションリソースとして記述することもできます。

アドレス指定は機密ではありません。すべての管理ユーザーがアドレス指定できます。

3.5.9.2. 機密性制約のリスト
リンクのコピー

以下の管理 CLI コマンドを使用すると、利用可能な機密性制約のリストを JBoss EAP 管理モデルから直接確認できます。 

/core-service=management/access=authorization/constraint=sensitivity-classification:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

3.5.9.3. アプリケーションリソース制約の設定
リンクのコピー

各アプリケーションリソース制約は、通常はアプリケーションとサービスのデプロイメントに関連するリソース、属性、および操作のセットを定義します。アプリケーションリソース制約が有効化されると、Deployer ロールの管理ユーザーに、適用されるリソースへのアクセスが付与されます。

アプリケーション制約設定は /core-service=management/access=authorization/constraint=application-classification/ にあります。

各アプリケーションリソース制約は分類として識別されます。分類はタイプにグループ化されます。各分類には apply-to 要素があります。これは分類設定が適用されるパスパターンのリストです。

デフォルトでは、有効になっている唯一のアプリケーションリソースの分類はコアです。コアには、デプロイメント、デプロイメントオーバーレイ、およびデプロイメント操作が含まれます。

アプリケーションリソースを有効にするには、write-attribute 操作を使用して、分類の configured-application 属性を true に設定します。アプリケーションリソースを無効にするには、この属性を false に設定します。デフォルトでは、これらの属性は設定されず、default-application 属性の値が使用されます。デフォルト値は変更できません。

例: logger-profile アプリケーションリソースの分類の有効化

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:write-attribute(name=configured-application,value=true)
Copy to Clipboard Toggle word wrap

例: 結果

/core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile:read-resource
Copy to Clipboard Toggle word wrap 

{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/subsystem=logging/logging-profile=*" => undefined}
    }
}
Copy to Clipboard Toggle word wrap
重要

アプリケーションリソース制約は、その設定に一致するすべてのリソースに適用されます。たとえば、Deployer ユーザーに、あるデータソースリソースへのアクセスを許可して、同じデータベースの別のリソースへのアクセスを拒否することはできません。このレベルの分離が必要な場合は、異なるサーバーグループでリソースを設定し、グループごとに異なるスコープ指定の Deployer ロールを作成することが推奨されます。

3.5.9.4. アプリケーションリソース制約のリスト表示
リンクのコピー

以下の管理 CLI コマンドを使用すると、利用可能なアプリケーションリソースのリストを JBoss EAP 管理モデルから直接確認できます。 

/core-service=management/access=authorization/constraint=application-classification:read-resource(include-runtime=true,recursive=true)
Copy to Clipboard Toggle word wrap

3.5.9.5. Vault 式制約の設定
リンクのコピー

デフォルトでは、vault 式の読み書きは機密操作です。Vault 式制約を設定すると、これらの操作のいずれかまたは両方を非機密に設定できます。この制約を変更すると、より多くのロールで vault 式の読み書きが可能になります。

Vault 式制約は /core-service=management/access=authorization/constraint=vault-expression にあります。

Vault 式制約を設定するには、write-attribute 操作を使用して configured-requires-write と configured-requires-read の値を true または false に設定します。デフォルトではそれらは設定されず、default-requires-read と default-requires-write の値が使用されます。デフォルト値は変更できません。

例: Vault 式への書き込みのを非機密操作にする

/core-service=management/access=authorization/constraint=vault-expression:write-attribute(name=configured-requires-write,value=false)
Copy to Clipboard Toggle word wrap

例: 結果

/core-service=management/access=authorization/constraint=vault-expression:read-resource
Copy to Clipboard Toggle word wrap 

{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}
Copy to Clipboard Toggle word wrap

ロールと、読み書きが可能な関連の vault 式は、属性の設定に依存します。これは、以下の表で説明されています。

Expand
表3.3 Vault 式制約設定の結果
値requires-readrequires-write

true

読み取り操作は機密です。Auditor、Administrator、および SuperUser のみを読み取ることができます。

書き込み操作は機密です。Administrator および SuperUser のみが書き込み可能です。

false

読み取り操作は機密ではありません。すべての管理ユーザーは読み取りが可能です。

書き込み操作は機密ではありません。Monitor、Administrator、および SuperUser は書き込み可能です。Deployer は、vault 式がアプリケーションリソースにある場合にも書き込み可能です。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る