IAM Identity Center に追加リージョン（セカンダリ）を作ってみた（KMSキーの作成から大阪リージョンの追加まで）
こんにちは。
ここがわたしのセカンダリリージョン
運用イノベーション部のかわいです。
先日、IAM Identity Center（以下 IIC）の追加リージョンを作成しました。
当初は IIC を実際に設定したことがなかったため、リージョン追加方法のイメージがまったく沸いておらず、ドキュメント漁りに奔走しました。
社内有識者やドキュメントを参考にセカンダリリージョンが無事追加できたので、本記事に備忘録として残します。
この記事でわかること
- 追加リージョンを作ると何がうれしいのか
- プライマリリージョンと追加リージョンで、それぞれ何ができるのか
- リージョン追加までの基本的な手順
- 実際に触ってみて分かった挙動
- マネジメントコンソールで作った IIC用の KMS キーを Terraform 管理する方法
※なお、本記事では IIC 上のユーザを使用するため、外部IdP の話には触れていません（以下を参照されたし）。
IICの追加リージョンとは
IIC は組織インスタンス（※IICまるごと1セットのこと。いわゆる"ガワ"）を有効化する際に、リージョンを1つ選びます。これがプライマリリージョンになります。追加リージョンを作ると、ユーザやグループ、許可セット、各種割り当て、セッションなどの情報がプライマリから追加リージョンへ自動でレプリケートされます。
追加リージョンを作るメリット
公式ドキュメントでは、以下の 2点がメリットとして挙げられています。
- プライマリリージョンで障害が起きても、AWS アカウントにアクセスできる
- AWS マネージドアプリケーションを、好きなリージョンにデプロイしやすくなる
特に1点目がユースケースとして考えられ、プライマリリージョン障害時などの迂回路としての活用が期待できます。
プライマリと追加リージョンでできること/できないこと
| 操作 | プライマリ | 追加リージョン |
|---|---|---|
| アクセスポータルへのサインイン | できる | できる |
| 割り当て済みアカウント・アプリケーションの表示と利用 | できる | できる |
| ユーザ・グループの閲覧 | できる | できる |
| ユーザーのセッション取り消し | できる | できる |
| パスワードリセット・MFA デバイスの管理（※ポータル経由。Identity Center ディレクトリの場合） | できる | できる |
| ユーザ・グループの作成・更新・削除 | できる | できない（読み取りのみ） |
| 許可セットと割り当ての管理 | できる | できない |
| リージョンの管理、KMSキーの管理などの機能 | できる | できない（一部読み取りのみ） |
マネージドアプリケーションの対応表は以下ページを参照されたし
KMSキーと IIC の関係
ここが一番の留意事項なんですが、
追加リージョンを作るには、IIC 保存データの暗号化にカスタマーマネージドのマルチリージョンキーを使う必要があります。デフォルトの AWSマネージドキーのままだと追加リージョンは使用できません。
今回は東京リージョンがプライマリ、セカンダリに大阪リージョンを使用しました。
KMSキーはマルチリージョンレプリケートが必要となり、大阪リージョンに複製することで、はじめてIICセカンダリリージョンとして追加が可能になります（後述）。
実際にやってみる
全体の流れです。手順自体はすごくシンプル
- KMS でマルチリージョンキーを作る（東京）
- キーのレプリカを作る（大阪）
- IIC の暗号化キーを、作ったキーに切り替える
- IIC に大阪リージョンを追加する
前提条件
開始前に、公式ドキュメントの前提条件を確認しておきます。
- IIC が組織インスタンスであること（アカウントインスタンスは非対応）
- ID ソースが Identity Center ディレクトリか外部 IdP であること（Active Directory は非対応）
- KMS キーが IIC と同じ AWS アカウントにあること
- 使っている AWS マネージドアプリケーションが、すべてカスタマーマネージドキーに対応していること
- プライマリと追加リージョンの両方が、マルチリージョン対応のリージョンであること
検証環境
| 項目 | 内容 |
|---|---|
| IICインスタンス | 組織インスタンス（既存） |
| IDソース | Identity Center ディレクトリ |
| プライマリリージョン | 東京（ap-northeast-1） |
| 追加リージョン | 大阪（ap-northeast-3） |
| 操作環境 | マネジメントコンソール（管理アカウント） |
1.KMS からマルチリージョンキーを作る
プライマリの東京リージョンから KMS 画面に遷移し、【キーの作成】を開きます。
- キーのタイプ：対称
- キーの使用法：暗号化および復号化
- 詳細オプション；「マルチリージョンキー」を選ぶ
任意のエイリアスを入力し、キー管理者とキーユーザーの選択に進みます。
今回はキーポリシーを直接編集するので、何も選択せず次へ進みます。
キーポリシーの編集画面で、IIC が使うためのポリシーを入れます。ポリシーの中身は公式ドキュメントのベースラインポリシーを元にしました。
今回は 111122223333 が IIC のある管理アカウント、444455556666 が委任管理者のアカウント。
委任管理者を使っていなければ、444455556666 の行は不要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowIdentityCenterAdminAccounts",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root",
"arn:aws:iam::444455556666:root"
]
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "AllowIdentityCenterAndIdentityStoreToDescribeKey",
"Effect": "Allow",
"Principal": {
"Service": [
"identitystore.amazonaws.com",
"sso.amazonaws.com"
]
},
"Action": "kms:DescribeKey",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "${aws:ResourceAccount}"
}
}
},
{
"Sid": "AllowIdentityCenterAndIdentityStoreToUseKey",
"Effect": "Allow",
"Principal": {
"Service": [
"identitystore.amazonaws.com",
"sso.amazonaws.com"
]
},
"Action": [
"kms:Decrypt",
"kms:ReEncryptTo",
"kms:ReEncryptFrom",
"kms:GenerateDataKeyWithoutPlaintext"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "${aws:ResourceAccount}"
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": [
"aws:sso:instance-arn",
"aws:identitystore:identitystore-arn"
]
}
}
},
{
"Sid": "AllowOrgPrincipalsViaIdentityCenterAndIdentityStore",
"Effect": "Allow",
"Principal": "*",
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "${aws:ResourceOrgID}"
},
"StringLike": {
"kms:ViaService": [
"sso.*.amazonaws.com",
"identitystore.*.amazonaws.com"
]
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": [
"aws:sso:instance-arn",
"aws:identitystore:identitystore-arn"
]
}
}
},
{
"Sid": "AllowManagedApps",
"Effect": "Allow",
"Principal": "*",
"Action": "kms:Decrypt",
"Resource": "*",
"Condition": {
"Bool": {
"aws:PrincipalIsAWSService": "true"
},
"StringEquals": {
"aws:SourceOrgID": "${aws:ResourceOrgID}"
},
"StringLike": {
"kms:ViaService": [
"identitystore.*.amazonaws.com",
"sso.*.amazonaws.com"
]
},
"ForAnyValue:StringEquals": {
"kms:EncryptionContextKeys": [
"aws:sso:instance-arn",
"aws:identitystore:identitystore-arn"
]
}
}
}
]
}
ポリシーが記載できたら次へ進み、内容の確認後、キー作成を行います。
その後キーの詳細画面から、「これはマルチリージョンのプライマリキーです」の記載が確認できればok
2.セカンダリリージョン（大阪）にレプリカキーを作る
キーの詳細画面の「リージョンごと」タブから「新しいレプリカキーを作成」を開きます。
リージョン一覧から、アジアパシフィック（大阪）を選びます。
キーポリシーはプライマリの内容がコピーされた状態で表示されます。
確認画面には、「キーポリシーはリージョン間で同期されない」といった旨の確認チェックがあります。
ここで覚えておきたい点として、レプリカを作った後にプライマリのキーポリシーを変更したとしても、レプリカには反映されません。そのため、キーポリシーを修正する際は、両方のリージョンで編集する必要があります。
作成直後は「作成中」ステータスとなり、少し待つと有効になります。
3. IIC の暗号化キーを切り替える
IIC コンソール（東京側）の「設定」から「暗号化を管理」を開き、「別の AWS KMS キーを選択する（詳細）」を選びます。手順1で作ったキーの ARN を入れて保存します。
利用中のユーザ影響については、公式ドキュメント上に、キーの切り替え時は「サインイン済みユーザのセッションには影響しない」、「切り替えの間も、アクセスポータル、IIC コンソール、IIC の API を使い続けられる」と明記されています。
4. 大阪リージョン（セカンダリ）を追加する
IIC 設定メニュー上、プライマリのみの場合は以下のような表示になっています。
KMSキーの複製後に【リージョンを追加】から追加リージョンメニューに遷移します。
ここから大阪リージョンを選択し追加します。
（※事前にマルチリージョン対応のKMSキーを作成していないと、リージョン選択ができない）
ダッシュボード上で追加中ステータスになるので少し待ちます。
だいたい3分程度でしょうか、少し待つとアクティブ状態となり、セカンダリリージョン用の接続先URL（デュアルスタック/IPv4専用）がそれぞれ発行されました。
追加後、大阪側のポータル画面から各アカウントへのアクセスが可能になりました。
（おまけ）コンソールで作ったKMSキーを Terraform 管理化
IIC 全体の Terraform 化は未サポートの部分もあるため実施しませんが、暗号化に用いたKMSキーを今回コード化しようと思います。
注意する点
キーポリシーと権限について
カスタマーマネージドキーに切り替えると、IIC の情報を読むときにも KMS の権限が絡んできます。
例えば、ReadOnly 系の権限で IIC を見ていたユーザーが、キーを切り替えた後に kms:Decrypt の権限不足で見られなくなることがあります。このあたりの権限設計は、yhanaさんの記事で詳しく検証されているので、ぜひ参考にしてみてください。
また、キーポリシーのベースラインは公式ドキュメントにまとまっています。
キーを消すと IIC 全体が使えなくなる
今回切り替えたKMSキーを無効化したり削除したりすると、IIC 全体が使えなくなります。
キーポリシーの変更やキーの削除は致命傷となるため、削除防止策として prevent_destroyを追加します。
キーポリシーはリージョン間で同期されない
手順2でも触れましたが、プライマリキーとレプリカキーのポリシーは別物になるため、両方を編集する必要があります。
検証環境（Terraform）
| 項目 | 内容 |
|---|---|
| Terraform | 1.16.4 |
| AWS Provider | hashicorp/aws 6.66.0 |
| provider のデフォルトリージョン | 東京（ap-northeast-1） |
コード
キーポリシーは、手順1で使用した JSON をそのまま kms_key_policy.json として置き、プライマリとレプリカの両方から読み込みます。ポリシーはリージョン間で同期されないので、1つのファイルを両方に当てておけば、片方だけ直し忘れることがなくなります。
locals {
iic_kms_key_policy = file("${path.module}/kms_key_policy.json")
}
# プライマリ（東京）
"aws_kms_key"">resource "aws_kms_key" "iic" {
description = "iic kms key for multi regions"
multi_region = true
policy = local.iic_kms_key_policy
lifecycle {
prevent_destroy = true
}
}
"aws_kms_alias"">resource "aws_kms_alias" "iic" {
name = "alias/iic-kms-key"
target_key_id = aws_kms_key.iic.key_id
}
# レプリカ（大阪）
"aws_kms_replica_key"">resource "aws_kms_replica_key" "iic_osaka" {
region = "ap-northeast-3"
primary_key_arn = aws_kms_key.iic.arn
description = "iic kms key for multi regions"
policy = local.iic_kms_key_policy
lifecycle {
prevent_destroy = true
}
}
# エイリアスはリージョンごとのリソースのため、大阪側にも作る
"aws_kms_alias"">resource "aws_kms_alias" "iic_osaka" {
region = "ap-northeast-3"
name = "alias/iic-kms-key"
target_key_id = aws_kms_replica_key.iic_osaka.key_id
}
import {
to = aws_kms_key.iic
id = "mrk-1234abcd12ab34cd56ef1234567890ab"
}
import {
to = aws_kms_alias.iic
id = "alias/iic-kms-key"
}
import {
to = aws_kms_replica_key.iic_osaka
id = "mrk-1234abcd12ab34cd56ef1234567890ab@ap-northeast-3"
}
import {
to = aws_kms_alias.iic_osaka
id = "alias/iic-kms-key@ap-northeast-3"
}
ポイントとしては以下の3つ。
-
region引数
AWS Provider 6.x からはリソースごとにリージョンを指定できるので、大阪用に provider の alias を別で用意しなくても、1ファイルに東京と大阪のリソースを並べられます。 -
import ID の末尾の @ap-northeast-3
マルチリージョンキーはプライマリとレプリカでキーID が同じ（mrk- から始まる）なので、何も付けないとデフォルトリージョン（東京）のキーを探しにいってしまいます。別リージョンのリソースを import する際は@<リージョン>を付ける、と provider のガイドに記載されています。エイリアスも名前が東京と同じなので、同じく@ap-northeast-3を付与します。
- prevent_destroy
このキーが消えると IIC 全体が使えなくなるため、予防策として2つのキーに対し付与します。
まとめ的な
今回、IIC に大阪リージョンを追加リージョンとして作成してみました。
手順自体はすごくシンプルで、KMS のマルチリージョンキーを作成 → セカンダリにレプリカを作成 → IICのキー切り替え → リージョン追加 のみなので、思ったより導入は難しくなかったです。
また、事前にキーのレプリカが作成されてないと追加先できない点や、キーポリシーがリージョン間で同期されない点には注意が必要です。
追加リージョンは、IICのプライマリリージョンが使用できなくなった際の迂回路となるため、KMSキーの管理コストを勘案しても、導入しておくメリットはあるかと考えます。
本記事が、セカンダリリージョンの利用を検討している方の役に立てばと思います。
完
参考
