こんにちは、アプリケーションサービス部ディベロップメントサービス1課の滝澤です。
本記事をご覧いただきありがとうございます。
今回、AWS Config カスタムポリシールールについて調査しましたので、基本編・応用編の2本立てでお届けしたいと思います。
本記事の概要
本記事は「AWS Config カスタムポリシールール（Guard）の作成方法 ~1. 基本編~」となります。
AWS Config カスタムポリシールールの概要と簡単なサンプルルールの作成まで説明いたします。
基本は理解している、さらに細かい記法が知りたいという方はぜひ応用編も併せてご覧いただければと思います。
AWS Config カスタムポリシールールとは
AWS Config とは
AWS Config は、AWS アカウントにある AWS リソースに関する設定の詳細ビューを提供するサービスです。
サポートされているリソースタイプは「サポートされているリソースタイプ」をご参照ください。
AWS Config ルールとは
AWS Config ルールは、AWS Config を使用して収集した AWS リソースの設定項目に対して評価を行うためのもので、大きく
- AWS Config マネージドルール
- AWS Config カスタムルール
の2つに分類することができます。
AWS Config マネージドルールは、AWS によって管理されている事前定義されたルールです。
例えば、IAM ユーザが多要素認証（MFA）を有効にしているかどうかチェックするiam-user-mfa-enabledといったルールがあります。
その他のルールについては、「AWS Config マネージドルールのリスト」をご参照ください。
一方で、AWS Config カスタムルールは1から作成するルールで
- AWS Config カスタム Lambda ルール
- AWS Config カスタムポリシールール
の2つが存在します。
AWS Config カスタム Lambda ルールはその名の通り、Lambda 関数を使用した方法で、 AWS Config カスタムポリシールール はポリシーをコード化する言語である Guard を使用した方法です。 Guard の詳細については「Guard ルールの記述」を参照してください。
本記事でご紹介するのは AWS Config カスタムポリシールールですが、 AWS Configカスタム Lambda ルールの作成を支援する開発キットである、AWS Config Rule Development Kit（RDK）についてのブログもありますので、気になる方はご覧ください。
AWS Config カスタムポリシールールとは
AWS Config カスタムポリシールール（以下、カスタムポリシールール）は前述したように Guard という言語を使用して記述します。
評価結果はPASS（準拠）／FAIL（非準拠）／SKIP（表示されない）の3種類を返します。
カスタムポリシールールを使用するメリットデメリットは以下の通りです。
メリット
- マネージドルールよりも柔軟な設定が可能
- コアな部分のみ記述すればよい
デメリット
- カスタム Lambda ルールほど細かい設定は不可能
- AWS Config にサポートされているリソースタイプのみ評価可能
- Guard についての文献が少ないため、ほぼ公式ドキュメント頼り
マネージドルールはすぐ適用できるが柔軟性が低い、カスタム Lambda ルールは細かい評価ができるが作成に時間的コストがかかるという特徴があり、カスタムポリシールールはその中間という位置付けにあたります。
ルールを作成したい場合、マネージドルールで要件を満たすことができないか検討して、不可能ならカスタムポリシールール、それも不可能ならカスタム Lambda ルールという選定方法が効率的です。
カスタムポリシールールの基本的な記法
ここからはカスタムポリシールールの基本的な記法について説明していきます。
今回サンプルで作成するルールは、
- EC2 インスタンスのインスタンスタイプが
t2.microの場合にPASS（準拠）
と評価するものとします。
基本的な形
カスタムポリシールールは AWS Config が収集した AWS リソースの設定項目（スキーマ）をqueryとして指定し、operatorを使用して評価します。
<query> <operator> [query|value literal]
query
ドット（.）で表す階層データのこと
スキーマに関しては「AWS Config Resource Schema GitHub Repository」の「resource-types」をご参照ください。
※AWS Config でサポートされていても、この GitHub に載っていない場合もあるのでご注意ください。
operator
▼ Unary Operators（単項演算子）
exists, empty, is_string, is_list, is_struct, is_bool, is_int, is_float, not(!)
▼ Binary Operators（二項演算子）
==, !=, >, >=, <, <=, IN
今回作成するルール
今回作成するルールでは、EC2 インスタンスのインスタンスタイプの情報を取得したいのでqueryで何を指定するべきか、 「resource-types」で確認します。
resource-types の AWS::EC2::Instance.properties.jsonの39行目に"configuration.instanceType": "string"というスキーマが存在するので、今回はこれをqueryとして使用します。
以上の情報から要件を満たすルールは
configuration.instanceType == "t2.micro"
と記述できます。
シンプルな要件ではありますが、1行で簡単に記述できることがわかるかと思います。
デプロイ方法
では、実際に作成したルールを AWS 環境にデプロイしてみようと思います。
以下に手順を示します。
- AWS マネジメントコンソールにログイン
- AWS Config のサービス画面に移動
- ナビゲーションペインから
ルールを選択し、ルールを追加を押す
- ルールタイプは
Guard を使用してカスタムルールを作成を選択
- ルール名は
ec2-desired-instance-typeとする
- Rule content に先ほど記述したルール本文を貼付する
- EC2 インスタンスに対して評価を行いたいため、変更範囲を
リソース/AWS EC2 Instanceに設定する
- その他の設定はデフォルトで
保存
作成したルールの確認方法
- ルール一覧から先ほどデプロイしたルールを選択する
- 対象範囲内のリソースを確認して、要件通りの結果になっているか確認する
これで EC2 インスタンスのインスタンスタイプがt2.microの場合のみ準拠として評価するルールを AWS 環境に作成することができました。
まとめ
本記事では、AWS Config カスタムポリシールールの概要から簡単なサンプルルールの作成まで紹介させていただきました。
応用編ではさらに細かい記法についても触れていますので、ご興味がある方はぜひご覧いただけるとありがたいです。
本記事が少しでもお役に立てれば幸いです。
