こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田( @Shige0096 )です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上 KS ビルにて開催された「 JSConf JP 2024 」にプレミアムスポンサーとして協賛させていただきました。 JSConf JP は一般社団法人 Japan Node.js Association によって企画・運営されている JavaScript に関する“⁠ お祭り ⁠”です。日本と海外の Web 開発者を繋げる目的で企画されています。2020 年から開催され、今年で 5 回目。今年もフロントエンドエンジニア・採用人事・技術広報担当を中心に多くの参加者が訪れました。 会場の様子 会場は九段坂上 KS ビル。今年はオンライン・オフラインのハイブリッド開催でした。現地チケットは売り切れてしまったので、オンライン配信があるのは嬉しいですね。 当日は 4 つのトラックに分かれ、時間帯によっては 4 セッションが同時並行していました。 セッション数が多くとても充実したイベントになりました。 会場入り口 メドレーブースの様子 メドレーブースでは「医療体験あるある」をパネルを用いてアンケート調査しました。 エンジニアをはじめ多くの方にお越しいただきました！お越しいただいた皆様ありがとうございました ✨ 特に多かった「医療体験あるある」は以下 2 つ。 ① キャッシュレス決済がしたい ⇨ キャッシュレス対応が進んできたがまだまだ現金対応の病院が多い ⇨ 現金を引き落としに一度コンビニに行くことがあった ② 待ち時間が長い（ほぼ同率 １ 位） ⇨ 予約したはずなのに待ち時間が発生している ⇨ いつも混んでいるので病院に行くのが疲れる 実際に CLINICS アプリ の画面をご覧いただきながら以下のようなお話をしました。オンライン診療を受けたのち、ご要望に合わせて薬を Uber で配達することも可能であることや、何よりキャッシュレス決済もスムーズにできてとても良い！などのお声をいただきました。 多くの方にお越しいただきました 🙌 自身が開発しているプロダクトに込める思いは人一倍 👀✨ メドレー登壇 当社の髙橋(医療プラットフォーム本部)と德永(人材プラットフォーム)が登壇しました。 高橋のセッションの様子 次々に参加者が増えていき、最終的には 50 名近くの方にご覧いただきました 🙌 オンライン配信を含め、ご視聴いただいた皆様、ありがとうございました！ 登壇した髙橋より一言 セッションや登壇資料をご覧頂いた皆様、ありがとうございました！当日のブースや懇親会、また X やブログを通じて、皆様から多くのご感想を頂き感謝の気持ちでいっぱいです。発表で詳しく取り上げられなかった内容に関する Q&A を以下に公開します。 コンポーネントの分割粒度をチーム全体でどのように統一していますか？ 発表内で紹介した{関心事}{状況}{ベースコンポーネント名}の命名規則を守ることで Button や Dialog の単位で自然とコンポーネントが分割されるようなメンタルモデルを築いています。加えて Plop を使ってテンプレートコードを生成することで実装がブレないようにしています。 状態管理ライブラリはどのように使い分けていますか？ 非同期状態管理は Tanstack Query 、フォーム状態管理は React Hook Form 、その他の UI に関する状態は React.useState のように使い分けています。複合コンポーネント間で親子関係がある場合は React.createContext を使って依存関係を表現することがあります。このとき、子コンポーネントの Storybook の decorator に Context Provider を設定することで、複合コンポーネント間の連携を含めた Story とそのテストを実装しています。 Redux はサーバキャッシュとして運用していましたが、現在は Tanstack Query への移行を進めているため積極的な利用は避けています。 👇 登壇資料はこちら 德永のセッションの様子 登壇した徳永より一言 Remix のファイルベースルーティングについて LT させていただきました。当日に React Router v7 が正式リリースされるなど想定外のことが起こりつつも、皆さんにホットな話題として取り上げていただき有り難かったです。 👇 登壇資料はこちら 終わりに メドレーはこれからも医療ヘルスケア領域において、医療体験にインパクトを与えるプロダクトやサービスの開発に取り組んでいきます。引き続き技術的なチャレンジも行っていきますのでご注目ください！ 最後に、改めて JSConf JP 2024 の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、ありがとうございました。来年の開催も楽しみにしています！ ミイダス社とメルカリ社の素敵なノベルティをいただきました ✨ メドレーでは一緒に働く仲間を募集しています。 ぜひこの記事やブースや登壇などで興味を持っていただいた方はご連絡をお待ちしております！カジュアル面談も大歓迎ですので、お気軽にお問い合わせください！ 当日会場でお時間いただいた皆様、ありがとうございました！ メドレーは今後も技術イベントへ出展/登壇する予定です。今後も皆さんにお会いすることを楽しみにしています！

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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/

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こちらの記事は Medley（メドレー） Advent Calendar 2024 の3日目の記事です。 Who are you? メドレーで主にSRE活動を行っている人材プラットフォーム本部 第四開発グループの玉井です。 最初に簡単にFAQ形式で自己紹介させていただこうと思います。 （昨日は何を食べましたか） ： 麺系ファストフードでは一番好きな小諸そば。 （好きな本は何ですか） ： 柳井正さんの自伝書『一勝九敗』は心に残っています。 （遊びに行くならどこに行きますか） ： アウトドアが好きなのでキャンプなど。 今回は利用しているAWS環境に IAM Identity Center を導入した話をさせていただこうと思います。 セキュリティと管理コストの天秤 メドレーではクレデンシャルな情報は厳重に管理され、平文で外部ツールに保存されることはありません。AWSのIAMユーザのアクセスキーに関しても同じです。 ただ、それでも心配になるのは PCの中に平文で残る情報 。PCも厳重に管理されているのでそうそう漏洩するものではありませんが、それでも可能性はゼロではありません。 一時はAssumeRoleを使うことで漏洩時のリスクを減らしました。 最初の認証では何もできない弱い権限で、AssumeRoleで権限の強いロールに変身する方式を導入しました。 この話を聞いて、腕に包帯を巻いた学生服の少年が天狗のお面を被るいらすとが浮かんだあなたはAWSデベロッパーお馴染みのあのブログの敬虔な読者です。 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を導入した決め手 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全体図 SSOユーザの作成 SSOユーザは前述した通りIAMユーザとは全く別物なので、新たに全員分作成する必要があります。 最低限必要なのは名前とメールアドレスのみです。 作成画面に任意項目で住所や電話番号などあったりするのですが、システム的には全く関係ないようです。IAM Identity CenterをIdPとして使うときのための設定でしょうか。 SSOユーザ作成画面 SSOグループの作成 SSOグループとは、SSOユーザと後述する許可セットをまとめるためのものです。 新しいSSOユーザが増えた場合は、該当のグループに追加してあげるだけでOKです。 SSOグループ作成画面 許可セットの作成 許可セットは、IAMロールの素になるものです。 ここで設定したポリシーが各AWSアカウントにIAMロール、IAMポリシーとしてプロビジョニングされます。 プロビジョニング先のAWSアカウントに既にあるIAMポリシーを使いたい場合は、カスタマーマネージドポリシーでその名前を設定すれば割り当てることができます。 名前が間違っていて存在しないIAMポリシーを設定してしまった場合は、プロビジョニング時にエラーになります。 許可セット作成画面 プロビジョニング “SSOユーザまたはグループ” と “許可セット” を適用したいAWSアカウントにプロビジョニングすることで、対象SSOユーザで該当AWSアカウントにログイン可能になります。 プロビジョニング概要図 SSOアクセスポータル画面 SSOユーザでログインするAWSアクセスポータル画面に、AWSアカウントへのリンクの一覧が表示されます。 このリンクから各AWSアカウントに、任意のロールでログインすることができます。便利ですね！ AWSアクセスポータル画面 一時的なアクセスキーはCLIでも取得できますが、この画面からも アクセスキー のリンクをクリックすると一覧画面が表示されます。 AWSアクセスポータル アクセスキー確認画面 導入後に対応したこと これまでの手順でマネジメントコンソールのでログインはできるようになっていますが、それ以外のツール等で利用するためにしたことをここでは説明します。 ~/.aws/configの修正 ターミナルでAWS CLIを利用するために、これまでアクセスキーを直接指定していたのを、SSOユーザ対応の記述に変更する必要があります。 アクセスキーなどのクレデンシャルな情報の記載が不要になり、この内容が漏洩してもダメージが少ないです。 [default] sso_session = m y-sso sso_account_id = 999999999999 sso_role_name = x xxxxxxxxxxx [sso-session my-sso] sso_start_url = h ttps://xxxxxxxxxxxx.awsapps.com/start sso_registration_scopes = s so:account:access sso_sessionの設定が古いaws_sdkだと対応していなかったりしたので、最新のaws_sdkを使うように mise (開発ツール管理用ツール)に設定しました。 [tools] awscli = "latest" この設定をした状態で aws sso login を実行すると認証画面のブラウザが自動で立ち上がり、ブラウザでの認証完了後にターミナルでCLIが使えるようになります。 ターミナルで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 = a ws --profile default configure export-credentials --format process region = a p-northeast-1 output = j son 対応して良かったこと 管理者目線で良かったこと 管理者目線では、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ですので、お話しだけでも聞いてみたい、むしろ私の推しの話を聞いて欲しい、などなんでもかまいませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 https://www.medley.jp/jobs/

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに 皆さん、こんにちは! エンジニア / エンジニア・デザイナー採用担当の平木です。 弊社では社内のエンジニアが定期・不定期で勉強会を開催しています。この勉強会は、プロダクト開発の話はもちろんですが、各技術の最新情報の共有などを、事業部に留まらず全社的に行う会となっています。 11/15(金)にも社内勉強会を開催したのですが、題材を Web フロントエンド版 DX Criteria についてとしました。そこで作成者の 1 人である日本 CTO 協会 DX Criteria WG の佐藤 歩( @ahomu )さん(以下 ahomu さん)を講師としてお招きして講演をしていただきましたので、そのレポートとなります。 今回の勉強会開催の背景 今年 4 月に Web フロントエンド版 DX Criteria が 発表 されたのを見て、内容的にメドレーでも参考にできる部分が非常に多いと思いました。 作成者の 1 人である ahomu さんは筆者の前職同僚だったということもあり、勉強会講師を打診して快諾いただいたため、開催の運びとなりました。 勉強会について 講演の様子 今回は社外から講師をお招きするということもあり、勉強会へは 25 名ほどの参加となりました。 真剣に講演を聞くメンバー 社内限定での勉強会ということもあり、ahomu さんからも、メドレーに合わせて濃いお話をしていただきました。 歴史を踏まえた昨今のフロントエンドの技術的な変遷 現代のフロントエンドの設計で重視しなければならないポイントと提供するプロダクトの特性の関係 開発持続性を実現するための、開発環境について Web フロントエンド版 DX Criteria の成り立ちや目的を、弊社の状況も交じえながら解説 Web フロントエンド版 DX Criteria のそれぞれの項目について、弊社の状況を踏まえて解説 アセスメント後に、どのような整理をして改善していけばよいかの指針について 佳境に入った講演の様子 上述したものは内容の一例で、全てをお伝えできませんが参加者がより Web フロントエンド版 DX Criteria を「メドレーのプロダクト」ベースで考えられるような講義を行なっていただきました。 参加者からも Web フロントエンド版 DX Criteria の内容を越えたフロントエンド技術についての質問なども飛び出して、大変盛況のうちに終了しました。 改めてプロダクトのフロントエンド開発を事業発展にどのように繋げるかという視点で考えることができた、非常に有意義な時間となりました。 多忙の中、今回の勉強会講師を快諾してくださった ahomu さんに大変感謝しております。ありがとうございました! ahomu さんと記念撮影 さいごに メドレーではこれからも機会があれば、社内の開発者向けに外部講師を招聘して勉強会などを開いていく予定です。 自分の技術を色々な角度から高めていきたい!と考えているエンジニア・デザイナーの方はぜひご連絡ください。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは、2024 年 11 月 23 日に九段坂上 KS ビルにて開催される JSConf JP 2024 にプレミアムスポンサーとして協賛します。 今回は、来週末に控えている JSConf JP 2024 で発表するスポンサーワークショップの内容について紹介します。 JSConf JP 2024 とは JSConf JP は、一般社団法人 Japan Node.js Association が主催する JavaScript の祭典です。 国内はもちろん、海外からも Web 開発者を招き、合計 4 トラックで Web 開発に関連する多数のセッションが予定されています。 公式サイト： https://jsconf.jp/2024/ スポンサーワークショップでは React コンポーネント設計について発表します 16:00 からトラック D にて、 クラウド診療支援システム CLINICS の開発で実践している React コンポーネント設計について、開発体制や医療業務システムの観点を踏まえて紹介します。 徹底解剖！医療業務システムの React コンポーネント設計 - 株式会社メドレー | JSConf JP 【ワークショップタイトル】 徹底解剖！医療業務システムの React コンポーネント設計 【ワークショップ詳細】 医療業務システムの Web フロントエンド開発では、高い安全性の要求に応えつつ、複雑化する医療業務に対して診療効率改善につながる質の高いユーザー体験を提供することが求められます。 加えて、長期利用を見据えた保守性の維持も重要です。 これらの要求に応えるため、私たちは約 4 年間の継続的なアーキテクチャ改善を通して React コンポーネント設計を確立してきました。 本セッションでは、メドレーの開発体制の背景を交えながら、クラウド診療支援システム CLINICS の Web フロントエンド開発で実践している React コンポーネント設計を紹介します。 具体的には次の内容を予定しています： コンポーネントレイヤーと分割粒度 独立性の高い複合コンポーネント設計とデザインパターン 代表的なフロントエンドロジックの分類とそれぞれの実装手法 クロスファンクショナル（非職能別）開発チームにおける Storybook 駆動開発の活用 開発速度と品質を両立するためのテスト戦略 発表予定内容の一部：コンポーネント分割粒度の紹介 ブースでメドレーのエンジニアとお話しましょう トラック D がある 2F の Communication Area にブースを出展します。 ブースでは、メドレーのプロダクトや使用技術、開発組織について、エンジニアとざっくばらんに交流できる場を設ける予定です。 休憩エリアの近くになっていますので、セッションの合間などにぜひお立ち寄りください。 おわりに 最後までお読み頂きありがとうございました。 当日のブースやワークショップでみなさまとお会いできることを楽しみにしております！