IAMロールはどこから来て、どこへ行くのか / Where do IAM rolls come from and where to go?

32131422fbba6c81b3827a6e967bf1e2?s=47 Ryotaro Tamura
November 04, 2017

IAMロールはどこから来て、どこへ行くのか / Where do IAM rolls come from and where to go?

JAWS FESTA 2017

32131422fbba6c81b3827a6e967bf1e2?s=128

Ryotaro Tamura

November 04, 2017
Tweet

Transcript

  1. 2.

    1 自己紹介 • 名前:田村 龍太郎 • 所属:ハンズラボ株式会社 • 入社:2017年3月 •

    出身地:徳島県 • AWS歴:8ヶ月 • 初登壇で緊張してます
  2. 11.

    10 よくあるユースケース EC2 Lambda S3 DynamoDB ロール • EC2のインスタンス等にロールを設定することで、 権限に応じたAWS

    リソースを呼び出し可能 • 例: S3のバケットにファイルをアップロード • リソースの利用権限はロールにアタッチされたポリシーによって決まる ポリシー リソースを 呼び出し アタッチ ロール
  3. 13.

    12 IAMユーザーの場合 • マネジメントコンソールでアクセスキーを生成 • AWS CLIの場合は aws configure を実行してキー情報を入力

    • デフォルトだと ~/.aws/credentials に記録される • IAMユーザーが持つ権限通りにリソースが利用ができる • ではIAMロールは?
  4. 14.
  5. 15.

    14 EC2インスタンスで追ってみた • ロール名を指定してリクエストするとCredentialがJSONで返ってくる • 見覚えのある文字が • 何が行われたのか? $ curl

    http://169.254.169.254/latest/meta-data/iam/security-credentials/sample-role { "Code" : "Success", "LastUpdated" : "2017-10-30T06:54:40Z", "Type" : "AWS-HMAC", "AccessKeyId" : "ASIAXXXXXXXXXXXXXXXX", "SecretAccessKey" : "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "Token" : "xxxxx...", "Expiration" : "2017-10-30T13:04:40Z" }
  6. 16.

    EC2インスタンス EC2サービス STS IAM ① ⑤ ② ④ ③ 15

    メタデータの動作イメージ AssumeRole 実行 一時的なCredential メタデータを リクエスト アタッチ メタデータの レスポンス AssumeRolePolicy 確認 IAMポリシー
  7. 17.

    16 AssumeRoleとは • AWS Security Token Service(STS)に用意されているAPI • 指定したIAMロールの持つ権限を、一時的に引き受ける(Assume)機能 •

    AssumeRoleという動作の主体になるのは権限を必要とする側 • 今回の例では、EC2がSTSに「オレにそのロールの権限使わせてよ」 と伝える感じ ① 権限ください ③ あげる ② Credential生成
  8. 18.

    17 AssumeRoleとは • 権限を要求する主体は、ロールと同じAWSアカウント内に限定されない • 別のAWSアカウントにいるIAMユーザー • Amazon, Facebook, Google,

    Cognito で認証されたユーザー • 任意のOpenID ConnectおよびSAMLのIDプロバイダで認証されたユーザー ① 認証 ⑥ あげる ⑤ Credential生成 ② トークン取得 ③ ください(トークン付) ④ 検証
  9. 22.

    21 余談 • わざわざメタデータにリクエスト送らなくても、インスタンス内のCLIで 直接AssumeRoleを実行すればいいのでは? $ aws sts assume-role --role-arn

    arn:aws:iam::111122223333:role/sample-role --role-session-name "hogehoge" • できない (aws configureなどを行っていない状態) • ロールのAssumeRolePolicyでは • 特定のEC2インスタンスを信頼しているのではない • EC2サービス(マネージドな部分)を信頼している • インスタンスにロールを設定するということは • AssumeRoleを行う権限を与えているのではない • メタデータの該当ロールのURIへリクエストを送る権限を与えている • EC2サービス(メタデータ)を経由する必要がある
  10. 29.

    28 余談: Authorizationヘッダの各項目 • AWS4-HMAC-SHA256 • 署名に使用したアルゴリズム • 2017/11/04時点で推奨される署名バージョン4では HMAC-SHA256

    • Credential (AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request) • アクセスキーID • タイムスタンプ (yyyymmdd) • 対象リージョン • 対象サービス名 • 固定文字列 (aws4_request) • SignedHeaders (content-type;host;x-amz-date) • 署名されたHTTPリクエストのヘッダ一覧(Authorizationヘッダは除く) • 「署名された」というのは後述のSignature内に含まれるという意味
  11. 30.

    29 余談: Authorizationヘッダの各項目 • Signature (5d672d79c15b13162d9279b0855cfba6789a8edb4c82c400e06b5924a6f2b5d7) • シークレットアクセスキー • タイムスタンプ

    • 固定文字列 (AWS-HMAC-SHA256) • CredentialString (AKIDEXAMPLE/20150830/us-east-1/iam/aws4_request) • HTTPリクエストの中身 (CanonicalStringと呼ぶらしい) • メソッド • URI • クエリ文字列 • 元のHTTPリクエストに含まれる全ヘッダ名 (content-type;host;x-amz-date) • BodyのSHA256ハッシュ値 • 以上の文字列をHMAC-SHA256で複数回計算してハッシュ値にしている • 詳細な実装を追いたい場合は、SDKなどを参考にしてください • GolangのSDKだとこの辺に書いてます • https://github.com/aws/aws-sdk-go/blob/master/aws/signer/v4/v4.go