AWS Config カスタムポリシールール(Guard) ~2. 応用編~

記事タイトルとURLをコピーする

こんにちは、アプリケーションサービス部ディベロップメントサービス1課の滝澤です。

本記事をご覧いただきありがとうございます。

今回、AWS Config カスタムポリシールールについて調査しましたので、基本編・応用編の2本立てでお届けしたいと思います。

本記事の概要

本記事は「AWS Config カスタムポリシールール(Guard)~2. 応用編~」となります。

基本編では AWS Config カスタムポリシールールの概要と簡単なサンプルルールの作成まで紹介しました。

応用編では、さらに細かいルールの記法についてそれぞれに簡単な例を提示する形で紹介させていただきます。

概要について知りたいという方はまずは基本編からご覧いただければと思います。

blog.serverworks.co.jp

応用的な Guard のルール

custom message

記法

基本編にて、Guard の基本的な形は

<query> <operator> [query|value literal]

だとお伝えしましたが、行末にcustom messageというものを加えることも可能です。

 <query> <operator> [query|value literal] [custom message]

custom messageを記述することで非準拠として評価された場合にその内容が注釈にメッセージが表示されるようになります。

直接ルールに関係するものではありませんが、ポリシーに則っていない箇所を明示できるので便利です。

例えば、基本編で作成したルールに対して以下のような custom message を記述することで、ルールに非準拠だった場合(インスタンスタイプがt2.microではなかった場合)にAllowed instanceType is t2.microというメッセージを表示させることが可能です。

configuration.instanceType == "t2.micro" <<Allowed instanceType is t2.micro>>

範囲指定

基本形のquery|value literalでサポートされているプリミティブは以下の6つですが、

string、integer(64)、float(64)、bool、char、regex

そのうち、integer(64)、float(64)、charに関しては範囲指定が可能です。

記法

記号 意味
[ 以上
] 以下
( より大きい
) 未満
記法 意味
r[<lower_limit>, <upper_limit>] lower_limit <= k <= upper_limit
r[<lower_limit>, <upper_limit>) lower_limit <= k < upper_limit
r(<lower_limit>, <upper_limit>] lower_limit < k <= upper_limit
r(<lower_limit>, <upper_limit>) lower_limit < k < upper_limit

例として、EBSのサイズが8 GiB より大きく、100 GiB 以下だった場合に準拠とするルールを作成します。

  • リソースタイプ:AWS EC2 Volume
configuration.size IN r(8,100]

配列走査

実際のリソースの設定項目を見ると、例えば Tag などは配列型で表現されていることが確認できます。

(省略)
  "configuration": {
(省略)
    "tags": [
      {
        "key": "System",
        "value": "test-system"
      },
      {
        "key": "Name",
        "value": "test"
      }
    ],
(省略)

その配列に対して走査を行う記法を紹介します。

記法

queryでスキーマを指定する際に、tagsではなくtags[*]を使用します。

  • リソースタイプ:AWS EC2 Instance
configuration.tags[*].key == "System"

tags配列を走査して配列内のすべての項目が要件を満たしている(すべてのタグのキーが System である) 場合に準拠

System というキー以外のタグが1つでもあった場合に非準拠となります。

some

前述の配列走査の方法では、準拠と評価されるには配列内すべての項目でルールの要件を満たす必要がありますが、

some を使用することで、配列内のいずれか1つがルールの要件を満たしていると準拠とすることができます。

記法

行頭にsomeを記述する

  • リソースタイプ:AWS EC2 Instance
some configuration.tags[*].key == "System"

System というキーのタグが1つでもあった場合に準拠となります。

パラメータ

Guard でルールを作成する際、パラメータを入力しそれをルール内で使用することができます。

▼AWS Config > ルール > ルールを追加 > ステップ 2 : ルールの設定 より

記法

ルール内でCONFIG_RULE_PARAMETERSを使用して呼び出す

配列走査で作成したルールで評価しているタグのキーをパラメータから入力するようにします。

  • リソースタイプ:AWS EC2 Instance

パラメータ

configuration.tags[*].key == CONFIG_RULE_PARAMETERS.RequiredTagKey

結果は、配列走査と同じ評価となりました。

論理積

記法

改行すると暗黙的に論理積として処理される

# clause_A ^ clause_B ^ clause_C
clause_A
clause_B
clause_C

EC2 インスタンスのタグにおいて、キー名がSystemのものがある、かつキー名がProjectのものがあるときに準拠とするルールを作成する。

  • リソースタイプ:AWS EC2 Instance
some configuration.tags[*].key == "System"
some configuration.tags[*].key == "Project"

論理和

記法

[or|OR] を置くことで論理和として処理される

# clause_A v clause_B
clause_A or
clause_B

EC2 インスタンスのタグにおいて、キー名がSystemのものがある、またはキー名がProjectのものがあるときに準拠とするルールを作成する。

  • リソースタイプ:AWS EC2 Instance
some configuration.tags[*].key == "System" or
some configuration.tags[*].key == "Project"

when

条件つきでルールの評価が可能なのがこのwhenです。

記法

conditionがtrueのとき評価される

when <condition> {
    Guard_rule_1
    Guard_rule_2
    ...
}

Systemというキーのタグが存在する EC2 インスタンスに対し、インスタンスタイプがt2.microであった場合に準拠とする

  • リソースタイプ:AWS EC2 Instance
when some configuration.tags[*].key == "System" {
    configuration.instanceType == "t2.micro"
}

conditionfalseのリソースは、評価結果がSKIP(表示されない)となることに注意が必要です。

変数

記法

変数はletを使用することで割り当てることができ、%変数で呼び出すことが可能です。

  • リソースタイプ:AWS EC2 Instance
let desiredInstanceType = "t2.micro"
configuration.instanceType == %desiredInstanceType

結果は基本編で作成したルールと同様の評価となりました。

正規表現

記法

▼確認した正規表現

記号 意味
/ 正規表現の開始と終了
^ 先頭
$ 末尾
. 任意の一文字
* 直前の文字を繰り返す
\ エスケープ
(?i) 以降の大文字小文字を区別しない

※おそらくこれ以外の正規表現も問題なく使用できると推測しています

EC2 インスタンスのインスタンスタイプがt2から始まるタイプだった場合に準拠と評価するルールを作成します。

  • リソースタイプ:AWS EC2 Instance
configuration.instanceType == /^t2/

まとめ

本記事では応用的なカスタムポリシールールの作成方法について紹介しました。

今回ご紹介した方法を使用して作成したいルールが実現できるのであれば幸いですが、

実現できそうにないという場合は、カスタム Lambda ルールの作成を支援してくれる開発キットの AWS Config Rule Development Kit(RDK) を使用することも視野に入れると効率的なルールの作成ができるかと思います。

そのときはぜひこちらのブログもご覧ください。

blog.serverworks.co.jp

本記事が少しでもお役に立てれば幸いです。