会員登録すると
学習することができます。
会員登録する(無料)
登録済みの方はこちら
ログイン

SDKと認証情報 ― IAMロールと一時的な認証情報で、鍵をコードに書かずにAWSを呼ぶ

目安学習時間 25分

課題

全問正解でレクチャー完了です。

【問題1】

STS の AssumeRole が返す一時的な認証情報に含まれないものはどれですか。

[選択肢]

【問題2】

EC2 で動くアプリから S3 を読むとき、認証情報の渡し方としていちばん適切なものはどれですか。

[選択肢]
会員登録すると
学習することができます。
会員登録する(無料)

学ぶ目的

SDK は API を呼ぶための道具

AWS のサービスは、すべて API(決まった形のリクエストを受け付ける窓口)で操作します。SDK は、その API を各言語から呼ぶためのライブラリです。リクエストへの署名(Signature Version 4)、一時的なエラーやスロットリング(呼びすぎで断られること)のときの再試行を、SDK が代わりにやってくれます。

認証情報はどこから来るか

SDK は、決まった順番で認証情報を探します。コードで直接渡したもの、環境変数、~/.aws/credentials などの設定ファイル、そして EC2 のインスタンスプロファイルや Lambda の実行ロールのような、実行環境に付いた IAM ロールです。

アクセスキーをコードに書かない

長く使えるアクセスキーをコードや設定ファイルに書くと、漏れたときに被害が大きくなります。AWS の上で動くコードには IAM ロールを付け、一時的な認証情報を使わせるのが基本です。

AssumeRole と一時的な認証情報

STS(Security Token Service)の AssumeRole を呼ぶと、ロールの権限を持った一時的な認証情報(アクセスキー ID、シークレットアクセスキー、セッショントークンの3つ)が返ります。期限があり、AssumeRole のセッションは既定で1時間です。別のアカウントのリソースを使うときは、相手のアカウントのロールの信頼ポリシーで自分を許し、そのロールを引き受けます。

このレクチャーで学ぶこと

  • SDK が代わりにしてくれること(署名・再試行)
  • SDK が認証情報を探す場所
  • アクセスキーをコードに書かず、IAM ロールを使う理由
  • AssumeRole と、別アカウントのリソースへのアクセス

質問

まだ質問は投稿されていません。

質問投稿

ログイン後に質問の投稿ができます。