株式会社メドレーDeveloper Portal

2024-12-03

トイルの削減も、情報漏洩リスクの削減も、両方手に入れる。IAM Identity Centerは欲張りなんだ。

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。

Who are you?

メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。

最初に簡単にFAQ形式で自己紹介させていただこうと思います。

  • （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。
  • （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。
  • （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。

今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。

セキュリティと管理コストの天秤

メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。

一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。

AssumeRole概要図

AssumeRole概要図

それでもまだ課題はありました。 IAMユーザとAssumeRoleの管理コスト です。

AWSアカウントはサービスごとに複数存在し、さらに本番環境、ステージング環境でも分けてあります。それぞれのAWSアカウントにアクセスできる環境を開発メンバーに提供する必要があります。

AssumeRoleは変身する元と変身した先の設定をする必要があり、AWSアカウントを跨ぐ場合はそれぞれのAWSアカウントに設定が必要になります。開発メンバーの異動がある度にあちらこちらのAWSアカウントにその設定をすることが、面倒なトイルになっていました。

セキュアな環境を維持したまま、管理コストもなるべく下げたい。

そこで導入を決めたのが IAM Identity Center でした。

IAM Identity Centerの導入検討

結論を先に申し上げますと、IAM Identity Centerを導入することで セキュアな環境を維持しながらトイルの削減も実現することができました 。 完璧で究極というほどではありませんが、誰もが目を奪われていく理想の環境に一歩近づくことがました。

IAM Identity Centerをさらに管理するAWS Control Towerの導入も検討しましたが、既にある環境に導入することの予期せぬ制限がかかることのリスクや、AWS Configが多用されることで思わぬコスト増が発生するとの情報もあり、今回は見送ることにしました。

IAM Identity Centerとは

元は AWS Single Sign-On （AWS SSO） というサービス名でした。 これはIAMユーザとは全く別物のユーザ（これをSSOユーザとします）を作成し、SSOユーザが各AWSアカウントの各IAMロールを持ったユーザに変身することができる機能です。

IAM Identity Center概要図

IAM Identity Center概要図

IAM Identity Centerを導入した決め手

SSOユーザと権限の管理は一つのAWSアカウントのIAM Identity Centerで管理することができます。 これはAWS Organizationsの機能の上に乗る機能ですが、幸い元々それを導入していたことで、すぐに組み込むことができました（ちなみに現在はIdPを設定することでAWS Organizationsがなくてもこの機能を使うことができます）。

つまり、 複数のAWSアカウントの複数のユーザの複数のロールを一つのIAM Identity Centerで全て管理することができるのです 。

では、各AWSアカウントで既に作成してしまったIAMポリシーを、IAM Identity Centerで同じ内容で作り直さないといけないかというとそんなこともなく、カスタムロールという設定で、IAMポリシー名だけ定義することで既存のIAMポリシーをそのまま活かすことができます。

そして、SSOユーザは恒久的なアクセスキーを持つことができず、最大で12時間の期限付きアクセスキーしか持つことができません。従って、 仮に万が一アクセスキーが漏洩しても12時間後には使えなくなります 。

まさに最強で無敵のIAM Identity Centerです。

IAM Identity Centerの導入

ここではIAM Identity Centerの導入の流れを簡単に説明いたします。 一番最初はIAM Identity Centerを有効にすることですが、それは割愛して有効化した後の手順を記載していきます。

IAM Identity Center全体図

IAM Identity Center全体図

SSOユーザの作成

SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。

SSOユーザ作成画面

SSOユーザ作成画面

SSOグループの作成

SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。

SSOグループ作成画面

SSOグループ作成画面

許可セットの作成

許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。

プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。

許可セット作成画面

許可セット作成画面

プロビジョニング

"SSOユーザまたはグループ" と "許可セット" を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。

プロビジョニング概要図

プロビジョニング概要図

SSOアクセスポータル画面

SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！

AWSアクセスポータル画面

AWSアクセスポータル画面

一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。

AWSアクセスポータル アクセスキー確認画面

AWSアクセスポータル アクセスキー確認画面

導入後に対応したこと

これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。

~/.aws/configの修正

ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。

[default]
sso_session = my-sso
sso_account_id = 999999999999
sso_role_name = xxxxxxxxxxxx

[sso-session my-sso]
sso_start_url = https://xxxxxxxxxxxx.awsapps.com/start
sso_registration_scopes = sso:account:access

sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。

[tools]
awscli = "latest"

この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。

ターミナルでsso login

ターミナルでsso login

ブラウザで認証

ブラウザで認証

開発環境へのアクセスキーの渡し方

開発環境においてアクセスキーの設定が必要な箇所があり、それを毎日ポータル画面からコピペで更新してくださいというのは面倒すぎるので、毎日1回最初にシェルを実行してもらうようにしました（これも面倒なのでこれなしでどうにかできれば良かったのですが・・・無念）。

この実行にはSSOの認証情報をシェル内の処理で利用するため aws2-wrap を利用し、.envファイルの更新には python-dotenv を利用しました。

これもmiseで定義することで、全開発メンバーにもれなく対応できました。

# 一部抜粋
if ! $(aws2-wrap --profile "$profile" --export); then
    aws sso login --profile="$profile"
    eval "$(aws2-wrap --profile "$profile" --export)"
fi
# 一部抜粋
from dotenv import set_key

def update_env_file(env_file, key_value_pairs):
    try:
        for key in key_value_pairs:
            value = key_value_pairs[key]
            set_key(env_file, key, value, quote_mode='never')
    except Exception as e:
        print(e)

Terraform, Packerの対応

最新のTerraform、Packerではaws ssoに対応しているので、ssoのprofileをそのまま使うことができます（AssumeRoleには対応していなかったので、それを対応させた時は大変でした・・・）。

Terraformは環境依存をなくすため実行環境をコンテナ化しコンテナ内で実行しているのですが、"ログイン時にSSOセッションの存在有無の確認" → "なければSSOログイン" をさせることで、 aws sso login の事前実行を意識しなくても良いようにしました。

# 一部抜粋
function get_caller_identity () {
	set +eu

  for i in {1..3} ; do
    command "aws sts get-caller-identity --profile $1"

    if [[ $? = 0 ]]; then
      break
    else
      echo "Not logged in"
      command "aws sso login --profile $1"
    fi
  done

	set -eu
}

最新のPackerはaws ssoに対応していると前述しましたが、なぜだか環境により sso-session が効かずにエラーになる場合がありました。その場合はレガシーな記述方法で回避できます。

[profile packer]
credential_process = aws --profile default configure export-credentials --format process
region = ap-northeast-1
output = json

対応して良かったこと

管理者目線で良かったこと

管理者目線では、AWSのユーザ管理が大分楽になりました。

これまで開発メンバーが増えた際には、複数のAWSアカウントに対しそれぞれに、IAMユーザの作成、アクセスキーの生成をし、その後初期ログインパスワードとアクセスキーをメンバーに配布しなければならなかったため、作業が大分煩雑でした。

IAM Identity Center導入後は、 1つのAWSアカウントでSSOユーザを作成するだけです 。招待メールも勝手に送られます。

また、与えている権限の管理も楽になりました。

IAM Identity Centerの画面を見れば、誰がどのAWSアカウントにどんな権限を持っているか全てわかりますし、設定するのもそこだけなので 、いろんなAWSアカウントを出入りして確認・設定する必要がなくなりました。

利用者目線で良かったこと

利用者目線では、各AWSアカウントへのログインがポータル画面のリンクから行くことができるので、 AWSアカウントごとにログインの作業が必要なくなったのも楽ですし、各AWSアカウント毎にログイン情報、MFA情報を保持しなくても良くなったのも管理が気楽になりました 。

対応して困ったこと

12時間の壁

SSOユーザのセッション時間の上限が12時間のため、朝9時にログインすると夜9時にセッションが切れてしまいます。そのことを忘れて12時間後に急に開発環境でエラーが出始めて「なんじゃこりゃあああ！」とたまに驚かされます（12時間以上働くことがほとんどないのでめったに遭遇しませんが、だからこそ忘れます）。

深夜メンテの際にそれが起きるとトラブルになりますので、その際は作業前に必ずログインし直すようにしています。

個人的にはセッション時間の上限の時間もう少し上げて欲しいです。

利用できないサードパーティーツールの存在

AWSにアクセスするためのサードパーティーツールは様々ありますが、AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEY の2項目しか設定できないものがあります。

SSOユーザでログインするには、それらに加え AWS_SESSION_TOKEN の値が必要であるため、設定できないツールはSSOユーザでは利用できないことになります。

最近ではSSOユーザでも利用できるようにアップグレードされているツールも増えてきていますので、今まで使っていたツールが使えなくなった場合は代替のツールを使いましょう。

まとめ

これは絶対嘘ではなくて、IAM Identity Centerを導入することで、トイルの削減も、情報漏洩リスクの削減も、両方実現することができました。

もちろん私たちの挑戦はこれで終わりではなく、サービスの品質を上げるため、開発メンバーが開発に集中できる環境を作るため、 俺たちの戦いはまだ始まったばかり 、です。

そして、明日12月4日は @shigerisa さんが何やらもっと面白い記事を書いてくれているようです！お楽しみに！

We're hiring!

メドレーでは各種エンジニアを絶賛募集中です！

カジュアル面談いつでもWelcomeですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！

https://www.medley.jp/jobs/

前の記事
次の記事

株式会社メドレーDeveloper Portal

© 2016 MEDLEY, INC.