この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは(U・ω・U)
AWS事業部の深澤です。
さて僕は先日、こんな記事を上げました。
【小ネタ】direnv + assume-roleでクレデンシャルを取得、有効期限を設定してみる
しかしこの記事に対して以下のようにフィードバックをいただきました。
※ こちらですがremind101/assume-roleでも以下のようにコマンドを用いればセッション継続時間を指定できると指摘をいただきました。
$ assume-role -duration 2hこちらは改めて検証し後日修正させていただきますm(_ _)m
そうです、今回はここを検証すべく記事を書きました。
前提
ロールやポリシーについては【小ネタ】direnv + assume-roleでクレデンシャルを取得、有効期限を設定してみる に書いた環境をそのまま利用しています。
remind101/assume-roleのインストール
インストール方法は利用されている環境に応じて公式ドキュメントを参照してください。
https://github.com/remind101/assume-role
僕の場合はMacを利用しているので次のようにインストールしました。
$ brew install remind101/formulae/assume-role事前準備
踏み台となるAWSアカウントのconfigとクレデンシャル情報を記載します。まずは.aws/credentialsに以下のような感じで書き込みましょう。
[bastion]
aws_access_key_id=AKIAXXXXXXXXXXXXXXXX
aws_secret_access_key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX続いて.aws/configに設定を書き込みます。
[profile bastion]
region=ap-northeast-1次に以下の情報を.aws/configに書き込みます。
region=リージョン
role_arn=遷移先で作成したロールのARN
mfa_serial=遷移元で設定したMFAデバイスのシリアル番号
source_profile=踏み台アカウントの設定が記載されているprofile自分の場合は次のような設定になりました。
[profile private]
region=ap-northeast-1
role_arn=arn:aws:iam::123456789012:role/sample_switch_role
mfa_serial=arn:aws:iam::123456789101:mfa/bastion-account
source_profile=bastionここまでで事前準備は完了です。この段階で簡単な動作確認をしてみましょう。次のように叩いて遷移先のリソース状況が取得できればただしく設定できています。
$ assume-role private aws s3 ls
MFA code: 123456
〜〜ここにaws s3 lsの結果が表示される〜〜direnvと組み合わせる
direnvのインストール方法や設定方法については先日の僕の記事を参照ください。
【小ネタ】direnv + assume-roleでクレデンシャルを取得、有効期限を設定してみる
direnvでは以下のように書いてassume-role privateの出力結果がそのまま実行されるようにすればOKです。
eval $(assume-role private)実際に検証してみた
さて、準備が長くなりましたがここからが今回検証の趣旨です。まずはassume-roleのhelpから-duration引数の詳細を見てみましょう。
$ assume-role --help
Usage: assume-role <role> [<command> <args...>]
-duration duration
The duration that the credentials will be valid for. (default 1h0m0s)なるほど、デフォルトで1時間が設定されるようですが時間(h)分(m)秒(s)の単位で指定できそうです、早速やってみます。なおこちらも最小設定時間は900秒（15分）からです。direnv editで次のように書き込みます。
eval $(assume-role -duration 900s cm_private_aws)保存してMFAを入力。
$ direnv edit .
direnv: loading .envrc
MFA code: 123456
direnv: export +ASSUMED_ROLE +AWS_ACCESS_KEY_ID +AWS_SECRET_ACCESS_KEY +AWS_SECURITY_TOKEN +AWS_SESSION_TOKENこの状態で正しく目的環境の認証が得られていることを確認します。
$ aws s3 ls
〜〜〜このまま15分待機するとセッションが無効になることを確認しました。
$ aws s3 ls
An error occurred (ExpiredToken) when calling the ListBuckets operation: The provided token has expired.両方使ってみて
ということで前回僕が記事に書いた「セッションの継続時間を指定することができません。」というのは誤りである事がわかりましたm(_ _)m
個人的にはcoinbase/assume-roleとremind101/assume-roleを実際に使ってみて比較する事ができて非常に良かったなと思います。せっかくなので両者を比較してみたいと思います。
言語
ここでいう言語とは、プログラミング言語です。remind101/assume-roleはGo言語で作られていてcoinbase/assume-roleはShellで作られています。懸念点としてはShellの場合は他のサービス（コマンド）に依存するのでうっかりバージョンアップをしてしまった際に挙動がおかしくなる等の懸念があります。実際にcoinbase/assume-roleはjqコマンドとawsコマンドのインストールが必須です。
この点はremind101/assume-roleの方が優れているなと思います。
Github上でのスター数
Githubでは良いなと思ったツールにスターを付けることができるのですが、OSSのツールではこのスター数がどのくらい付いているかを僕は結構見ます。本記事執筆現在（2019/10/9 17:00）で、remind101/assume-roleのスター数が318個、coinbase/assume-roleのスター数が409個でした。
この点はcoinbase/assume-roleの方が多いですね。
コミュニティの活発具合
こちらはGithubの以下の観点から確認してみました。
- contributorの人数
- coinbase/assume-role: 16人
- remind101/assume-role: 9人
- masterへの最終コミット（日にちはJSTです）
- coinbase/assume-role: 2019年9月5日
- remind101/assume-role: 2018年12月25日
- 最後のissue更新
- coinbase/assume-role: 2019年7月26日
- remind101/assume-role: 2019年6月25日
ここは結構判断が難しいところですが、これらの観点から自分はcoinbase/assume-roleの方がコミュニティが活発であると思いました。issueのところをみていただくと分かりますが、remind101/assume-roleは最新issueのタイトルが「No releases.」になっています。コミュニティが活発である方がBugの修正や改善が多く行われるので安心ですよね。
インストール方法
両者ともMacならbrewコマンドでインストール可能です。Linuxとwindowsの場合を比較します。
Linux
- coinbase/assume-role
- remind101/assume-role:
Windows
- coinbase/assume-role
- READMEに明記なし
- remind101/assume-role:
こちらはそれぞれが作られた言語の特性がもろに出ていますね。Linuxに簡単にインストールという観点ですとcoinbase/assume-roleであればcurlという標準コマンドでインストール可能なのは強いですし、一方で言語のところでも述べたように安定性という観点ですとGo言語上でバージョン揃えて動かす方が安全だと思います。Windowsで使うならremind101/assume-roleでREADMEにインストール方法があるのは強いですね。とはいえ、Windows上でLinuxを動かすという考え方もありますのでWindowsで全く使えないということもないと思います。
設定の煩雑さ
両者ともに優れているポイントとして独自の設定ファイルを持たず、.awsディレクトリ配下のaws cli標準configファイルで動作するのは優れている点だと思います。coinbase/assume-roleは実行の前にsource $(which assume-role)が必要だったり、遷移元情報をAWS_PROFILE_ASSUME_ROLEという環境変数に格納しなければならなかったりと少し煩雑さがありますね。
謝辞
前回の僕の記事の間違いに対し指摘をいただいたのは弊社の佐伯航でした。この場を借りてお礼申し上げますm(_ _)m
感想
前回記事で失敗してしまったものの、改めて今回色々検証して記事にまとめることができたのは非常に良かったです！両者とも非常に優れたツールなので、本記事を参考にまだ導入されていない方は是非導入を検討いただけると幸いです。
以上、深澤（@shun_quartet）でした！
0
