Help us understand the problem. What is going on with this article?

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

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

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

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

image.png

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

1. Organizationアカウントの作成

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

image.png

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

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

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

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

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

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

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

image.png

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

image.png

作成されたユーザの「アクセス権限の追加」を押し、下記の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ユーザとするため、設定しておきます。

image.png

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

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

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

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

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

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

image.png

{
  "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できるようにしました。
image.png

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

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

image.png

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

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

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

image.png

まとめ

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

T-Tokumori
CBcloud株式会社に一人目のエンジニアとしてジョインして、PickGo作って、今はアーキテクチャ設計や他のプロダクト見てます
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした