AWS CodePipeline と Amazon Bedrock を使用して AWS Organizations ポリシーをコードとして管理する

Andre Cavalcante と Mariana Pessoa de Queiroz、Amazon Web Services

概要

で認可ポリシーを使用して AWS Organizations 、メンバーアカウントのプリンシパルとリソースのアクセスを一元的に設定および管理できます。サービスコントロールポリシー (SCPs、組織内の AWS Identity and Access Management (IAM) ロールとユーザーに使用可能なアクセス許可の最大数を定義します。リソースコントロールポリシー (RCPs、組織内のリソースで使用できる最大アクセス許可を定義します。

このパターンは、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを通じてデプロイするコードとしてのインフラストラクチャ (IaC) として SCPs と RCPs を管理するのに役立ちます。 AWS CloudFormation または Hashicorp Terraform を使用してこれらのポリシーを管理することで、複数の認可ポリシーの構築と維持に関連する負担を軽減できます。

このパターンには、次の機能が含まれています。

• マニフェストファイル (scp-management.json および ) を使用して、認可ポリシーを作成、削除、更新しますrcp-management.json。

• ポリシーの代わりにガードレールを使用します。マニフェストファイルでガードレールとそのターゲットを定義します。

• AWS CodeBuild および を使用するパイプラインは AWS CodePipeline、マニフェストファイルのガードレールをマージして最適化します。マニフェストファイル内の各ステートメントについて、パイプラインはガードレールを単一の SCP または RCP に結合し、定義されたターゲットに適用します。

• AWS Organizations はターゲットにポリシーを適用します。ターゲットは AWS アカウント、、組織単位 (OU)、環境 ( environments.json ファイルで定義したアカウントのグループまたは OUs)、またはAWS タグを共有するアカウントのグループです。

• Amazon Bedrock はパイプラインログを読み取り、すべてのポリシー変更を要約します。

• パイプラインには手動承認が必要です。承認者は、Amazon Bedrock が準備したエグゼクティブサマリーを確認できるため、変更を理解するのに役立ちます。

前提条件と制限

前提条件

• 組織として管理 AWS アカウント されている複数の AWS Organizations。詳細については、「組織の作成」を参照してください。

• SCP および RCP 機能は で有効になっています AWS Organizations。詳細については、「ポリシータイプの有効化」を参照してください。

• Terraform バージョン 1.9.8 以降がインストールされています。

• このソリューションを Terraform パイプライン経由でデプロイしない場合、Terraform 状態ファイルは、ポリシー管理パイプラインをデプロイ AWS アカウント する https://developer.hashicorp.com/terraform/language/backend/s3の Amazon Simple Storage Service (Amazon S3) バケットに保存する必要があります。

• Python バージョン 3.13.3 以降がインストールされています。

制約事項

• このパターンを使用して、この CI/CD パイプラインの外部で作成された SCPs または RCPsを管理することはできません。ただし、パイプラインを使用して既存のポリシーを再作成することはできます。詳細については、このパターンの追加情報「追加情報」セクションの「既存のポリシーをパイプラインに移行する」を参照してください。

• 各アカウントのアカウント、OUs、ポリシーの数には、 のクォータとサービス制限が適用されます AWS Organizations。

• このパターンは、バックアップポリシー AWS Organizations、タグポリシー、チャットアプリケーションポリシー、宣言ポリシーなど、 の管理ポリシーの設定には使用できません。

アーキテクチャ

次の図は、ポリシー管理パイプラインとその関連リソースのワークフローを示しています。

この図表は、次のワークフローを示しています：

1. ユーザーは、リモートリポジトリのメインブランチにある scp-management.jsonまたはrcp-management.jsonマニフェストファイルに変更をコミットします。

2. main ブランチへの変更により、パイプラインが開始されます AWS CodePipeline。

3. CodePipeline は Validate-Plan CodeBuild プロジェクトを開始します。このプロジェクトでは、リモートリポジトリの Python スクリプトを使用して、ポリシーとポリシーマニフェストファイルを検証します。この CodeBuild プロジェクトは以下を実行します。

   1. SCP マニフェストファイルと RCP マニフェストファイルに一意のステートメント IDs () が含まれていることを確認しますSid。

   2. scp-policy-processor/main.py および Python rcp-policy-processor/main.py スクリプトを使用して、ガードレールフォルダ内のガードレールを単一の RCP または SCP ポリシーに連結します。同じ Resource、、Actionおよび を持つガードレールを組み合わせますCondition。

   3. AWS Identity and Access Management Access Analyzer を使用して、最終的な最適化されたポリシーを検証します。検出結果がある場合、パイプラインは停止します。

   4. Terraform がリソースの作成に使用する ファイルscps.jsonと rcps.json ファイルを作成します。

   5. terraform plan コマンドを実行して、Terraform 実行プランを作成します。

4. （オプション) Validate-Plan CodeBuild プロジェクトは、bedrock-prompt/prompt.pyスクリプトを使用して Amazon Bedrock にプロンプトを送信します。ファイルでプロンプトを定義しますbedrock-prompt/prompt.txt。Amazon Bedrock は Anthropic Claude Sonnet 3.5 を使用して、Terraform ログと Python ログを分析して、提案された変更の概要を生成します。

5. CodePipeline は Amazon Simple Notification Service (Amazon SNS) トピックを使用して、変更を確認する必要があることを承認者に通知します。Amazon Bedrock が変更概要を生成した場合、通知にはこの概要が含まれます。

6. ポリシー承認者は CodePipeline でアクションを承認します。Amazon Bedrock が変更概要を生成した場合、承認者は承認する前に CodePipeline で概要を確認できます。

7. CodePipeline は Apply CodeBuild プロジェクトを開始します。このプロジェクトでは、Terraform を使用して RCP と SCP の変更を適用します AWS Organizations。

このアーキテクチャに関連付けられた IaC テンプレートは、ポリシー管理パイプラインをサポートする以下のリソースもデプロイします。

• scp-policy-processor/main.py や などの CodePipeline アーティファクトとスクリプトを保存するための Amazon S3 バケット bedrock-prompt/prompt.py

• このソリューションによって作成されたリソースを暗号化する AWS Key Management Service （AWS KMS) キー

ツール

AWS のサービス

• Amazon Bedrock はフルマネージド AI サービスで、多数の高性能基盤モデルを統合 API で使用できます。

• AWS CodeBuild は、ソースコードのコンパイル、ユニットテストの実行、デプロイ可能なアーティファクトの生成に役立つフルマネージド型のビルドサービスです。 

• AWS CodePipeline は、ソフトウェアリリースのさまざまなステージを迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。

• AWS Organizations は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。

• AWS SDK for Python (Boto3) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。

• Amazon Simple Storage Service (Amazon S3) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。

その他のツール

• HashiCorp Terraform は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングおよび管理するための IaC ツールです。

コードリポジトリ

このパターンのコードは、 organizations-policy-pipeline GitHub リポジトリで入手できます。以下は、 sample-repositoryフォルダに含まれるキーファイルです。

• environments フォルダに、 環境のリストenvironments.jsonが含まれています。環境はターゲットのグループであり、 AWS アカウント IDsまたは組織単位 (OUsを含めることができます。

• rcp-management フォルダで、次の操作を行います。

  • guardrails フォルダには、RCPs の個々のガードレールが含まれています。

  • policies フォルダには個々の RCPsが含まれます。

  • rcp-management.json マニフェストファイルは、RCP ガードレール、完全な RCPs、および関連するターゲットを管理するのに役立ちます。

• scp-management フォルダで、次の操作を行います。

  • guardrails フォルダには、SCPs の個々のガードレールが含まれています。

  • policies フォルダには個々の SCPsが含まれます。

  • scp-management.json マニフェストファイルは、SCP ガードレール、完全な SCPs、および関連するターゲットを管理するのに役立ちます。

• utils フォルダには、パイプラインを通じて管理できるように、現在の SCPsと RCPs を移行するのに役立つスクリプトが含まれています。詳細については、このパターンの「追加情報」セクションを参照してください。

ベストプラクティス

• パイプラインを設定する前に、 AWS Organizations クォータの制限に達していないことを確認することをお勧めします。

• AWS Organizations 管理アカウントは、そのアカウントで実行する必要があるタスクにのみ使用することをお勧めします。詳細については、「 管理アカウントのベストプラクティス」を参照してください。

エピック

ターゲットアカウントを設定する

タスク	説明	必要なスキル
リポジトリを作成します。	セキュリティオペレーションチームがポリシーを管理するリポジトリを作成します。 AWS CodeConnections がサポートするサードパーティーのリポジトリプロバイダーのいずれかを使用します。	DevOps エンジニア
ポリシー管理を委任します。	パイプラインをデプロイするメンバーアカウントに AWS Organizations ポリシーの管理を委任します。手順については、「 を使用してリソースベースの委任ポリシーを作成する AWS Organizations」を参照してください。サンプルポリシーについては、このパターンの追加情報「追加情報」セクションの「リソースベースの委任ポリシーのサンプル」を参照してください。	AWS 管理者
（オプション) 基盤モデルを有効にします。	ポリシーの変更の概要を生成する場合は、パイプラインをデプロイ AWS アカウント する の Amazon Bedrock で Anthropic Claude 3.5 Sonnet 基盤モデルへのアクセスを有効にします。手順については、「Amazon Bedrock 基盤モデルへのアクセスを追加または削除する」を参照してください。	AWS 全般

パイプラインのリソースをデプロイする

タスク	説明	必要なスキル
リポジトリをクローン作成します。	次のコマンドを入力して、GitHub から organizations-policy-pipeline リポジトリのクローンを作成します。 git clone https://github.com/aws-samples/organizations-policy-pipeline.git	DevOps エンジニア
デプロイ方法を定義します。	クローンされたリポジトリで、 variables.tf ファイルを開きます。 にはproject_name、デプロイされたリソースの名前に適用するプレフィックスを入力します。 にはprovider_type、リモートリポジトリのプロバイダーを入力します。有効な値は ファイルで提供されます。 にはfull_repository_name、リモートリポジトリの名前を入力します。 にはbranch_name、ポリシーのデプロイに使用する Git ブランチの名前を入力します。このブランチのプッシュまたはマージにより、パイプラインが開始されます。通常、これはメインブランチです。 にはterraform_version、使用している Terraform のバージョンを入力します。 でenable_bedrock、Amazon Bedrock に変更を要約するtrue場合は、「」と入力します。変更の概要を生成falseしない場合は、 を入力します。 にはtags、デプロイされたリソースにタグとして割り当てるキーと値のペアを入力します。 variables.tf ファイルを保存して閉じます。	DevOps エンジニア
パイプラインをデプロイします。	次のコマンドを入力してプランを作成し、変更を確認します。 terraform plan 次のコマンドを入力してプランを適用し、パイプラインインフラストラクチャを作成します。 terraform apply	DevOps エンジニア、Terraform
リモートリポジトリを接続します。	前のステップで、Terraform はサードパーティーリポジトリへの CodeConnections 接続を作成しました。AWS デベロッパーツールコンソールで、接続のステータスを PENDING から に変更しますAVAILABLE。手順については、「保留中の接続の更新」を参照してください。	AWS DevOps
Amazon SNS トピックを購読します。	Terraform が Amazon SNS トピックを作成しました。エンドポイントをトピックにサブスクライブし、サブスクリプションを確認して、承認者がパイプラインで保留中の承認アクションに関する通知を受信できるようにします。手順については、Amazon SNSトピックへのサブスクリプションの作成」を参照してください。	AWS 全般

ガードレールとポリシーを定義する

タスク	説明	必要なスキル
リモートリポジトリを入力します。	クローンされたリポジトリから、sample-repositoryフォルダの内容をリモートリポジトリにコピーします。これには、environments、、scp-management、および rcp-managementutilsフォルダが含まれます。	DevOps エンジニア
環境を定義します。	environments フォルダで、 environments.json ファイルを開きます。これは、RCPs AWS アカウント と SCP のターゲットと OUs を定義するファイルです。 SCPs サンプル環境を削除します。 次の形式でターゲット環境を追加します。 [ { "ID": "<environment-name>", "Target": [ "<ou-name>:<ou-id>", "<account-name>:<account-id>" ] } ] コードの説明は以下のとおりです。 <environment-name> は、OUsと AWS アカウントのグループに割り当てる名前です。マニフェストファイルでこの名前を使用して、ポリシーを適用する場所を定義できます。 <ou-name> はターゲット OU の名前です。 <ou-id> はターゲット OU の ID です。 <account-name> はターゲットの名前です AWS アカウント。 <account-id> はターゲットの ID です AWS アカウント。 例については、ソースコードリポジトリを参照してください。 environments.json ファイルを保存して閉じます。	DevOps エンジニア
ガードレールを定義します。	リモートリポジトリの rcp-management/guardrailsフォルダに移動します。これは、RCP マニフェストファイルのガードレールを定義するフォルダです。各ガードレールは、個々のファイルに含める必要があります。ガードレールファイルには、1 つ以上のステートメントを含めることができます。 注記 SCPs と RCPs のマニフェストファイルの複数のステートメントで同じガードレールを使用できます。ガードレールを変更すると、このガードレールを含むポリシーが影響を受けます。 ソースコードリポジトリからコピーされたガードレールの例をすべて削除します。 新しい .json ファイルを作成し、わかりやすい名前を付けます。 作成した .json ファイルを開きます。 ガードレールを次の形式で定義します。 [ { "Sid": "<guardrail-name>", "Effect": "<effect-value>", "Action": [ "<action-name>" ], "Resource": "<resource-arn>", "Condition": { "<condition-operator>": { "<condition-key>": [ "<condition-value>" ] } } } ] コードの説明は以下のとおりです。 <guardrail-name> はガードレールの一意の名前です。この名前は、他のガードレールには使用できません。 <effect-value> は Allowまたは である必要がありますDeny。詳細については、「Effect」を参照してください。 <action-name> は、サービスがサポートするアクションの有効な名前である必要があります。詳細については、「アクション」を参照してください。 <resource-arn> は、ガードレールが適用されるリソースの Amazon リソースネーム (ARN) です。* や などのワイルドカード文字を使用することもできます?。詳細については、「 リソース」を参照してください。 <condition-operator> は有効な条件演算子です。詳細については、「条件演算子」を参照してください。 <condition-key> は、有効なグローバル条件コンテキストキーまたはサービス固有のコンテキストキーです。詳細については、「条件」を参照してください。 <condition-value> は、ガードレールが適用されるかどうかを評価するために条件で使用される特定の値です。詳細については、「条件」を参照してください。 RCP ガードレールの例については、ソースコードリポジトリを参照してください。 .json ファイルを保存して閉じます。 これらのステップを繰り返して、必要な数の RCP ガードレールを作成します。 scp-management/guardrails フォルダでこれらのステップを繰り返して、SCPs に必要な数のガードレールを作成します。SCP ガードレールの例については、ソースコードリポジトリを参照してください。	DevOps エンジニア
ポリシーを定義します。	リモートリポジトリの rcp-management/policiesフォルダに移動します。これは、RCP マニフェストファイルの完全なポリシーを定義するフォルダです。各ポリシーは個別のファイルである必要があります。 注記 このフォルダのポリシーを変更すると、マニフェストファイルで定義されているように、ポリシーの変更は、このポリシーが適用されるすべてのアカウントまたは OUs に影響します。 ソースコードリポジトリからコピーされたポリシーの例をすべて削除します。 新しい .json ファイルを作成し、わかりやすい名前を付けます。 作成した .json ファイルを開きます。 RCP を定義します。RCPs「リソースコントロールポリシーの例」を参照してください。 https://github.com/aws-samples/organizations-policy-pipeline/tree/main/sample-repository/rcp-management/policies AWS Organizations .json ファイルを保存して閉じます。 これらのステップを繰り返して、必要な数の RCPsを作成します。 scp-management/policies フォルダでこれらのステップを繰り返して、必要な数の SCPsを作成します。SCPs「サービスコントロールポリシーの例」を参照してください。 https://github.com/aws-samples/organizations-policy-pipeline/tree/main/sample-repository/scp-management/policies AWS Organizations	DevOps エンジニア

マニフェストファイルを使用してポリシーを管理する

タスク	説明	必要なスキル
マニフェストファイルを設定します。	rcp-management フォルダで、 rcp-management.json ファイルを開きます。これは、ターゲット環境に適用する RCP ガードレールと完全な RCPs を定義するファイルです。このファイルの例については、ソースコードリポジトリを参照してください。 サンプルステートメントを削除します。 次の形式で新しいステートメントを追加します。 [ { "SID": "<statement-name>", "Target": { "Type": "<target-type>", "ID": "<target-name>" }, "Guardrails": [ "<guardrail-name>" ], "Policy": "<policy-name>", "Comments": "<comment-text>" } ] コードの説明は以下のとおりです。 <statement-name> は、 ステートメントの一意の名前です。 <target-type> は、ポリシーを適用するターゲットのタイプです。有効な値は Account、OU、Environment、または Tag です。 <target-name> は、ポリシーを適用するターゲットの識別子です。次のいずれかを入力します。 には AWS アカウント、識別子を として入力します<account-name>:<account-id>。 OU の場合は、識別子を として入力します<OU-name>:<ou-id>。 環境の場合は、 environments.json ファイルで定義した一意の名前を入力します。 タグには、キーと値のペアを として入力します<tag-key>:<tag-value>。 <guardrail-name> は、 rcp-management/guardrailsフォルダで定義した RCP ガードレールの一意の名前です。この要素には複数のガードレールを追加できます。ガードレールを適用しない場合は、このフィールドを空のままにすることができます。 <policy-name> は、 rcp-management/policiesフォルダで定義した RCP の一意の名前です。この要素に追加できるポリシーは 1 つだけです。ポリシーを適用しない場合は、このフィールドを空のままにすることができます。 <comment-text> は、ドキュメント目的で入力できる説明です。このフィールドは、パイプライン処理中は使用されません。コメントを追加しない場合は、このフィールドを空のままにすることができます。 これらのステップを繰り返して、組織の RCPs を設定するために必要な数のステートメントを追加します。 rcp-management.json ファイルを保存して閉じます。 scp-management フォルダで、 scp-management.json ファイルでこれらのステップを繰り返します。これは、ターゲット環境に適用する SCP ガードレールと完全な SCPs を定義するファイルです。このファイルの例については、ソースコードリポジトリを参照してください。	DevOps エンジニア
パイプラインを開始します。	variables.tf ファイルで定義したリモートリポジトリのブランチに変更をコミットしてプッシュします。通常、これはmainブランチです。CI/CD パイプラインが自動的に開始されます。パイプラインエラーがある場合は、このパターンの「トラブルシューティング」セクションを参照してください。	DevOps エンジニア
変更を承認します。	Validate-Plan CodeBuild プロジェクトが完了すると、ポリシー承認者は、以前に設定した Amazon SNS トピックを通じて通知を受け取ります。以下の操作を実行します。 通知メッセージを開きます。 可能な場合は、ポリシーの変更の概要を確認します。 CodePipeline の承認アクションを承認または拒否するの指示に従います。	AWS 全般、ポリシー承認者
デプロイを検証します。	委任管理者であるアカウントの AWS Organizations コンソールにサインインします AWS Organizations。 サービスコントロールポリシーページで、作成した SCPsが一覧表示されていることを確認します。 パイプラインを通じて管理される SCP を選択し、目的のターゲットに適用されることを確認します。 リソースコントロールポリシーページで、作成した RCPsが一覧表示されていることを確認します。 パイプラインを通じて管理される RCP を選択し、目的のターゲットに適用されることを確認します。	AWS 全般

トラブルシューティング

問題	ソリューション
パイプラインの Validate-Planフェーズでのマニフェストファイルエラー	scp-management.json または rcp-management.jsonファイルにエラーがある場合、「マニフェストファイルの検証と計画フェーズのパイプラインエラー」メッセージがパイプライン出力に表示されます。考えられるエラーには、誤った環境名、重複した SIDs、無効なフィールドや値などがあります。以下の操作を実行します。 「 でビルドの詳細を表示する AWS CodeBuild」の手順に従います。 ビルドログで、検証エラーを見つけます。エラーは、ビルドが失敗した原因に関する詳細情報を提供します。 対応する .json ファイルを更新します。 更新されたファイルをコミットし、リモートリポジトリにプッシュします。パイプラインが再起動します。 ステータスをモニタリングして、検証エラーが解決されたことを確認します。
パイプラインの Validate-Planフェーズでの IAM Access Analyzer の検出結果	ガードレールまたはポリシー定義にエラーがある場合、「検証と計画フェーズ中の IAM Access Analyzer の検出結果」メッセージがパイプライン出力に表示されます。このパターンでは、IAM Access Analyzer を使用して最終ポリシーを検証します。以下の操作を実行します。 「 でビルドの詳細を表示する AWS CodeBuild」の手順に従います。 ビルドログで、IAM Access Analyzer の検証エラーを見つけます。エラーは、ビルドが失敗した原因に関する詳細情報を提供します。検出結果タイプの詳細については、「IAM ポリシー検証チェックリファレンス」を参照してください。 ガードレールまたはポリシーに対応する .json ファイルを更新します。 更新されたファイルをコミットし、リモートリポジトリにプッシュします。パイプラインが再起動します。 ステータスをモニタリングして、検証エラーが解決されたことを確認します。

関連リソース

• JSON ポリシー要素リファレンス (IAM ドキュメント）

• リソースコントロールポリシー (AWS Organizations ドキュメント）

• サービスコントロールポリシー (AWS Organizations ドキュメント）

• Amazon Bedrock 基盤モデルへのアクセスを追加または削除する (Amazon Bedrock ドキュメント）

• CodePipeline の承認アクションを承認または拒否する (CodePipeline ドキュメント）

追加情報

リソースベースの委任ポリシーの例

以下は、 のリソースベースの委任ポリシーの例です AWS Organizations。これにより、委任された管理アカウントが組織の SCPs と RCPsを管理できるようになります。次のサンプルポリシーで、 をポリシー管理パイプラインをデプロイするアカウントの ID <MEMBER_ACCOUNT_ID>に置き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DelegationToAudit",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<MEMBER_ACCOUNT_ID>:root"
      },
      "Action": [
        "organizations:ListTargetsForPolicy",
        "organizations:CreatePolicy",
        "organizations:DeletePolicy",
        "organizations:AttachPolicy",
        "organizations:DetachPolicy",
        "organizations:DisablePolicyType",
        "organizations:EnablePolicyType",
        "organizations:UpdatePolicy",
        "organizations:DescribeEffectivePolicy",
        "organizations:DescribePolicy",
        "organizations:DescribeResourcePolicy"
      ],
      "Resource": "*"
    }
  ]
}

既存のポリシーをパイプラインに移行する

このパイプラインを介して移行および管理したい既存の SCPs または RCPs がある場合は、コードリポジトリの sample-repository/utilsフォルダにある Python スクリプトを使用できます。これらのスクリプトには以下が含まれます。

• check-if-scp-exists-in-env.py – このスクリプトは、指定したポリシーが、 environments.json ファイルで定義した特定の環境のターゲットに適用されるかどうかをチェックします。次のコマンドを入力して、このスクリプトを実行します。

  python3 check-if-scp-exists-in-env.py \
     --policy-type <POLICY_TYPE> \
     --policy-name <POLICY_NAME> \
     --env-id <ENV_ID>

  このコマンドで以下を置き換えます。

  • <POLICY_TYPE> は scp または rcp

  • <POLICY_NAME> は SCP または RCP の名前です。

  • <ENV_ID> は、 environments.json ファイルで定義した環境の ID です。

• create-environments.py – このスクリプトは、環境内の現在の SCPs と RCPs に基づいて environment.json ファイルを作成します。を通じてデプロイされたポリシーは除外されます AWS Control Tower。次のコマンドを入力してこのスクリプトを実行します。ここで、 <POLICY_TYPE>は scpまたは ですrcp。

  python create-environments.py --policy-type <POLICY_TYPE>

• verify-policies-capacity.py – このスクリプトは、定義した各環境をチェックして、各 AWS Organizations ポリシー関連のクォータに残っている容量を決定します。ファイル内の をチェックする環境を定義しますenvironments.json。次のコマンドを入力してこのスクリプトを実行します。ここで、 <POLICY_TYPE>は scpまたは ですrcp。

  python verify-policies-capacity.py --policy-type <POLICY_TYPE>