新しく追加された Declarative policies（宣言型ポリシー）について整理してみた

みなさん、こんにちは。 AWS CLI が好きなテクニカルサポート課の市野です。

AWS re:Invent 2024 前に発表された RCPs（Resource control policies）についての理解も追いついていないまま、2024年12月1日に Declarative policies（宣言型ポリシー）というものが追加されました。

本エントリでは、まずは今回新しく追加された Declarative policies（宣言型ポリシー）について整理をしてみました。

免責事項：
本ブログ記事内で、自身の理解・整理のために便宜上付与している呼び名があります。
それらについては原則イタリック体（italic）で表現するようにしていますが、AWS 公式の表現ではない点ご留意ください。

公式発表

aws.amazon.com

位置付け

AWS Organzations におけるポリシータイプには、大きく「Authorization policies（承認ポリシー）」と「Management policies（管理ポリシー）」の二つのカテゴリが存在しますが、AWS 公式ドキュメントによりますと Declarative policies（宣言型ポリシー）はそのうちの「Management policies（管理ポリシー）」に属するとなっています。

docs.aws.amazon.com

なお、上記二つのポリシーカテゴリについてや継承の考え方について「AWS Organizations の各ポリシーと継承について整理する (2024年10月版)」の記事で弊社の佐竹が整理していますので、ぜひご一読ください。

blog.serverworks.co.jp

Declarative policies（宣言型ポリシー）で制御可能な項目

制御可能な項目については、Declarative policy syntax and examples のページで、ポリシーの構文とともに解説されていますので本記事でも構文とともに見ていきます。

構文の構成要素

以下は Declarative policy syntax and examples のページからの抜粋に少し手を加えたものとなりますが、Declarative policies（宣言型ポリシー）の基本的な構文は以下の通りとなります。

{
    "ec2_attributes": {
        "exception_message": {
            "@@assign": "Your custom error message.https://myURL"
        },

        ... 
    
        [Insert supported service attributes]
   
        ...

        // 以降は筆者により加筆しています。
        // 自分自身の理解のために便宜上名称をつけていますので AWS の公式の呼び名でない点にご留意ください
        "${service-name}": {
            "${attributes}": {
                "${sub-attributes}": {
                    "${inheritance-operators}": "${configuration-value}"
                }
            }
        },
        "${service-name}": {
            "${attributes}": {
                "${inheritance-operators}": "${configuration-value}"
            }
        }
    }
}

上記の構文の中の構成要素を整理すると以下となります。

ec2_attributes：ポリシーの名前空間に相当するという理解が近いかと思いますが、どの AWS サービスに関連する Declarative policies（宣言型ポリシー）であるかの宣言部分となっています。現時点では「EC2 関連のサービスのみをサポート」とありますので、今後拡充されるものと見込まれます。
つまり、本エントリ執筆時点では ec2_attributes の値しか取り得ないこととなります。
exception_message：カスタムエラーメッセージを定義できるとあります。本日時点で公式ドキュメントの該当部分に記載されているリンクがリンク切れを起こしているため、カスタムエラーメッセージの詳細ページを確認することができませんが、実際の挙動や API リファレンスから最大 255 文字までの組織内で自由に適宜設定可能なエラーメッセージとなります。
実際の定義内容として以下の要領で記載
- ポリシーとして定義する AWS サービス（本ブログでは ${service-name} として整理）
  - ポリシーとして定義する属性（本ブログでは${attributes} として整理）
    - （場合により）属性として定義する副属性（本ブログでは${sub-attributes} として整理）
      - 継承演算子（本ブログでは${inheritance-operators} として整理）
      - 値（本ブログでは${configuration-value} として整理）

定義可能な属性

VPC Block Public Access

Amazon VPC およびサブネット内のリソースがインターネットゲートウェイ (IGW) を介してインターネットにアクセスできるかどうかの制御をします。

AWS サービス（${service-name}）: vpc_block_public_access

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
internet_gateway_block	mode	off	VPC Block Public Access を有効にしない状態です。
		block_ingress	VPC 内へ向かうすべてのインターネットトラフィックはブロックされます。これらのゲートウェイではアウトバウンド接続の確立のみが許可されるため、NAT ゲートウェイと egress-only のインターネットゲートウェイとの間のトラフィックのみが許可されます。また、除外設定をすることが可能です。
		block_bidirectional	インターネットゲートウェイ、egress-only のインターネットゲートウェイとの間の全てのトラフィックをブロックします。また、除外設定をすることが可能です。
	exclusions_allowed	enabled	アカウントごとに除外設定を可能にします。
		disabled	アカウントごとの除外設定を不可にします。

Serial Consol Access

EC2 シリアルコンソールにアクセスできるかどうかの制御をします。

AWS サービス（${service-name}）: serial_console_access

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
state	-	enabled	EC2 シリアルコンソールアクセスが許可されます。
		disabled	EC2 シリアルコンソールアクセスを不可とします。

Image Block Public Access

Amazon マシンイメージ (AMI) を公開可能にするかどうかの制御をします。

AWS サービス（${service-name}）: image_block_public_access

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
state	-	unblocked	Amazon マシンイメージ (AMI) の公開共有に制限をしない設定です。
		block_new_sharing	このポリシーを有効化した以降に、Amazon マシンイメージ (AMI) の公開共有をブロックします。すでに公開共有されている AMI は引き続き公開される仕様となります。

Allowed Images Settings

Amazon EC2 での Amazon マシンイメージ (AMI) の検出と使用を制御します。

AWS サービス（${service-name}）: allowed_images_settings

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
state	-	enabled	image_criteria 属性に定義した AMI ソースに強制する設定です。
		disabled	制限をしない設定です。
		audit_mode	監査モードで動作し、準拠していないイメージの識別のみ行い、使用のブロックまでは行わないモードです。
image_criteria	criteria_1 ... criteria_n	allowed_image_providers	許可された AMI ソースを定義するリストプロバイダー名（amazon、aws_marketplace、aws_backup_vault）やアカウント ID をカンマ区切りで列記可能です。

Instance Metadata Defaults

新しい EC2 インスタンスの起動に対して IMDS（Instance Metadata Service）のデフォルトを制御します。

AWS サービス（${service-name}）: instance_metadata_defaults

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
http_tokens	-	no_preference	その他のデフォルトが適用され、例として AMI のデフォルトが適用されるなどの挙動となります。
		required	IMDSv2 を使用する必要があります。IMDSv1 は使用不可となります。
		optional	IMDSv1 と IMDSv2 の両方が許可されます。
http_put_response_hop_limit	-	Integer	メタデータトークンが移動できるホップの最大数を整数値で設定します。 `-1(優先しない)` から最大 `64` までの値を取ることができ、最小 `2` を設定することが推奨されています。
http_endpoint	-	no_preference	その他のデフォルトが適用され、例として AMI のデフォルトが適用されるなどの挙動となります。
		enabled	インスタンスメタデータサービスエンドポイントへのアクセスを許可します。
		disabled	インスタンスメタデータサービスエンドポイントへのアクセスを拒否します。
instance_metadata_tags	-	no_preference	その他のデフォルトが適用され、例として AMI のデフォルトが適用されるなどの挙動となります。
		enabled	インスタンスタグにはインスタンスメタデータからのアクセスを許可します。
		disabled	インスタンスタグにはインスタンスメタデータからのアクセスを拒否します。

Snapshot Block Public Access

Amazon EBS スナップショットがパブリックにアクセス可能かどうかの制御をします。

AWS サービス（${service-name}）: snapshot_block_public_access

属性（${attributes}）	副属性（${sub-attributes}）	値（${configuration-value}）	作用
state	-	block_all_sharing	スナップショットのすべての公開共有をブロックします。すでに公開されているスナップショットも非公開として扱われ、公開されなくなります。
		block_new_sharing	このポリシーを有効化した以降の設定として、スナップショットの公開共有をブロックします。すでに公開共有されているスナップショットは引き続き公開される仕様となります。
		unblocked	スナップショットの公開共有に制限がない状態です。

ポリシータイプ

以下、公式ドキュメントにて、本日時点でのポリシータイプが記載されていますが、Declarative policies（宣言型ポリシー）はこのうち DECLARATIVE_POLICY_EC2 が相当します。

また、ポリシータイプについてはデフォルトでは無効状態となりますので、本機能を利用する前に、明示的な有効化が必要となります。

docs.aws.amazon.com

PolicyType
The policy type that you want to enable. You can specify one of the following values:

SERVICE_CONTROL_POLICY

RESOURCE_CONTROL_POLICY

DECLARATIVE_POLICY_EC2

BACKUP_POLICY

TAG_POLICY

CHATBOT_POLICY

AISERVICES_OPT_OUT_POLICY

適用範囲

前述で紹介した佐竹さんの「ブログ」でも整理されているように、組織のルート、組織単位（OU）、アカウントに対して付与することが可能です。

付与する対象による挙動

管理ポリシーを組織のルートにアタッチすると、組織内のすべての OU とアカウントがそのポリシーを継承します。
特定の OU に管理ポリシーをアタッチすると、その OU の直下または子 OU にあるアカウントがそのポリシーを継承します。
特定のアカウントに管理ポリシーを添付すると、そのポリシーはそのアカウントにのみ影響します。

利用手順

ここでは、「VPC Block Public Access」に対して「アカウントごとの除外設定を不可」とする条件で、全ての通信を不可とする想定、かつ組織のルートにポリシーを適用する想定で整理してみます。

また、管理者によって制限されていることと詳細を社内のドキュメントの URL に誘導するようなカスタムのエラーメッセージを出す想定にしています。

現状の有効化済みポリシータイプの確認

aws organizations list-roots コマンドを活用すると、有効化されているポリシータイプのみ返却されますので、この値により確認が可能です。

実行例

aws organizations list-roots
# コマンド実行後のレスポンスの例
{
    "Roots": [
        {
            "Id": "r-xxxj",
            "Arn": "arn:aws:organizations::xxxxxxxxxxxx:root/o-xxxxxxxxxx/r-xxxj",
            "Name": "Root",
            "PolicyTypes": [
                {
                    "Type": "AISERVICES_OPT_OUT_POLICY",
                    "Status": "ENABLED"
                },
                {
                    "Type": "RESOURCE_CONTROL_POLICY",
                    "Status": "ENABLED"
                },
                {
                    "Type": "SERVICE_CONTROL_POLICY",
                    "Status": "ENABLED"
                }
            ]
        }
    ]
}

AWS Organizations Root ID の取得

前述の aws organizations list-roots コマンドの返却値に含まれる Id を取得します。

実行例

root_id=$(aws organizations list-roots --query 'Roots[].Id' --output text)

Declarative policies（宣言型ポリシー）機能の有効化

前述の通り Declarative policies（宣言型ポリシー）を示すポリシータイプは DECLARATIVE_POLICY_EC2 となりますので、aws organizations enable-policy-type コマンドにより有効化します。

また、このコマンドは正常終了後に、完了後の有効化されているポリシータイプを返却しますので、レスポンスの中に DECLARATIVE_POLICY_EC2 が含まれていれば正しく処理ができていると判断できます。

実行例

aws organizations enable-policy-type \
  --root-id "${root_id}" \
  --policy-type "DECLARATIVE_POLICY_EC2"
# コマンド実行後のレスポンスの例
{
    "Root": {
        "Id": "r-xxxj",
        "Arn": "arn:aws:organizations::xxxxxxxxxxxx:root/o-xxxxxxxxxx/r-xxxj",
        "Name": "Root",
        "PolicyTypes": [
            {
                "Type": "AISERVICES_OPT_OUT_POLICY",
                "Status": "ENABLED"
            },
            {
                "Type": "DECLARATIVE_POLICY_EC2",
                "Status": "ENABLED"
            },
            {
                "Type": "RESOURCE_CONTROL_POLICY",
                "Status": "ENABLED"
            },
            {
                "Type": "SERVICE_CONTROL_POLICY",
                "Status": "ENABLED"
            }
        ]
    }
}

ポリシードキュメントの作成

付与するポリシードキュメントを作成します。

前述の構文の構成要素、および、定義可能な属性で見た通り、以下の要領でポリシーの内容を定義します。

実行例

cat << EOF > vpc_block_public_access.json
{
    "ec2_attributes": {
        "exception_message": {
            "@@assign": "All communication with the Internet has been restricted by the administrator.\nSee https://example.com for details."
        },
        "vpc_block_public_access": {
            "internet_gateway_block": {
                "mode": {
                    "@@assign": "block_bidirectional"
                },
                "exclusions_allowed": {
                    "@@assign": "disabled"
                }
            }
        }
    }
}
EOF

ポリシーの作成

前述までで組み立てたポリシードキュメントを使用し、ポリシーを作成します。

実行例

aws organizations create-policy \
  --content file://vpc_block_public_access.json \
  --description "Restrict all resources from communicating to and from the Internet bidirectional" \
  --name "VPC Block Public Access Policy" \
  --type "DECLARATIVE_POLICY_EC2"

作成済みポリシーの ID の取得

前工程で作成したポリシーの ID を取得します。

実行例

policy_id=$(aws organizations list-policies --filter "DECLARATIVE_POLICY_EC2" --query "Policies[?Name==\`VPC Block Public Access Policy\`].Id" --output text)

ポリシーのアタッチ

ここまでの工程で作成したポリシー情報とアタッチ先のターゲットの情報を指定し、ポリシーのアタッチをします。

実行例

aws organizations attach-policy \
  --policy-id "${policy_id}" \
  --target-id "${root_id}"

備考

上記の利用手順の例では、ポリシーの作成を行い、即座にポリシーのアタッチを行なっていますが、「アカウントステータスレポート」を使用することで指定したアカウント、AWS リージョンを網羅した概要や詳細な CSV の取得が可能になり、ポリシーアタッチ前の準備にご利用が可能です。

詳細は、AWS 公式ブログに記載がございますので割愛いたしますが、作業の概要としては、ステータスレポートの出力先として S3 バケットを用意し、所定のバケットポリシーの付与が必要です。

aws.amazon.com

その後、AWS Organizations の信頼されたアクセスを有効にするサービスとして、サービスプリンシパルに ec2.amazonaws.com を設定した上で、「アカウントステータスレポート」の作成を実施する流れとなります。

なお「アカウントステータスレポート」の作成着手後、内部的に選択したアカウントをクロールする挙動をしていると思われます。

検証時には管理アカウントを含め 5 アカウント程度の小さな AWS Organizations 組織で実施したため、5分程度でアカウントステータスレポートが作成されましたが、多くのアカウントを内包する組織である程度の数量のアカウントを対象にする場合は、一定程度時間を要する可能性があります。

まとめ

ざっと要点をまとめてみましたが、管理者として実行してほしくない内容に対して処理を行える機能は今までもありましたが、SCP などでは実際に制御しているポリシーの全容を開示できないなど、一利用者に対して詳細を伝えられない場面もあったかと思います。

Declarative policies（宣言型ポリシー）であれば、カスタマイズ可能なエラーメッセージにより禁止されているリソースの作成内容であることを伝えられる利点があるかと考えられます。

リリースされたばかりのサービスのため、具体的な事例やユースケースのご案内が薄いところがありますが、まずは概要把握にお役立ていただけますと幸いです。

ではまた。