この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Control Tower環境下でまだサポートしていない大阪リージョンにConfigを有効化することがあったので、Control Towerのカスタマイズ(CfCT)を使って自動で有効化してみました。
CfCTを導入していない環境では以下のStackSetsから有効化も可能です。
AWS Control Tower がサポートしていないリージョンで Configを有効化する | DevelopersIO
前提条件
CfCTが展開されている
CfCTを利用してConfigを展開するため、既にCfCTが展開されている前提です。マニフェストファイルとCloudFormationテンプレートを用意したらプッシュするだけの状態で実施します。今回はCfCTのソースをCodeCommitで実行します。
参考：Control Towerカスタマイズソリューション(CfCT)を使ってガードレールとCloudFormationを自動展開してみた | DevelopersIO
Configを無効化する
Configレコーダーはリージョンごとに1つのため、対象のアカウント・リージョンは全て無効化しておきましょう。一応ConfigはControl Towerのガードレールによって特定のロール以外は設定できないようになっているので、管理外リージョンは無効化されているはずです。
やってみる
今回はControl Towerによって作成されるS3バケットを指定して大阪リージョンのConfigログを出力しています。
CfCTでプッシュするフォルダ構成は以下の通りです。
custom-control-tower-configuration
├── manifest.yaml
└── template
└── config.yamlCfCTのマニフェストファイル
展開先のOU・アカウントやリージョンを定義するmanifest.yamlを作成します。
今回は全アカウントを対象とするためRootを指定、対象リージョンは大阪リージョンのみにしています。
Parametersで定義しているバケット名とプレフィックスは保存先バケットに合わせて変更してください。今回はControl Towerで作成されている以下のS3バケットを対象として実行しています。
- BucketName:
aws-controltower-logs-{AccountID}-ap-northeast-1 - S3KeyPrefix:
o-xxxxxxxx
- name: add-config-oosaka-region
description: Control Tower Custom CloudFormation Resources - Add Config
resource_file: template/config.yaml
deploy_method: stack_set
Parameters:
- parameter_key: BucketName
parameter_value: {BucketName}
- parameter_key: S3KeyPrefix
parameter_value: {S3KeyPrefix}
deployment_targets:
organizational_units:
- Root
regions:
- ap-northeast-3CloudFormationテンプレート
config.yamlとして定義しているテンプレートです。
グローバルリソースは他リージョンでも取得しているのでfalseにしています。ログの送信頻度はControl Towerと同じ24時間です。
AWSTemplateFormatVersion: "2010-09-09"
Parameters:
BucketName:
Type: String
S3KeyPrefix:
Type: String
Resources:
# Config Recorder
ConfigRecorder:
Type: AWS::Config::ConfigurationRecorder
Properties:
RoleARN: !Sub arn:aws:iam::${AWS::AccountId}:role/aws-controltower-ConfigRecorderRole
RecordingGroup:
AllSupported: true
IncludeGlobalResourceTypes: false
# Config Delivery Channel
ConfigDeliveryChannel:
Type: AWS::Config::DeliveryChannel
Properties:
S3BucketName: !Ref BucketName
S3KeyPrefix: !Ref S3KeyPrefix
ConfigSnapshotDeliveryProperties:
DeliveryFrequency: "TwentyFour_Hours"CodeCommitへPushする
マニフェストファイルとテンプレートが用意できたらCodeCommitのリポジトリにプッシュします。特にファイルに不備がなければパイプラインが成功するはずです。
マニフェストファイルの定義に不備があればBuildフェーズ、StackSetsの展開で失敗すればCloudformationResourceフェーズで失敗します。)
パイプラインが成功したことを確認したら、対象のアカウントにConfigが展開されているか確認します。
確認
メンバーアカウントのConfig有効化
メンバーアカウントでConfigが有効化されていることを確認します。
大阪リージョンでConfigを開くと、記録がオンになっており、送信先のバケットも問題なく指定されています。(他のリージョンとコンソールの表示が少し違います)
ログアーカイブアカウントの出力先
出力先に指定したControl Tower作成のS3バケットを確認します。
こちらも問題なく大阪リージョンのフォルダが作成され、スナップショットが格納されていました。
その他
新規のOU、アカウントが追加されたとき
CfCTのマニフェストファイルで定義されたOU・アカウントが展開の対象となります。そのため全アカウントに展開したい場合はRootを指定しておけば、アカウント追加された際に自動で設定されます。OUを指定して運用する際は、マニフェストファイルのdeployment_targetsにOUを追加してCodeCommitにプッシュしてください。
Control Towerが対応して削除したくなったとき
Control Towerが対応して本設定を削除したくなった場合は、展開したStackSetsを削除します。
※現時点(2022/01/29)ではCfCTによるStackSetsの削除は未対応のため、マニフェストファイルからセクションごと削除しても削除されません。
Control Towerの管理アカウントからCloudFormationコンソール→StackSetsを開いて、展開したStackSetsを選択します。StackSets名はCustomControlTower-xxxxxxxxxの形式になっており、マニフェストファイル上でつけたnameがついています。(今回の例ではadd-config-oosaka-region)
[アクション] → [StackSet からスタック削除] を選択します。
展開されているアカウントをカンマ区切りで指定します(組織単位の指定でも可)。 取り消したいリージョンを指定してください。
これでスタックの削除ができたので、最後にStackSetsを削除します。
[アクション] → [StackSet の削除] を選択します。
スタックが残っていなければ、問題なく削除できるはずです。
まとめ
Control Tower未対応の大阪リージョンにConfigの有効化を行ってみました。Control Towerの必須ガードレールによってConfigの有効化はAWSControlTowerExecution以外からは設定できないようになっています。しかしCfCTではStackSetsの展開をAWSControlTowerExecutionのロールから実行しているため、本制限に引っかからず自動で有効化ができるというメリットがあります。
大阪リージョンがいつControl Towerに対応するかわかりませんが、とりあえず有効化しておきたい場合はCfCTから設定してみてはいかがでしょうか。
34
