AWSアカウント シングルサインオン構成のご紹介(電通デジタル自社開発部門 2020年上期版)
電通デジタルでSite Reliability Engineer(SRE)をしている齋藤です。
先日(8/5)に7/22開催のAWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料が公開されました。
資料中では以下の内容を説明しています。
・AWSではアカウントに個別のIAMユーザを作成してログインする代わりに、IDプロバイダ(IdP)を使用し、シングルサインオンができること
・シングルサインオンは組織に独自のID基盤がある場合や、複数のAWSアカウントを使用している場合に有効であること
・シングルサインオンの実現の方法にはいくつかパターンがあり、運用をふまえながら何を選択するのがよいかであること
弊社の自社開発部署もAWSをマルチアカウント構成-シングルサインオンで運用しています。今回はその事例を上記資料の選定パターンチャートをふまえてご紹介させていただきたいと思います。
構成の前提として、弊社の自社開発部署の開発者数/AWSアカウントの数は共に少数です。その前提での現状(2020年)の構成サマリは以下になります。
・IdPにはAuth0を利用
・アイデンティティストアにはAWS Directory ServiceのSimple ADを利用
・フェデレーティッドSSOでのAWSアカウントのクレデンシャル取得は独自スクリプトを作成して対応
図にすると以下になります。
以下でそれぞれの選択について説明します。
IDプロバイダーの選択
複数のプロダクトで開発/本番環境を展開していくにあたり、AWSのマルチアカウント戦略を採ることになりました。そこでユーザ管理はシングルサインオンにしたい。とまでは順当な流れです。IDプロバイダー(IdP)を選択することになりました。前述のセミナーの資料のチャートを引用すると以下のようになります。
(20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用 スライド34より)
・Organizationsマスターアカウント管理者である
→ 「いいえ」：諸々の歴史的経緯で請求代行サービスを利用していました。
・組織のポリシーで外部サービスの利用が可能
→ 「はい」：厳密にはIDプロバイダーの選択時に、会社としてもIDプロバイダーを選択・切り替えの検討をしており、導入・弊部署の要求の取り込みなどがスケジュールに合わなかったので個別承認をもらいました。
と、このチャートと同じようにIDプロバイダーにはマネージドサービスを使うことになりました。既にSSOでの利用実績があったことと、API・接続方法のドキュメントが充実していたことでAuth0を選択することにしました。
アイデンティストアの選択
同様にアイデンティティストアも前述のセミナーの資料のチャートを引用すると以下のようになります。
(20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用 スライド38より)
・組織のID基盤と連携した外部IDプロバイダーが存在し、管理権限がある
→ 「いいえ」：会社のものは情報システム部門の管理ですし、開発部個別のID基盤はこれ以前にはありません。
・構成するIdP専用の少数のID基盤を運用したい
→ 「いいえ」：ユーザは少数ですが、別途ユーザ-AWS間にVPNを張る要件があり、AWS ClientVPNのユーザ管理が必要でした。IdP側で管理すると二重管理になるため、IdPでもAWS Client VPNのユーザプールのSimpleADを使うことにしました(VPNの話はまた別の機会で)。
Active Directory(AD)は運用・管理を割り切ってAWS Directory ServiceのSimple ADをServerとして使い、EC2にWindows Serverを立ててAD Clientとして利用しています。また、Windows ServerにはAuth0とAD Clientの接続のためにAuth0のAD LDAPコネクターをインストールしています。
この構成は未だ「これでよかったのか」と思う面があります。普段の開発・運用スタック内にWindows ServerやADがないので、メンバーでも議論になりました。また、切り替え前提の1回きりの構築だと思っていたら諸事情で同じような構成を他でも作る事になりました。なかなかままならないものです。
手作業が多く残っている領域なのですが、アカウント申請の仕組みを別途作成し、アカウント台帳の管理やアカウントの作成/削除のコマンドの生成をするなど、それなりの運用で済むようにしています。
フェデレーティッドSSOでのAWSアカウントのクレデンシャル取得
AWS 公式ドキュメントにありますが、フェデレーティッドSSOでAWSアカウントのクレデンシャルを取得する場合、AWS STSを利用してAssumeRoleで一時クレデンシャルを発行します。APIリクエストになるのでプログラムを用意したいところです。
探してみたところAWSでSAMLでフェデレーティッドSSOでクレデンシャルを取得する Versent/saml2awsが見つかりました。
しかし、Versent/saml2awsはAuth0には対応していませんでした。Auth0対応してPull Requestを出すという対応……ができれば一番よかったのですが、その時点でAWS各アカウントの共通部分構築がはじまっており、すぐにでもプログラムが必要でした。そこで、まずAWS公式に一部サンプルコードがあったPythonで実装して対応しました。
実装したPythonスクリプト(saml2awsにならってauth02awsという名前にしました)での一時クレデンシャルの取得フローは以下になります。
認証はADで行い、権限はADのユーザの属性とAuth0のRule機能でマッピングして実現しています。
このPythonスクリプトを使ってエンジニアは普段
# 実際には一行で実行
$(auth02aws --username USERNAME \ # ADのユーザ名
--profile ACCOUNT_NAME \ # AWSのアカウント名
--keyring \ # パスワードはkeyringに保存されているものを使う
--sh # シェルの環境変数として出力
)として、利用するアカウントのクレデンシャルを環境変数に反映しています。アカウントを切り替えたい場合はprofileオプションのアカウント名を変えてスクリプトを実行します。複数環境を切り替えながらの作業が必要になる場合も手間が大幅に減りました。
このスクリプトは機能拡張に伴って弊社独自の内容を含むようになったので公開は難しいのですが、処理フローは理解したのでVersent/saml2awsに還元していきたいと思っています。
まとめ
ユーザ/AWSアカウント数ともに小規模な弊社自社開発の部署のAWSのマルチアカウントとSSOの構成についてAWS Black Belt Online Seminar「AWSアカウント シングルサインオンの設計と運用」の資料のチャートを使ってご紹介させていただきました。
今後の展望としては
・全社の仕組みに合わせていく(異動の対応を全社と連動させたい、認証/認可に必要な箇所を揃えたい)
・Versent/saml2awsなどへのナレッジ還元をしていきたい(Auth0の対応リクエストのIssueが上がってるので)
などがあります。
ユーザ数/AWSアカウント共に少数な場合の事例としてどなたかのご参考になれば幸いです。