なんでこんなことをやったのか
筆者が所属している会社には、AWSのいろいろなサービスを試行するためのプレイグラウンド的なアカウントがあり、筆者もそのアカウントに参加させてもらっています。
あるとき、CloudFormation Template で Webアプリサーバーを立ち上げ、それをHTTPS化して Cognito と連携させてみる、という作業をやっていました。まずは AWS Certificate Manager (ACM) を使って、HTTPS化に必要なSSL証明書を発行しようとしたのですが、その証明書が正しくドメインにひも付いていることを証明するために、DNS に証明書のIDを示す CNAME レコードを登録する必要があることが分かりました。
使用したドメイン自体は、これも試行作業用に作ったドメインなのですが、その管理は別アカウントの Route 53 で行われています。そこで、この試行作業用ドメインのDNS管理もプレイグラウンドアカウントで行えないかな、と考えたのがきっかけです。
権限移譲手順
手順としては下記となります。
-
対象ドメインを Route 53 のホストゾーンとして管理しているアカウントで、そのドメインの編集権限を別アカウントに移譲するようなポリシーを作成する
-
続いて、上記ポリシーを移譲先アカウントに適用するロールを作成する
-
移譲先のアカウントは、コンソールにログインした後、上記ロールに切り替える
以上です。
もう少し説明します
実際にやってみたら、いろいろと調べることが出てきましたが、手順を整理すると「以上」になります。以下、行間を埋めていきましょう。
移譲対象となるホストゾーンを元々管理しているアカウントを Account-A、移譲先のアカウントを Account-B で表すことにします。
1. 移譲ポリシーの作成
移譲用のロールにアタッチされるポリシーです。Account-A で作業します。
IAM コンソールの「ポリシー」の画面で「ポリシーの作成」をクリックします。
「ポリシーの作成」画面で「JSON」をクリックします。
ここに下記のJSONをコピペします。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:GetHostedZoneCount",
"route53:ListHostedZonesByName"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"route53:*",
"route53domains:*"
],
"Resource": "arn:aws:route53:::hostedzone/<HOSTZONE_ID>"
}
]
}下図のような感じになります。
Statement が2つあります。
赤で囲んだほうは、Account-A が管理しているホストゾーンの一覧を別アカウントでも表示できるようにするためのものです。
青で囲んだほうは、<HOSTZONE_ID> で指定されたホストゾーンに対して "route53:" で始まるすべてのアクションと "route53domain:" で始まるすべてのアクションを許可するものとなります。<HOSTZONE_ID> には実際に権限を移譲するホストゾーンのIDを入れてください。
これで、別アカウントからはホストゾーンの一覧が見えますが、実際に選択できるのは、上で指定したホストゾーンだけとなるわけです。
ホストゾーンのIDは、「Route 53」>「ホストゾーン」画面の「ホストゾーンID」からコピペできます。
<HOSTZONE_ID>は、本当は<HOSTEDZONE_ID>にすべきだったのですが、もうスクショも撮っちゃったし、このまま行くことにします
JSONの編集が終わったら、「次へ」をクリックして、次の画面で「ポリシー名」を入力して「ポリシーの作成」をクリックします。
2. ロールの作成
Account-B に対して、前項で作成したポリシーを付与するためのロールを作成します。Account-A で作業します。
IAM コンソールの「ロール」の画面で「ロールの作成」をクリックします。
「信頼されたエンティティを選択」の画面で、「AWSアカウント」、「別のアカウント」を選択し、「アカウントID」に Account-B （つまり移譲先のアカウント）のID(12桁の数字)を入力します。
「次へ」をクリックします。「許可を追加」の画面で、前項で作成したポリシーを選択します。
「次へ」をクリックします。「名前、確認、および作成」の画面でロール名を入力します。
青で囲んだところの "AWS" : に移譲先の Account-B のIDが入っていることを確認してください。"Action": "sts:AssumeRole" がロールの移譲を許可するアクションのようですね。
最後に「ロールの作成」をクリックして完了です。
3. Account-B でロールの切り替え
さて、いよいよ Account-B でログインし、ロールの切り替えを行うわけですが、もし Account-B がルートアカウントである場合は、適当な IAM ユーザーを作成して、そのユーザーでログインしてください。Account-B が Identity Center で作成されたアカウントの場合は、そのままログインしてください。
コンソールの右上にログインユーザー名が表示されています。これをクリックし、さらに「ロールの切り替え」をクリックすると下図のような「ロールの切り替え」画面になります。
ここで Account-A のアカウントIDと、先ほど作成したロール名を指定して「ロールの切り替え」を実行します。もし、ロールの切り替えに失敗するようでしたら、アカウントIDが Account-A のもので間違いないか、また、ロール名に間違いがないかを確認してください。
ロールが切り替わったら、「Route 53」>「ホストゾーン」画面を表示させてみます。Account-A が管理している全ホストゾーンが表示されているはずです。ここから権限移譲を受けたホストゾーンを選択すると、ホストゾーンの編集画面になります。
念のため、「ホストゾーン」一覧画面で他のホストゾーンもクリックしてみてください。この場合は、エラーになって編集画面には切り替わらないはずです。
余話
わかってしまえば簡単なのですが、筆者は AWS を本格的に使用しはじめてからまだ日が浅いので、 今回は、ChatGPTのお世話になりながら（ChatGPTの嘘にも惑わされながら）、かなり試行錯誤を繰り返しました。会話内容に興味のある方は下記URLを参照ください。
https://chat.openai.com/share/f1bdaa11-9650-4fdc-8a01-a8ee844ad87f
まず、「AWS Route 53は、リソースポリシーを直接サポートしていないため、同じようなアクセス許可設定を行うことはできません。」というのが嘘。この回答で一瞬、調べるのを諦めようかと思いましたよw。
さらに突っ込んで聞いた質問への回答で「AWS Organizationsを使用して、アカウントAとアカウントBを同じ組織に追加します。これにより、組織内の他のアカウントとリソースを共有することが可能になります。」というのも、嘘ではないけど、別に同じ組織に属するアカウントでなくてもホストゾーンの権限移譲は可能でした。
致命的だな、と思ったのは「『アカウントB（リソースにアクセスする側）で行う操作』で、アカウントBがアカウントAのRoute 53リソースにアクセスするためのIAMロールを作成する」というところ。ChatGPTに突っ込んだら、間違いを認めてくれましたw。
筆者は Identity Center も試行しながらだったので、なおさら混乱した部分もありました。でも、いろいろと調べてみるヒントにはなったので、何も知らないところから始めるよりは十分に役に立ったといえそうです。
次回は、その Identity Center の使い方を書きたいと考えています。