(Google+)58この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。訓練されたアップル信者、都元です。前回(昨日)はAWSのクレデンシャルとプリンシパルを整理し、「開発運用スタッフ」が利用するクレデンシャルについてプラクティスを整理しました。今回はAWS上で稼働する「システム」が利用するクレデンシャルについてのプラクティスを整理しましょう。システムが利用するクレデンシャルシステムが利用するとはどういうことかといいますと、要するに「ユーザがアップロードしたファイルをS3に保存する」だとか「S3バケットに保存されたファイル一覧を取得して表示する」だとか、そういう操作をするシステムを作ることです。このようなシステムでは、APIキーを利用しますね。AWSのAPIキーには、これもまた大きく分けて2種類があります。(一時キー)皆さんが一般的に目にしているAPIキーは、永続キーになります。「アクセスキーID」と「シークレットアクセスキー」の組み合わせですね。こちらは、明示的に無効化の操作をしなければ、発行後無期限で利用可能です。後者は、「アクセスキーID」と「シークレットアクセスキー」の他に「セッショントークン」という3つの要素の組で構成されます。有効期限が切れたら再発行が必要です。一時キーの発行・再発行等の処理は、普段は見えないプログラム内で自動的に行われるため、多くの場合、開発運用スタッフが目にすることはありません。APIキーをシステム内にハードコーディングしないシステムがAPIキーを手に入れるには、何通りもの手段があります。それぞれ例示していきたいと思います。ここから出てくるコードはJavaです。SDKによる、最もよくあるAPI利用例はこんなかんじです。...ほとんどの資料で、このような説明がなされます。ここで使っているキーは永続キーです。このようなコードは当然git等にコミットして管理されるため、権限の共有範囲を管理できなくなってしまいます。PropertiesCredentials下記のように、クラスパス内から読み込んだとしても、同様にコミット管理されることになり、あまり適切ではありません。SDKの各クライアントのコンストラクタとして、ここまでは下記の(1)を利用していました。これとは別に(2)というコンストラクタもあります。(2)前者は「クレデンシャルそのもの」を渡すパターン、そして後者は「必要に応じてクレデンシャルを取得する手段」を渡すパターンです。*2例ですが、StaticCredentialsProviderはgetCredentialsで、コンストラクタから受け取ったクレデンシャルをそのまま返すAWSCredentialsProviderの実装です。...ClasspathPropertiesFileCredentialsProviderAWSCredentialsProviderの実装は他にもあります。ClasspathPropertiesFileCredentialsProviderは、前述の「クレデンシャルをクラスパス内から読み込む」ような実装です。引数を省略すると、AwsCredentials.propertiesを読み込むようになっています。...PropertiesCredentials再びコード内に書くパターンよりももう少しマシな例として、下記のような書き方を見てみましょう。...この書き方では、クレデンシャルをアプリケーションの外に出すことはできますが、これでもデプロイするサーバのファイルシステムにはクレデンシャルを書き込むことになります。運用担当者は自由に読み書きができるはずですので、共有範囲のコントロールはできません。EnvironmentVariableCredentialsProviderAPIキーを環境変数から読み込む仕組みです。...これもコード内からクレデンシャルを追い出すことができますが、どこかで環境変数を設定するコマンドを書かなければなりません。SystemPropertiesCredentialsProviderJavaにはシステムプロパティという仕組みがありまして、起動時のオプションでアプリケーションに値を引き渡せます。...まぁこれも、どこかにキーを生書きする必要があるでしょう。InstanceProfileCredentialsProviderさて、ここまで色々紹介して来ましたが、「APIキーをシステム内にハードコーディングしない」というプラクティスは何れも達成できていませんね。対応策を提示したいと思います。Roleを適用したEC2インスタンス」でしか上手く動きません。instancesを使ってみるを参照してください。Serviceという機能があります。EC2内から169.254.169.254に対してHTTPリクエストを行うことにより、インスタンスIDやAMIのIDをはじめ、様々な情報を得ることができます。Serviceを利用して一時キーを取得しています。従って、EC2以外(例えば開発マシン)でこの実装を使っても、一時キーが得られないわけです。永続キーはBasicAWSCredentialsを使いましたが、一時キーにはセッショントークンも含まれますので、別の実装BasicSessionCredentialsを使います。Serviceから得たキーをこのように処理しています。Roleを使って実現します。この仕組みを使えば、システムの「AWSアカウント間ポータビリティ」も柔軟に確保できます。AWSCredentialsProviderChainただ、InstanceProfileCredentialsProviderを利用する場合、一つ欠点があります。ローカル開発環境で動かなくなるんですね。そこで、AWSCredentialsProviderChainを使うと良いでしょう。ローカル開発環境では、環境変数なりシステムプロパティなりに、自分の持っているIAMのクレデンシャルを突っ込んでおけば上手く動作するってわけです。...って毎回書くのめんどくさいじゃないですか。...って毎回書くのもそこそこめんどくさいじゃないですか。