vRealize Automation 組織の所有者またはサービス管理者は、組織およびサービスのシステム ロールを使用してユーザー アクセスを管理します。ただし、システム ロールでは許可されていないタスクの実行やコンテンツの表示が可能になるカスタム ロールを、一部のユーザーに対して作成することが必要な場合もあります。
このシナリオでは、サービス ユーザーと閲覧者、および使用事例 2 で定義されているプロジェクト メンバーと閲覧者のロールについて理解していることが前提となります。これらのロールは、使用事例 1 で使用されているサービスおよびプロジェクト管理者のロールよりも制約が多いことがわかります。これで、ローカルな使用事例をいくつか確認しました。これらの使用事例では、一部のユーザーに対して、ある機能については完全な管理権限を付与し、別の機能については表示権限を付与し、それ以外の機能セットについては表示を禁止するように設定します。これらの権限を定義するには、カスタム ロールを使用します。
この使用事例は、使用可能 3 つのローカルな使用事例に基づいています。この手順では、次のカスタム ロールの権限の作成方法について説明します。
- 制限付きインフラストラクチャ管理者。サービス管理者以外の一部のサービス ユーザーに、より広範なインフラストラクチャ権限を付与する必要があります。管理者として、これらのユーザーが、クラウド ゾーン、イメージ、およびフレーバーの設定をサポートできるようにする必要があります。また、これらのユーザーが、検出されたリソースのオンボーディングや管理を実行できるようにする必要もあります。これらのユーザーは、クラウド アカウントまたは統合を追加できないことに注意してください。これらのエンドポイントのインフラストラクチャの定義のみが実行可能です。
- 拡張性開発者。一部のサービス ユーザーに、プロジェクト チームやその他のプロジェクトのクラウド テンプレート開発の一環として、拡張性アクションとサブスクリプションを使用するための完全な権限を付与する必要があります。これらのユーザーは、複数のプロジェクト用のカスタム リソース タイプとカスタム アクションも作成します。
- XaaS 開発者。一部のサービス ユーザーには、複数のプロジェクトでカスタム リソース タイプとカスタム アクションの作成ができるように、フル権限を付与する必要があります。
- 展開のトラブルシューティング担当者。プロジェクト管理者に、失敗した展開に対してトラブルシューティングと根本原因分析を実行するために必要な権限を付与する必要があります。イメージやフレーバーのマッピングなど、損害につながりにくいカテゴリや、重要性の低いカテゴリに関する管理権限を付与します。また、失敗した展開のトラブルシューティング担当者ロールの一部として、承認および Day 2 ポリシーを設定する権限も付与する必要があります。
前提条件
- vRealize Autmoation Cloud ユーザー ロールについてで、Cloud Assembly および Service Broker のサービス ロールとプロジェクト ロールの表を確認します。各サービス ユーザー ロールがこれらのサービス内で表示できる内容と実行できる作業について理解しておく必要があります。
- カスタム ロールの説明を参照して、ユーザーの権限を変更する方法について確認します。
- 最初の使用事例を確認して、組織のロールとサービス管理者のロールについて確認します。ユーザー ロールの使用事例 1:小規模なアプリケーション開発チームをサポートするための vRealize Automation ユーザー ロールの設定を参照してください。
- サービス ユーザーおよびプロジェクト メンバーのロールを理解するために 2 番目の使用事例を確認します。ユーザー ロールの使用事例 2:大規模な展開チームとカタログをサポートするための vRealize Automation ユーザー ロールの設定を参照してください。
- Service Broker に慣れます。カタログへのコンテンツの追加を参照してください。
手順
結果
この使用事例では、サービスとプロジェクト ロールを展開するカスタム ロールを含む、さまざまなロールを持つ複数のユーザーを構成します。
次のタスク
ローカルな使用事例に対処するカスタム ロールを作成します。