1. はじめに
運用も楽しく自動化できるといいなーと言うことで、
AWSの代表的な構成管理サービスであるAWS Configを軽く触ってみました。
1.1. 【補足】AWS Configとは
AWS上に作成した各種リソースをまとめて構成管理してくれるサービスです。
リソース構成の変更を継続的に評価、モニタリング、記録してくれます。
また、AWS Config マネージドルールやカスタムルールを設定することで、リソースが所定のベストプラクティス、業界規制、独自ポリシーに準拠しているかを評価できます。PublicIPがEC2に付与されていないか、S3がパブリックアクセス可能になっていないか、など。。。
今回は触っていないのですが、ルールを守れていないリソースを、Config側から設定変更することもできます。
2. 設定してみる
マネジメントコンソールから有効化してみます。
リージョン内にレコーダーを作成します。レコーダーとは、リソース構成の記録と配信を行う基本的な単位です。
設定を行っていきます。
記録戦略には「特定のリソースタイプ」を選択します。
記録するリソースタイプのプルダウンが表示されるので、テストのためS3バケットを選択します。
構成状態の記録頻度は「日次」または「連続」から選ぶことができます。
今回は「連続」を選択し、変更が起こるたび、構成状態を記録します。
※「カスタマイズ可能なオーバーライドのある全てのリソースタイプ」を選択すると、リージョン内の全てのリソースの構成を管理できます。カスタマイズ可能なオーバーライドのある、とある通り、全てのリソースを監視対象としつつ、一部は監視対象外にするなどのカスタマイズが可能です。
サービスロールを設定します。
「サービスにリンクされたロール」を選択します。AWSConfigServiceRolePolicyというポリシーを持つAWS管理のサービスロールが使用されます。（Read権限がほとんどですが、全てのリソースの状態を取得できるようなポリシーなので、気になる方はロールを用意するのがおすすめです。）
配信方法で設定スナップショットを保存するS3を設定します。
監視対象リソースに適応するルールを選択します。
今回はテストとして、S3バケットがパブリックリードアクセス可能となっているかを監査する「s3-bucket-public-read-prohibited」ルールを選択します。
確認をクリックすると、レコーダーが作成され、S3バケットの構成管理が開始されます。
3. 動作確認
マネジメントコンソールから、リソースの状況を確認してみます。
ルールを全てパスしている準拠リソースが1つあることが分かります。
クリックして、リソースの詳細を確認してみます。
AWS Configレコーダーのスナップショットを保存するためのバケットが、さっそく監視されていました。
パブリックアクセスできない設定のため、コンプライアンス準拠判定になっています。
テストのため、S3バケット「my-test-paburikku-baketto」を新たに作成しました。
リソースのインベントリ内に、新た作成されたバケットが記録されました。
3.1. 記録しているリソースの設定状況を確認
リソースの設定状況を一覧できるのも、AWS Configの嬉しいトコロです。
リソースの詳細画面から、実際に設定状況を確認してみます。
S3の設定が一覧されています。
下の方に行くと、json形式でも一覧できます。
また、上部「リソースタイムライン」から、リソースの変更履歴も確認できます。
設定の変更内容と、その際のCloudTrailイベントが記録されています。すごい
中身を展開してみました。
リソースの変更差分や、履歴が辿れます。これは便利！
3.2. ルールに違反しているリソースを確認
設定したルールに違反しているリソースが存在する場合の挙動を確認してみます。
バケットポリシーを変更し、パブリックアクセス可能な状態にしてみました。
再びリソースのインベントリ画面を確認しにいきます。
変更したバケットがコンプラ非準拠と表示されました！
リソース群の監視、構成管理記録や、監視ルールの挙動を確認できました。
3.3. リソースの設定スナップショットを確認
指定したS3バケットへのスナップショット機能もテストしてみます。
AWS Config AWS リソースの設定の変更を追跡し、更新された設定の詳細を指定した Amazon S3 バケットに定期的に送信します。 AWS Config 記録するリソースタイプごとに、6 時間ごとに設定履歴ファイルが送信されます。各設定履歴ファイルには、その 6 時間の間に変更があったリソースの詳細が含まれています。各ファイルに含まれるリソースタイプは 1 つです (Amazon EC2 インスタンスや Amazon EBS ボリュームなど)。設定が変更されない場合、 AWS Config はファイルを送信しません。
デフォルトでは、S3へのスナップショット記録は6時間に1度とのことです。
aws cliで任意のタイミングでスナップショットを別途記録できるので、そちらの方法でテストしてみます。
$ aws configservice describe-delivery-channels --output=json
{
"DeliveryChannels": [
{
"name": "default",
"s3BucketName": "s3-config-history-test-xzdesnzvz"
}
]
}
コマンドのため、delivery-channelsの名前を取得します。
マネジメントコンソールから作成した場合は、nameがdefaultでチャンネルが作成されていました。
$ aws configservice deliver-config-snapshot --delivery-channel-name default
{
"configSnapshotId": "2b7a0d18-5f9e-4c3b-9d6c-b7f32e5d1f9a"
}
snapshotを作成するコマンドを実行します。成功するとIdが返ってきます。
S3を確認すると、圧縮されたjsonが保存されていることが確認できました。
構成管理データの永続化も問題なくできていそうです。
3.4. リソースの設定変更をSNSへパブリッシュ
AWS Configでは、S3への定期的なスナップショットのほかにも、変更を随時SNSへパブリッシュできる機能が備わっています。
コンプラ非準拠をSNSへ知らせ、lambdaやSQSへ連携できるわけです！試してみます。
今回は、Config > SNS > lambda > cloudwatchとパブリッシュされたイベントをパスし、内容を確認します。
まずはテスト用にトピック「sns_test_topic」を作成し、上記アクセスポリシーを付与しました。
AWSConfigServiceRolePolicyにはsns:Publishを明示的にAllowするポリシーが含まれていないため、トピック側のアクセスポリシーで明示的に許可しています。
exports.handler = async (event, context) => {
console.log(event.Records[0]);
return 'Hello from Lambda!';
};
また、SNSには上記関数を実行するlambdaをサブスクさせています。
SNSイベントをログ出力し、どのようなイベントがパブリッシュされるかをcloudwatchで確認します。
SNSトピックの準備ができたので、AWS Config側の設定画面から、SNSトピックを設定します。
S3の設定を適当に変更して、ログの内容を確認します。
3.4.1 リソースの設定変更イベント
全ての設定変更内容は随時SNSへパブリッシュされます。
S3のパブリックアクセスブロック設定を変更した際のログです。
変更箇所が記載されていることが確認できます。
3.4.2 設定変更によるルール非準拠化イベント
設定変更により、リソースがあるルールに非準拠する状態になった場合、追加のイベントがパブリッシュされます。
ルールに対し、NOT_COMPLIANT（非準拠）している状態であることがパブリッシュされていることが確認できます。
3.4.3 設定変更によるルール準拠化イベント
同様に、設定変更により、リソースがあるルールに準拠する状態になった場合、追加のイベントがパブリッシュされます。
ルールに対し、COMPLIANT（準拠）している状態であることがパブリッシュされていることが確認できます。
3.5. config設定の無効化
主な機能は動作確認したので、記録を止めてみます。
設定画面から、設定を変更します。
レコードが記録停止になったことが確認できます。
途中のダイアログにもあったように、記録自体は残り続けるようです。
内部のリソース（レコーダー、チャンネル、ルールなど）も削除自体はされていません。
サービスの特性を考えると当然ですね。
おわりに
SAAで何度も出題され、気になっていたAWS Configを触ってみました。
実際の現場でもぜひ使っていきたい便利なサービスで、とても楽しかったです。
使いそうなAWSサービスで遊ぶのは楽しいので、
遊ぶ、現場で提案してみる、遊ぶ、、、のループを回したいです！