Organizationsのdeclarative policiesでIMDSv1許容のEC2を禁止できるか試す
はじめに
今回は先日公開されたOrganizationsのdeclarative policiesの中で、特にIMDS周りの制御に関して調査してみます。
IMDSは基本v2で使うことがメインだと思いますが、コンソールからEC2を作成した場合IMDSv1を許容して作成してしまうというケースは未だにあるかと思います。今回の設定でそれを組織的に防げるのか、また既存のIMDSv1の設定のEC2はどうなるのかなどを検証してみます。
結論
- この機能はアカウントレベルのIMDS デフォルト設定を組織で管理できようになるもの
- メンバーアカウント側でEC2作成時に設定を変えるとIMDS v1を許容するインスタンスは作成可能なので、完全に禁止はできない
検証パターン
設定を有効化した際の影響を確認するため、以下のEC2に対して影響を試していきます。
- IMDSv1を許容するEC2を作成後、設定適用
- IMDSv2を必須となるEC2を作成後、設定適用
- 設定適用後にIMDSv1を許容するEC2を作成
やってみた
EC2をメンバーアカウントで事前準備
まず事前に以下のようにIMDSv1/2のEC2をメンバーアカウント上で作成しておきます。
IMDSv1許容の場合の表示
IMDSv1必須の場合の表示
ちなみにIMDSv1を許容するインスンタンスは以下のようにコンソール上で設定して作ります。
最後にアカウントレベルのIMDS デフォルト設定を確認します。以下のように特に指定はされていなく変更可能です。
管理アカウントでdeclarative policiesを有効化
以下のようにOrganizationsから画面操作を進め設定を有効化していきます。
まずは「EC2宣言的ポリシーを有効にする」を押下して設定を有効化します。
「ポリシーを作成」で今回作成する設定を作ります。
ポリシー名は適当にno-use-imdsv1
と付けます。
「サービス属性を選択」から選ぶとデフォルトで以下の用に表示されます。
インスタンスメタデータサービスは優先度なし、有効、無効の3つが設定できます。
メタデータのバージョンもv2のみ、優先度なし、オプションから選択できます。
JSONで見ると以下のようになっています。
{
"ec2_attributes": {
"instance_metadata_defaults": {
"http_tokens": {
"@@assign": "required"
},
"http_put_response_hop_limit": {
"@@assign": -1
},
"http_endpoint": {
"@@assign": "no_preference"
},
"instance_metadata_tags": {
"@@assign": "no_preference"
}
}
}
}
詳細が気になる場合は、以下をご確認ください。
今回は、IMDSv2を強制するため設定はデフォルトのまま変更せず適用します。画面下部の「ポリシーを作成」を押下します。
このポリシーを適用したいOUにアタッチしていきます。
当てたいOUを選択してポリシーをアタッチします。
上記で設定完了です。
メンバーアカウント側で確認
最後にメンバーアカウントに戻って状態を確認します。
IMDSv1を許可していたEC2は、ポリシー適用後も変わらずでした。IMDSv2必須のEC2も変化なしです。
再度アカウントレベルのIMDS デフォルト設定を確認します。以下のようにメタデータのバージョンがv2になっており、管理ボタンも押下できなくなっています。今回の機能追加でOrganizationsでこの項目を組織的に管理できるようになったことがわかります。
注意:この後で新規にIMDSv1を許容するのEC2を作ってみました。デフォルト設定から手動でEC2作成時に設定変更すると作成することができました。完全にIMDSv1を許容するインスタンスの作成を禁止することはできないようでした。
所感
最初は完全に禁止する機能と勘違いしていたのですが、アカウントレベルの設定を組織で管理できるものと理解すると挙動がわかりました。抜け道はできてしまうものの、この設定が今まで組織で管理しようとするとAPI発行がアカウント単位で必要なので、後回しになっている場合も多いのではないかなと思います。自分たちでAPI実行する機能を実装するよりは負担が少ないので、この実験結果見て是非設定試してみてください。