ジョブ・マネージャーのセキュリティー
柔軟な管理環境では、ジョブ・マネージャーおよび登録済みノードを使用するために必要な権限がユーザー ID になければなりません。
必要なセキュリティー・ロール
ジョブ・マネージャーを使用するには、以下のロールが必要です。
管理用タスク | 必要なセキュリティー・ロール |
---|---|
ジョブ・マネージャーに対する登録または登録抹消 | administrator |
ジョブのサブミット | オペレーター |
ジョブ・マネージャー構成の変更 | コンフィギュレーター |
ジョブ・マネージャー構成またはジョブ・ヒストリーの読み取り | モニター |
管理エージェントが管理する基本 (スタンドアロン) アプリケーション・サーバー・ノードがジョブ・マネージャーに登録されている場合、 管理エージェントの使用およびそのノードの管理のために、以下のロールが必要です。
管理用タスク | 必要なセキュリティー・ロール |
---|---|
ベース (スタンドアロン) ノードの管理エージェントへの登録または登録抹消 | administrator |
管理エージェントの使用: | 実行されている操作に必要な管理ロール |
管理サブシステムの使用 (登録済みノードなど) | 登録済みベース・ノードに必要な管理ロール |
ターゲット上でジョブを実行する場合は、ユーザーにはそのジョブに必要なロールを含んだ特権が必要です。例えば、アプリケーション・サーバーを作成するためのジョブには、ベース・ノードまたは WebSphere® Application Server Network Deployment セルのいずれかで最小限のコンフィギュレーター・ロールが必要です。
リモート・ホスト上の Installation Manager または Liberty・ジョブの セキュリティー
Installation Manager または Libertyなどの リモート・ホストへのアクセスにユーザー名とパスワードが必要な場合、そのリモート・ホスト上でジョブを実行するには、 有効なオペレーティング・システム・ユーザー名およびパスワードを指定する必要があります。以下のタイプの 許可を指定できます。
- オペレーティング・システム・ユーザー名およびパスワード
- ユーザー名とパスワードはホストのログイン値です。ホストがパスワードを必要としない場合、 ジョブをサブミットするときにパスワードを指定する必要はありません。
- sudo
- 代替ユーザーがホスト上でコマンドを実行するようにしたい場合、 ジョブを実行する前に sudo を使用してユーザーを変更し、 それ以降は必要に応じて代替ユーザーのユーザー名とパスワードを指定するようにできます。sudo は、「代替ユーザーが実行する (substitute user do)」ことを意味します。ホストがパスワードを必要としない場合、 ジョブをサブミットするときにパスワードを指定する必要はありません。
- 公開/秘密鍵認証
- 公開/秘密鍵認証を使用することができます。ジョブをサブミットするとき、 鍵ストアの絶対パスを指定し、鍵ストアに必要な場合はパスフレーズ も指定します。セキュア・シェル (SSH) 秘密鍵 は、管理者が特定のユーザー名の下でリモート・ホストでジョブを 実行することを可能にします。別のユーザーによる使用を防止するため、 鍵はパスワードで暗号化されます。
Liberty サーバーの場合、使用する権限のタイプは、以下のように、各ホスト用に構成されているユーザー名によって異なります。
- 単一ユーザー名
- 各ホストが 1 つのユーザー名のみを使用する場合、 Liberty・リソースをインストールする ディレクトリーがそのユーザーによって書き込み可能であるようにすればいいだけです。異なるホストへの ジョブのサブミットをサポートするには、各ホスト上で同じユーザー名が構成されているように するか、または、SSH 鍵を使用して各ホストで異なるユーザー名として認証するようにします。
- 単一ユーザー名への切り替え
- ホストが複数のユーザー名をサポートする場合、さまざまなユーザー名の下で ジョブをサブミットできますが、単一の共通ユーザー名に切り替え るため sudo を使用します。共通ユーザー名のみが Liberty・リソースを管理できます。多くの場合、このユーザー名 はログインを使用不可にするよう構成されます。
- 異なるユーザー名
- 構成によっては、各 Liberty・リソースを
異なるオペレーティング・システム・ユーザー名の下でインストールできます。例えば、
共有リソースを 1 つ以上のユーザー名の下でインストールし、グローバルに読み取り専用にするか、
または、特定のオペレーティング・システム・グループにのみ読み取り専用にすることができます。非共有作業リソース
はユーザー名が異なれば使用できないよう排他的に作成することができます。
各リソースのルート・ディレクトリーの ファイル許可を制御することによって、誰が Liberty・リソース をインストールできるのかを制御できます。1 人のユーザーのみが書き込み可能 であるようにディレクトリーを設定すると、1 ユーザーのみがそのディレクトリーへのインストールを 実行できます。1 つのユーザー・グループが書き込み可能であるように ディレクトリーを設定すると、そのグループに所属するユーザーが、そのルート・ディレクトリーの下にリソースを インストールできます。グローバルに書き込み可能であるようにディレクトリーを 設定すると、どのユーザーでもそのディレクトリーにインストールできるようになります。
インストール中に、 他のユーザーによるリソース変更を防止するファイル許可を 設定できます。例えば、特定の 1 ユーザーまたは 1 グループのみが書き込み可能であるようにするファイル許可を指定して ${WLP_WORKING_DIR}/project1 を 事前作成できます。ユーザーが新しい Liberty (例えば server1) を インストールした後で、別のユーザーによって変更できないように ${WLP_WORKING_DIR}/project1/server1 を 構成することができます。
複数のユーザーがリソースにアクセスできる場合、以下のように、インベントリー・ジョブがすべての使用可能なリソースを検出できるようにする変数または ジョブ・パラメーターを設定する必要があります。
- 関連するすべてのパスでリソースが検索されるように、 WLP_ADDITIONAL_DIRS 変数を設定する必要があります。あるいは、
- インベントリー・ジョブの実行に使用されるユーザー名によってすべてのリソースが読み取り 可能であるようにする必要があります。リソースがグローバルに読み取り可能であるように 作成されているか、リソースがオペレーティング・システム・グループで読み取り可能 (そのグループに所属する ユーザー名で読み取り可能) であるか、または、インベントリー・ジョブを 実行するのに root ユーザー名が使用される必要があります。
基本のセキュリティー構成
管理エージェントとジョブ・マネージャーは、2 つの異なる基本のセキュリティー構成をサポートします。
管理エージェントのトポロジーでは、ユーザーが管理サブシステムの JMX コネクター・ポートにログインするか、管理コンソールから登録済みノードを選択すると、 基本ノードの許可テーブルが使用されます。
例えば、User1 には最初のベース・ノードの管理者としての権限が与えられていて、2 番目のノードに対する権限がないと仮定します。User2 には、2 番目のノードのコンフィギュレーターとしての権限が与えられていて、最初のノードに対する権限はありません。同じユーザー・レジストリーの図でこの例を示します。

さらに、User1 は、ユーザー名とパスワードを使用して、オペレーターとしてジョブ・マネージャーにログインできるとします。 User1 は、ユーザー名とパスワードを使用して、モニターとしてデプロイメント・マネージャーにログインすることもできます。 この例は、次の異なるユーザー・レジストリーの図で示されます。

User1 はジョブ・マネージャーとデプロイメント・マネージャーでユーザー名が同じですが、 異なるユーザー名とパスワードを使用することもできます。
セキュリティー情報の転送
ジョブ・マネージャーから管理エージェント、デプロイメント・マネージャー、またはホスト・コンピューターにジョブを転送される場合は、そのジョブをサブミットする者に関するセキュリティー情報も転送されます。この転送は、ジョブの実行中にユーザーを認証し権限を与えます。以下のユーザー・セキュリティー情報が、サブミットされたジョブと共に渡されます。
- ユーザー名
およびパスワード
ジョブをサブミットする際に、ユーザーはユーザー名とパスワードを指定します。ジョブが管理サブシステムまたはデプロイメント・マネージャーに到達すると、ユーザー名とパスワードがログインに使用されます。
同じユーザー・レジストリー構成の場合、John が最初のベース・ノードに対しジョブをサブミットすると、彼はジョブの一部として自分のユーザー名とパスワードを指定することができます。ユーザー名とパスワードが最初の管理サブシステムに対するログインに使用されると、ジョブが実行されます。John がデプロイメント・マネージャー・セルまたは 2 番目のベース・ノードに対してジョブをサブミットすると、John には権限がないためそのジョブは失敗します。
異なるユーザー・レジストリー構成の場合、John はそのデプロイメント・マネージャー・セルに自分のユーザー名とパスワードを指定して、デプロイメント・マネージャー・セルに対してジョブをサブミットできます。ジョブがデプロイメント・マネージャーに到達してログインが成功すると、ジョブが実行されます。John がベース・ノードに対してジョブをサブミットすると、アクセスが拒否され、そのジョブは失敗します。
- セキュリティー・トークン
ユーザーがジョブでユーザー名とパスワードを指定しないと、そのユーザーのクレデンシャルが、ジョブ・データベースでセキュリティー・トークンとして自動的に持続されます。トークンには、ユーザー・セキュリティー属性 (グループなど) が含まれています。ジョブが取り出されると、管理サブシステムまたはデプロイメント・マネージャーに対する認証および許可のためにトークンが使用されます。
同じユーザー・レジストリー構成の場合、John はユーザー名とパスワードを指定せずに、最初のベース・ノードに対してジョブをサブミットできます。John のクレデンシャルがセキュリティー・トークンとして自動的に管理サブシステムに伝搬され、そのジョブについて彼に権限を与えるために使用されるので、そのジョブは実行されます。 John が 2 番目のベース・ノードまたはデプロイメント・マネージャー・セルに対してジョブをサブミットすると、これら 2 つの環境では彼のセキュリティー・トークンには権限がないため、そのジョブは失敗します。
異なるユーザー・レジストリー構成の場合、ユーザーのセキュリティー・トークンは、サブミットされたジョブが管理サブシステムまたはデプロイメント・マネージャーに対して実行されることを自動的に許可しません。ユーザー・トークンを異なるレルムで使用可能にするには、複数のセキュリティー・ドメイン・フィーチャーを使用する必要があります。最初に、登録済みベース・ノードとデプロイメント・マネージャー・セルのトラステッド・レルムとしてジョブ・マネージャー・レルムを設定する必要があります。さらに、ユーザーのアクセス ID をジョブ・マネージャーからローカルの許可テーブルにインポートして、アクセス ID にロールを与える必要があります。こうすれば、ユーザーはユーザー名とパスワードを渡さずにジョブをサブミットできます。
John がジョブ・マネージャーのオペレーターで、彼の アクセス ID が管理者として最初のベース・ノードの管理許可テーブルにインポートされているとします。John はベース・ノードのユーザー・レジストリーに存在しませんが、セキュリティー・トークンと管理許可テーブルの定義を渡すことによって、John にはベース・ノードの管理者として権限が与えられます。John はユーザー名またはパスワードを指定せずに、最初のベース・ノードにジョブをサブミットすることができます。
John がデプロイメント・マネージャーに対してジョブをサブミットすると、ジョブは失敗します。John のセキュリティー・トークンはジョブ・マネージャー・レルムからであり、John のアクセス ID にはデプロイメント・マネージャーへの権限は与えられていません。この場合、管理者は John のアクセス ID をジョブ・マネージャーからエクスポートして、それをデプロイメント・マネージャーにインポートすることができます。または、John はデプロイメント・マネージャーで使用したユーザー名とパスワードを渡してジョブをサブミットできます。これにより John はモニターのロールでジョブを実行することができます。
きめ細かいセキュリティー・フィーチャーが使用されている場合は、同じ仕組みが利用できます。新規の許可グループでは許可テーブルで許可されている必要があります。許可テーブルにはまた、外部アクセス ID が含まれている場合があります。
混合レジストリー構成
一部のセルが同じユーザー・レジストリーを共有していて一部のセルが共有していない、さらに複雑なトポロジーでは、以下の規則が適用されます。