承認ポリシーはガバナンス レベルのポリシーです。展開および Day 2 アクションの申請が実行される前に、申請に対する制御を行うために追加します。Service Broker で承認ポリシーを定義することで、リソースが使用または破棄前に、承認者または承認者が指定したユーザーが申請を確認できるようにします。本手順では、承認ポリシーの使用事例を紹介し、ガバナンスのオプションについて解説します。

カタログ アイテムの追加と展開を行う小規模なチームのみが対象の場合、承認ポリシーは有用でないことがあります。しかし、大きなグループの開発者や一般的な利用者がカタログを利用できるようにする際には、承認ポリシーを使用することで、リソースの使用前やプロビジョニング済みのアイテムに変更を加える前に申請をチェックすることが可能になります。

たとえば、重要なカタログ アイテムが大量のリソースを使用している場合などです。この場合、IT 管理者に展開のすべての申請の確認を依頼し、申請の必要性を確認する必要があります。Day 2 アクションもこの場合に該当します。多くのユーザーが使用する展開に変更を加えると、非常に大きな影響が発生する可能性があります。この場合、チームの展開を管理するプロジェクト管理者は、カタログ アイテムに対するすべての変更を確認する必要があります。

承認ポリシーを使用するユーザーまたはその影響を受けるユーザー

  • Service Broker の管理者。ポリシーを構成します。
  • カタログの利用者。1 つ以上のポリシーが適用されるカタログ アイテムまたは Day 2 アクションを申請するユーザーです。
  • Cloud Assembly にクラウド テンプレートを展開しているユーザー。1 つ以上のポリシーが適用される Cloud Assembly のテンプレートまたは Day 2 アクションを申請するユーザー。
  • 指定された承認者。申請をチェックし、承認または拒否をする必要があるユーザーです。選択したユーザーおよびユーザー グループに承認者権限を付与することも、次の承認者ロールから選択することもできます。
    • AD Manager。マネージャ属性を持つ Active Directory ユーザー。AD Manager 承認者ロール用の Active Directory 属性の構成を参照してください。
    • プロジェクト管理者。ポリシー範囲内のプロジェクトの管理者は、自動的に承認者として割り当てられます。プロジェクトに専用の管理者が指定されていない場合、そのプロジェクトに承認ポリシーは適用されません。
    • プロジェクト スーパーバイザー。スーパーバイザー ロールが割り当てられた、ポリシー範囲内のプロジェクトのメンバー。スーパーバイザーのアクセス権は、プロジェクトの展開申請の承認と拒否のみに制限されます。プロジェクトに専用のスーパーバイザーが指定されていない場合、そのプロジェクトに承認ポリシーは適用されません。

承認ポリシーの適用プロセス

複数の承認ポリシーが適用可能な場合があります。承認ポリシーは評価が行われ、適用可能になったポリシーが申請に適用されます。有効なポリシーが複数あり、各ポリシーの承認者が異なる場合、すべての承認者が追加されます。複数のポリシーがある場合は、このプロセスを理解することが重要です。詳細については、承認ポリシーの目標と適用例を参照してください。

  1. 承認ポリシーが定義されます。
  2. ユーザーがカタログ アイテムまたは Day 2 アクションを申請します。申請が行われると、Service Broker はカタログ アイテムを評価し、適用されるポリシーの有無をチェックします。
  3. 承認ポリシーが適用されます。
    1. 展開カードにステータスが表示されます。たとえば、「Create - Approval Pending（作成 - 承認保留中）」などです。
    2. 申請者にメール通知が送信されます。承認が必要な申請を Service Brokerで追跡する方法を参照してください。
    3. 承認者にメール通知が送信されます。Service Brokerで承認申請に応答する方法を参照してください。

      展開を行う場合、申請が承認されるまでは、インフラストラクチャ リソースの展開および使用が開始されることはなく、展開済みのシステムが変更されることもありません。申請したユーザーに、申請が承認待ちの状態であることが E メールで通知されます。

    4. 承認者は Service Broker の [承認] 画面を使用して申請に応答します。
  4. 承認のプロセスは以上で完了です。
    1. 申請が拒否された場合には、申請したユーザーに通知が行われ、展開の申請はキャンセルされます。
    2. 申請が承認された場合には、展開が開始されます。
    3. 承認者がアクションを行わない場合でも、適用されるポリシーが申請を自動的に承認または拒否するように設定することもできます。

展開条件の使用方法

展開条件を定義することによって、ポリシーを適用するアイテムまたはアクティビティを制限できます。展開条件の詳細については、Service Broker ポリシーでの展開条件の構成方法を参照してください。

承認ポリシーの制約

  • 承認ポリシーには、リースの変更アクションを含めることはできません。
  • ポリシー基準の中でカスタム リソースをリソース タイプとして使用することはサポートされていません。

承認ポリシーの使用事例を参照して、独自のポリシーを作成する場合は、キー テキスト ボックスの Signpost ヘルプを参照して、詳細情報を確認してください。

前提条件

  • 承認者は、通常の Service Broker または Cloud Assembly のユーザーではない場合もありますが、次のロールの組み合わせのいずれかを保有している必要があります。
    • 組織のメンバーと Service Broker ユーザー
    • 組織のメンバーと承認の管理カスタム ロール

    これらのロールの権限は最小のレベルですが、申請の承認または拒否を行うことができます。

  • メール通知サーバが定義されていることを確認します。通知を送信するメール サーバの Service Broker への追加を参照してください。
  • ロールベースの承認タイプとして Active Directory マネージャを使用する場合は、vRealize Automation 用に構成された Workspace One Access と VMware Identity Manager の統合を使用する必要があります。また、ユーザー属性に Active Directory マネージャ属性も含める必要があります。AD Manager 承認者ロール用の Active Directory 属性の構成を参照してください。

手順

  1. [コンテンツおよびポリシー] > [ポリシー] > [定義] > [新規ポリシー] > [承認ポリシー] の順に選択します。
  2. 承認ポリシー 1 を構成します。
    管理者が、クラウド リソースを大量に使用する重要なカタログ アイテムを保有しています。数人のマネージャが展開の申請を評価し、申請の必要性と、展開をサポートするリソースの有無を確認するようにします。
    1. ポリシーを有効にするタイミングを定義します。
      設定 サンプルの値
      範囲 組織

      このポリシーは、組織内のすべてのプロジェクトに適用されます。

      基準 
      Catalog Item equals CompanyApplication
    2. 承認の動作を定義します。
      設定 サンプルの値
      承認レベル 1

      処理する順番に基づいてレベルに優先順位を付けます。
      承認タイプ [ユーザー ベース] を選択します。

      申請を承認するユーザーおよびユーザー グループを選択します。
      承認者モード すべて

      展開の申請によってリソースが浪費されないことについてすべての IT 管理者が同意することを条件にします。
      承認者 {GroupName1}@YourCompany、{ApproverName1}@YourCompany、{ApproverName2}@YourCompany

      承認申請は、ユーザー グループのすべてのメンバーに送信されます。グループのメンバーの 1 名のみが申請を承認する必要があります。
      自動有効期限の決定 拒否

      クラウド リソースの負荷を想定した場合、承認が得られないまま誤ってアイテムを展開することは望ましくありません。
      自動有効期限トリガー 3

      週末に管理者が不在になる可能性がある場合、この値を指定すると有効期限が週明けまで持ち越されます。
      アクション Deployment.Create
    このシナリオでは、カタログ利用者がこのカタログ アイテムを申請した場合、承認者 1、承認者 2、およびユーザー グループ 1 に属する 1 名が 3 日以内に申請を承認する必要があります。しなかった場合は申請が拒否されます。
  3. 承認ポリシー 2 を構成します。
    管理者として担当しているいくつかのプロジェクトについて、破壊的な結果をもたらす可能性のある変更を展開に加えることをプロジェクト管理者に承認してもらう必要があるとします。たとえば、展開を削除する場合です。
    1. 承認ポリシーが有効な場合を定義します。
      設定 サンプルの値
      範囲
      複数のプロジェクト 
      Project name contains Prod

      ポリシーは、範囲の基準に一致するすべてのプロジェクトに関連付けられている展開に適用されます。
      基準 なし
    2. 承認の動作を定義します。
      設定 サンプルの値
      承認レベル 1
      承認タイプ [ロール ベース] を選択します。
      承認者ロール プロジェクト管理者

      プロジェクトに専用の管理者が指定されていない場合、そのプロジェクトに関連付けられた申請に承認ポリシーは適用されません。

      承認者モード 任意
      自動有効期限の決定 拒否
      自動有効期限トリガー 7
      アクション Deployment.Delete、Deployment.PowerOff、Deployment.Update、およびコンポーネント固有の電源/再起動/削除アクションのいずれか。
    このシナリオでは、対象に含まれるプロジェクトのいずれかのメンバーが、ある展開に対してリストに表示したアクションを実行するように申請を送信して、プロジェクト管理者が応答しないときには、7 日後に申請が拒否されます。
  4. 承認ポリシー 3 を構成します。
    管理者は、リソース使用量の制御が必要になる場合があります。たとえば、ユーザーがサイズの大きいカタログ アイテムを申請した場合、その申請を評価してから承認する必要があります。サイズはフレーバー マッピングによって定義されます。
    1. 承認ポリシーが有効な場合を定義します。
      設定 サンプルの値
      範囲 組織
      基準 
      Resources has any 
     Flavor equals large
    2. 承認の動作を定義します。
      設定 サンプルの値
      承認レベル 1
      承認タイプ [ユーザー ベース] を選択します。
      承認者モード 任意
      承認者 {AdminName}@YourCompany
      自動有効期限の決定 拒否

      クラウド リソースの使用量を想定した場合、承認が得られないまま誤ってアイテムを展開することは望ましくありません。
      自動有効期限トリガー 5
      アクション Deployment.Create および該当する *.Machine.Resize アクション。たとえば、Cloud.vSphere.Machine.Resize です。
      このシナリオでは、ユーザーが大規模な展開の申請を送信したり、展開のサイズを大規模に変更して、クラウド管理者が応答しないときには、5 日後に申請が拒否されます。

次のタスク