エンジニア組織を作るのは難しいけど、AWS上の組織構築は完全に理解した【AWS Organizations】

最近色々悩みに悩んでいるCBcloud 徳盛です。

これまで一人で突っ走っている時にはAWSのインフラを全て一つのアカウントで管理していました。が、エンジニア組織が分割されていくにつれ、どのサービスでどれだけAWSが利用されているのかを特定するのが難しくなってしまったりと、リソース管理の煩雑化が目に見えてきたため、AWSのOrganizationsを利用して整えていこうとしています。
最近ジョインしていただいたAWSの運用にとても詳しい禿にワークショップ形式で教えていただいているので、今回はその内容をメモがてら書いていこうと思います。

今回のアカウント設計の全体像

Organizationsを管理するルートアカウントの操作手順 【ルートアカウント】

1. Organizationアカウントの作成

1.1. Organizationsの画面から「アカウントの追加」を押します。

1.2. 必要な情報を入力して、作成を押します。

フルネーム: [サービス名]-prodや[サービス名]-dev
Eメール: インフラを管理する専用のアドレスにしました。(フルネームをエイリアスに利用)
IAMロール名: 全てのOrganizationアカウントで統一したものにしました。

ちなみに、ここで設定したロール名は作成されたアカウント内でロールが自動生成され、Admin権限が付与されます。

ユーザを管理する側のOrganizationアカウントの操作手順 【IAMユーザ管理アカウント】

全体像では、アカウントを管理するOrganizationアカウントを作成して、そこでIAMユーザを管理していますが、弊社ではまだルートアカウントでIAMユーザを管理しているため、「IAMユーザ管理アカウント = ルートアカウント」となっております。
今後、ユーザ管理のCFnを整備できたら移行する予定です。

2.　OrganizationのAdminロールにassumeするためのIAMユーザを作成

2.1. まずIAMユーザを作成します

2.2. 作成したOrganizationのAdmin権限ロールをassumeするための権限を付与します

作成されたユーザの「アクセス権限の追加」を押し、下記のjsonを適用してください。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::{1.2で作成したOrganizationのアカウントID}:role/{1.2で作成したOrganizationのAdmin権限ロール名}"
            ]
        }
    ]
}

2.3. セキュリティ上、AサービスのAdmin権限ロールをassumeできる条件として、two-factor認証設定済みIAMユーザとするため、設定しておきます。

assumeされる側のOrganizationアカウントの操作手順 【Aサービス-prodアカウント】

3. Aサービスのルートアカウントでログイン

3.1. パスワードのリセット

Aサービスで利用するためのOrganizationアカウントのメールアドレス【1.2で作ったもの】を利用してルートアカウントにログインするためには、パスワードのリセットを行う必要があります。
通常のログインページより行ってください。設定を登録アドレス宛にメールがリセットメールが届きます。

4. 1.2で自動生成されているAdmin権限ロールに対してassumeできる条件を設定

4.1. 2.1で作成したIAMユーザのみがAdmin権限ロールにassumeできるように、ロールに変更を追加します

{
  "Version": "2012-10-17",
  "Statement": [
    {
      --省略---
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringLike": {
          "aws:username": "{assumeを許可するIAMユーザ名}"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": "社内のGlobalIPとか"
        }
      }
    }
  ]
}

今回はassumeできる条件として、こちらで作成したIAMユーザかつ、two-factor認証を設定している、かつ社内からのアクセスだった場合にのみassumeできるようにしました。

assumeできる環境が整ったので、試してみる

アカウントメニューよりスイッチロールを選択

以下を入力して、ロールの切り替えを行えばOK。

アカウント: 1.で作成したOrganizationアカウントのID
ロール: 1.で作成したOrganizationアカウントのadmin権限ロール名

新規で作成したOrganizationアカウントにassumeRoleに成功すると当然リソースは何もなく綺麗な状態です。

まとめ

時間の関係上ワークショップが途中で終わってしまったため、今回の記事はまだ途中です。
この後、作成したOrganizationアカウントに、メンバーがassumeできるロールを作成し、admin権限を持つロールをassumeできるアカウントを封印する作業や、そもそもこれまでの作業をCFnで管理するというが残っています。
作業完了次第続きをアップできればと思います〜。