Open11

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": "*"
}

https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html#kms-key-policy-update

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アカウントはどこにいったのだろう?

https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/basic-organization.html

構成例に倣ってSecurity OUの配下にProd OUを作成しようかと思ったがControl TowerのUIからは新規OUは作成できるものの、その親の指定をSecurity OUとする方法がわからない。

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を作る構成例が出ている。

日本語訳では以下が分かりやすい。

https://blog.serverworks.co.jp/recommended-ous#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
ログインするとコメントできます