AWS Control Tower
初期セットアップ時にCustmer managedのKMS keyを使用するかどうか設定できる。
Control Towerに関連するS3や、Config、CloudTrailの暗号化に使用される。
KMS keyの作成画面ではKey policyに以下のstatementを追加すること。
{
"Sid": "Allow CloudTrail and AWS Config to encrypt/decrypt logs",
"Effect": "Allow",
"Principal": {
"Service": [
"cloudtrail.amazonaws.com",
"config.amazonaws.com"
]
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}
OUをどうするか考える。
Control TowerのデフォルトではRoot, Security, Sandboxが作られる。また、Securiy OU直下にLog ArchiveアカウントとAuditアカウントが作られる。
Organizing Your AWS Environment Using Multiple Accounts
の構成例を見ると、Security OUの配下にProd OUを置き、その更に下にlog-archive-prodアカウントとsecurity-tooling-prodアカウントを置いている。Auditアカウントはどこにいったのだろう?
構成例に倣ってSecurity OUの配下にProd OUを作成しようかと思ったがControl TowerのUIからは新規OUは作成できるものの、その親の指定をSecurity OUとする方法がわからない。
Control TowerデフォルトのAuditアカウントは、下記構成で言うところのsecurity-read-only-prodアカウントに該当するのかもしれない。
Workloads OUおよびその子にProd OUを作成した。
このProd OUに、Control Tower以前から存在するAWSアカウントを移動させた。操作はControl TowerではなくOrganizationsで行う。
移動は問題なくできたが、Control Tower側では以下のように表示されてしまう。
このアカウントは AWS Control Tower に登録されている組織単位 (OU) に属していますが、アカウントはその OU に登録されていません。 AWS Control Tower では、OU ページで [OU を再登録] を選択してこのアカウントを登録することをお勧めします。
OUに属しているがOUに登録されていません、とは😵
ちなみに、Whitepaperの構成例の通りに、Workloads OUの子にProd OU、と言う風に作ると、例えばDeployments OUの子に作ったProd OUと見分けづらい。
図であればスッキリして見やすいが、Control TowerのUIで見ると混同してミスオペしそう。
子側もWorkloadsProd OUとかDeploymentsProd OUとかにした方が良い。
幸いOUの名前はOriganizationsの画面から簡単に変えられる。
OUに属しているがOUに登録されていません
これに関しては、Control TowerのUIで、OUを(今回であればWorkloadsProd OU)を選んで、アクション > OUを再登録 で解消できそう。
再登録前に2hかかると表示されたが、実際再登録を開始すると後1h弱と表示された。
あと、再登録を開始するとその間はControl Towerのコンソールが操作できない、といった旨の表示がされた気がするけど、そんなことないな。操作できる。
WhitepaperではWorkloads OUとは別にDeployments OUを作る構成例が出ている。
日本語訳では以下が分かりやすい。
自分はTerraformのCDにAtlantisを使用しているけど、ちょうどAtlantisサーバーはprod、devといった複数のアカウントに対してterraform applyさせているので、AtlantisサーバーはDeployments OU配下のアカウントに配置するのが良いのではと思った。
これもわかりやすい
OUもTerraform管理できる。例えば、for_each
とか使わずにベタに書くとしたら以下のような感じ。
data "aws_organizations_organization" "this" {}
resource "aws_organizations_organizational_unit" "workloads" {
name = "Workloads"
parent_id = data.aws_organizations_organization.this.roots[0].id
}
resource "aws_organizations_organizational_unit" "workloads_prod" {
name = "Workloads-Prod"
parent_id = aws_organizations_organizational_unit.workloads.id
}
resource "aws_organizations_organizational_unit" "workloads_test" {
name = "Workloads-Test"
parent_id = aws_organizations_organizational_unit.workloads.id
}
既存アカウントをAWS Organizationで何らかのOUに属させる。
その後、AWS Control Towerで上記OUに対して「再登録」の操作を行うと、OUに属するAWSアカウントでAWS Configが自動で有効になる。
AWS Control Tower配下になったアカウントでは、CloudFormationが走って、以下のリソースが作成される。
物理ID | Type |
---|---|
AWSControlTowerExecution | AWS::IAM::Role |
aws-controltower-ConfigRecorderRole | AWS::IAM::Role |
aws-controltower-ForwardSnsNotificationRole | AWS::IAM::Role |
aws-controltower-AdministratorExecutionRole | AWS::IAM::Role |
aws-controltower-ReadOnlyExecutionRole | AWS::IAM::Role |
aws-controltower-BaselineConfigDeliveryChannel | aws-controltower-BaselineConfigDeliveryChannel |
aws-controltower-BaselineConfigRecorder | AWS::Config::ConfigurationRecorder |
arn:aws:config:{region}:{account_id}:aggregation-authorization/{Auditアカウントのaccount_id}/{Auditアカウントのregion} | AWS::Config::AggregationAuthorization |
aws-controltower-ConfigComplianceChangeEventRule | AWS::Events::Rule |
/aws/lambda/aws-controltower-NotificationForwarder | AWS::Logs::LogGroup |
arn:aws:sns:{region}:{account_id}:aws-controltower-SecurityNotifications | AWS::SNS::Topic |
略 | AWS::Lambda::Permission |
略 | AWS::SNS::TopicPolicy |
略 | AWS::SNS::Subscription |
aws-controltower-BaselineCloudTrail | AWS::CloudTrail::Trail |
aws-controltower/CloudTrailLogs | AWS::Logs::LogGroup |
aws-controltower-CloudWatchLogsRole | AWS::IAM::Role |