AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

stsAssumeRoleについて

Pocket

ホッピーを燃料に書いています、ブログ大好き吉田です。
卒論のCodeCommitすごいですね!まだ見ていない方はぜひここ!を確認してください。

今回は権限委譲のお話です

aws_icon-iam_white-320x320

少し違う話をします

僕はハンズラボに入ってから業務でAWSを使用しました。
個人でAWSを使用していると「他のアカウントに権限を移譲する」なーんてことまず考えません。
だって移譲するもなにも自分のアカウントしか無いわけですから。

しかし

エンタープライズで使ってるとそうではありません。
コンソリデーティットビリングみたいに個人利用では無縁な話がゴロゴロと転がっています

個人で使っていると想像もしないのですが、もしAWSのアカウントが50個も100個もあったらどうしますか?
1個1個請求が来ても困りますよね?
だから請求を一つのアカウントにまとめる(一括請求)。これは分かります。
でも、50個も100個もあったら何が「大変」なのか、まで僕は考えていませんでした。

なんでも良いのですが、例えば「インスタンスが立ちっぱなしかどうか確認したい」とします。

マネジメントコンソールにログインして確認する。
AWS CLIを使用して確認する。
確認方法はありますよね。

でもそれ

100回ログインします?cliを使用するとして、100個のアクセスキーをCredentialに登録します?その100個、定期的に交換します???
僕は嫌です。
そんな時間あったら某ソーシャルゲームで音符叩きながらしながらプロデュースします(笑)

じゃあ、どうすればいいのか

今回はそこのところを考えていきます。
特にAWS自習勢に捧げます。地味だけど、大事。


AssumeRole
ものすごいざっくり言います。

はい、これ俺ん家の合鍵。あと適当によろしく。あ、そうそうキッチンは触らないでね!

合鍵あればお家入れますよね
家の中で好きにしてていいけど、キッチンはダメだって言われましたね。
家がアカウント、中のリソースは家主に制限されました。
このくらいのイメージです。

少しまじめに説明します

渋谷さんのアカウントと池袋さんのアカウントがあったとします。
ところで、ハンズのロゴが無くなったそうですよ?(個人的には花屋と発明(以下略))

  • 渋谷さんのアカウントにS3 Full Access の権限を持ったロールを作成します
  • 池袋さんのアカウントでIAMユーザーを作成します

池袋さんは渋谷さんのロール(鍵)を借りて、渋谷さんのS3(家)にアクセス(入り)します。

こういうことです。
でもこの、家の鍵の貸し借りって「お互いの信頼関係」の元に成り立っていますよね?
そうです。2つのアカウントの間で信頼関係を結んで初めて実現できる仕組みになっています。
こう考えるとAssumeRoleってそんな難しく無いですよね
じゃあ、その信頼関係の結び方ですが、

信頼関係の結び方は次のブログで紹介するという姑息な手を使います!

_(_ _)_。oO(次回をおたのしみに)

余談、AssumeRoleの何が良かったか
[良い点はセキュリティ]
50でも100でも、大量にあるアカウントのインスタンス情報を取得する際、操作する1つのアカウント(池袋さん)のIAMユーザーを使用してCLIコマンドが叩ければ、どのアカウント(渋谷さん’s)に対しても信頼関係を結んだロールのアクセス許可の範囲内でAPI Callが可能な点です。
stsで引き受ける鍵は一時的なものなので、仮に悪意のある第三者に情報を抜かれたとしても、操作に使用したIAMユーザーを止めるなり鍵を新しくするなりすれば、100個のIAMユーザーをどうにかしなくて良い点です(これすごい便利)
100ユーザー調べる時は鍵の差し替えだけなのでスクリプトを組んでfor文でぶん回すだけで簡単に情報の取得もできます。

(2016年3月3日追記)
続編をアップしました!こちらです。

Pocket