[小ネタ] Control Towerへ登録する際に必要なAWSControlTowerExecutionの作成に失敗した話

こんにちは、AWS事業部の木村です。

はじめに

Control Towerへ既存のアカウントを登録する際には、以下のブログで紹介されているようにいくつか事前に準備が必要です。

その一つの条件としてControl Tower管理下に登録するアカウント内にAdmin権限を持たせたAWSControlTowerExecutionというIAMロールを作成する必要があります。

ふとAWSControlTowerExecutionロールを作成しないで、Control Tower管理下に登録できるかが気になり検証しました。勿論Control Tower管理下への登録に失敗したのですが、その後に登録条件を満たすべくAWSControlTowerExecutionロールを作成しようとしたところAWSControlTowerExecutionと命名したロールの作成ができなくなってしまいました。

ふとAWSControlTowerExecutionを作成しないで、Control Tower管理下に登録できるかが気になり検証される方はあまりいないと思うのですが、AWSControlTowerExecutionの作成を忘れてしまっていた方やControl Towerへ登録するときの条件を把握しておらず登録してしまった方のちょっとした嵌りポイントになりそうかなと感じましたので原因と対応方法を記したいと思います。

いきなり結論

Control Tower管理内のOUにアカウントが配置されていると、Control Towerが生成しているSCPによってAWSControlTowerExecutionロールの作成が制限されてしまうので一旦Control Tower管理外のOUに移動させてAWSControlTowerExecutionロールを作成する必要があります。

2024/3/28追記
アカウントの登録に失敗した状態から、Control Tower管理内のOUを再登録することでもアカウント登録を行うことが確認できました。手順としてはこちらの方が簡潔になります。
OUの再登録を行った際の手順 についても合わせて追記しますのでご確認ください。

AWSControlTowerExecutionを作成しないで、Control Tower管理下にアカウント登録してみる

現在の状態としては以下になります。

Control Tower管理外のOUからControl Tower管理内のOUに移動させてかつアカウントをControl Tower管理下に登録するように操作してみます。

AWSControlTowerExecutionロールが必要という警告が出ますが、そのままアカウントの登録します。

当然ですがアカウントの登録は失敗となります。

この操作後の状態ですが、Control Tower管理下への登録は失敗しますが、以下のようにControl Towerの管理内のOUへの移動は成功していました。

AWSControlTowerExecutionを作成する

登録にはやはりAWSControlTowerExecutionが必要なことが分かりましたので、対象のアカウント内にAWSControlTowerExecutionロールを作成していきます。

コンソールから必要な情報を入力してIAMロールを作成してみましたが以下のように失敗してしまいました。

内容を確認してみるとexplicit deny in a service control policyとなっておりました。

SCP (service control policy)によって明示的に拒否されてしまっているようです。

先ほどControl Tower管理下にアカウント登録した際にControl Tower管理内のOUに移動していたためこのOUに適用されているSCPによって作成が明示的に拒否されるようになっているようです。

Control Towerの管理内OUに設定されているSCPを確認してみると、以下のように定義されておりました。（関連ある部分を抜粋）

{
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalArn": [
        "arn:aws:iam::*:role/AWSControlTowerExecution",
        "arn:aws:iam::*:role/stacksets-exec-*"
      ]
    }
  },
  "Action": [
    "iam:AttachRolePolicy",
    "iam:CreateRole",
    "iam:DeleteRole",
    "iam:DeleteRolePermissionsBoundary",
    "iam:DeleteRolePolicy",
    "iam:DetachRolePolicy",
    "iam:PutRolePermissionsBoundary",
    "iam:PutRolePolicy",
    "iam:UpdateAssumeRolePolicy",
    "iam:UpdateRole",
    "iam:UpdateRoleDescription"
  ],
  "Resource": [
    "arn:aws:iam::*:role/aws-controltower-*",
    "arn:aws:iam::*:role/*AWSControlTower*",
    "arn:aws:iam::*:role/stacksets-exec-*"
  ],
  "Effect": "Deny",
  "Sid": "GRIAMROLEPOLICY"
}

Control Towerの「予防」の一環として、制限がかけられているようです。

Control Towerにコントロールついては以下の記事をご参照ください。

OUを移動する

この状態を解消するためには、一度Control Towerの管理内OUからControl Towerの管理外のOUに移動させる必要があります。

Control Towerから対象のアカウント管理の解除を行います。

解除完了するとRootアカウントの配下に移動します。

再度AWSControlTowerExecutionを作成する

再度手動でIAMロールを作成します。

CloudFormationで作成する方法は以下のブログがわかりやすかったので参考にしてください。

ロールの信頼ポリシーとして以下を入力します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<管理アカウントID>:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

許可ポリシーは「AdministratorAccess」を追加します。

ロール名は「AWSControlTowerExecution」を指定します。

ロールを作成を選択すると今度は無事作成することができました。

再度Control Tower管理下にアカウント登録してみる

では今度こそControl Tower管理下にアカウント登録してみたいと思います。

先ほどと同様にAWSControlTowerExecutionロールが必要という警告が出ますが、今度は作成しているのでそのまま登録を行います。

画面遷移直後はエラーが表示されておりましたが、時間が経過すると登録中になり最終的にControl Tower管理下にアカウント登録することができました。

OUの再登録の実施(2024/3/28追記)

こちらの手順はOU内に存在する登録済みアカウントに影響を与える可能性がありますので、「リスクと想定」の内容を確認した上で実施してください。

AWSControlTowerExecutionを作成しないで、Control Tower管理下にアカウント登録してみる 章での操作が終わった段階から検証を行います。環境の状態としては以下の状態です。

Control Tower管理内のOUを選択して、OUの再登録を実施してみます。

リスクと想定の内容を確認します。今回は検証用のアカウントで既に登録済みのアカウントがありませんので同意にチェックを入れて再登録を実施します。

OU再登録中の様子

2,30分ほど待つと再登録が完了していました。

登録を行ったアカウントを確認してみると、AWSControlTowerExecutionロールも自動で作成されておりました。

OU再登録の一連の流れでCloudFormationが実行されており、AWSControlTowerExecutionロールが作成されておりました。

こちらのCloud Formation実行はstacksets-exec-*というロールで実行されているので、SCPの制限にもかからずにIAMロールを作成できるようです。

SCP一部再掲

"Condition": {
  "ArnNotLike": {
    "aws:PrincipalArn": [
      "arn:aws:iam::*:role/AWSControlTowerExecution",
      "arn:aws:iam::*:role/stacksets-exec-*"
    ]
  }
}

stacksets-exec-*ロールの詳細については以下をご参照ください。

解消方法について2種類試してみましたが「リスクと想定」の内容を確認して問題ないようであれば、こちらの方が手間もかからず早くて簡単にすみそうです。

ご自身の環境ごとにどちらの手順で進めるかご確認いただければと思います。

まとめ

検証環境だったのでふと気になって試してみたのですが、巻き戻すのにそこそこの時間がかかってしまいました。

このブログによって同じ状況に陥った方の作業時間を少しでも減らせると幸いです。

以上AWS事業部の木村でした。