認証情報の優先順位はどうなっているのか？
公式ドキュメントによると、SDKを使っているときの認証情報の優先順位は以下の通りになっています。設定の優先順位
AWS SDK for PHPバージョン 3 の認証情報 – AWS SDK for PHP
認証情報の引数を指定しないで新しいサービスクライアントを初期化すると、SDK はデフォルトの認証情報プロバイダチェーンを使用して AWS 認証情報を検索します。SDK では、チェーンのプロバイダの中で、最初にエラーのない認証情報を返したものを使用します。認証情報をチェックする一連のソースについて詳しくは、AWSSDK and Tools リファレンスガイドの「認証情報プロバイダーチェーン」を参照してください。
つまりクライアントを生成するときに付加された認証情報を最優先とし、それ以外はAWS CLIなどの認証情報の優先順位に従うってことですね。
認証情報を付加してクライアントを生成するパターン
$s3 = new Aws\S3\S3Client([
'version' => 'latest',
'region' => 'us-east-2',
'credentials' => [
'key' => ACCESS_KEY,
'secret' => SECRET_KEY,
]
]);デフォルトの認証情報の優先順位は？
クライアント生成時に認証情報を付加しない場合デフォルトに則ると書かれていますが、じゃあデフォルトはどうなっているかというと。設定と認証情報の優先順位
認証情報と構成設定は、システム環境変数、ユーザー環境変数、ローカルの AWS 設定ファイルなど複数の場所にあり、コマンドラインでパラメータとして明示的に宣言される場合もあります。特定の場所が他の場所よりも優先されます。AWS CLI 認証情報と構成設定は、次の順序で優先されます。
AWS CLI を設定する – AWS Command Line Interface
- コマンドラインオプション – –region、–output、–profile パラメータなど、他の任意の場所にある設定を上書きします。
- 環境変数 – システムの環境変数に値を保存できます。
- ロールの継承 – 設定または aws sts assume-role コマンドを通じて IAM ロールのアクセス許可を継承します。
- ウェブ ID によるロールの継承 – 設定または aws sts assume-role コマンドを通じてウェブ ID を使用して IAM ロールのアクセス許可を継承します。
- AWS IAM Identity Center (successor to AWS Single Sign-On) – IAM Identity Center の認証情報は config ファイルに保存され、aws configure sso コマンドを実行すると更新されます。「config」ファイルは、Linux または macOS では「~/.aws/config」、Windows では「C:\Users\USERNAME\.aws\config」にあります。
- 認証情報ファイル – コマンド aws configure を実行すると、credentials ファイルと config ファイルが更新されます。「credentials」ファイルは、Linux または macOS では「~/.aws/credentials」、Windows では「C:\Users\USERNAME\.aws\credentials」にあります。
- カスタムプロセス — 外部ソースから認証情報を取得します。
- 設定ファイル – コマンド aws configure を実行すると、credentials ファイルと config ファイルが更新されます。「config」ファイルは、Linux または macOS では「~/.aws/config」、Windows では「C:\Users\USERNAME\.aws\config」にあります。
- Amazon EC2 インスタンスプロファイルの認証情報 – IAM ロールを各 Amazon Elastic コンピュートクラウド (Amazon EC2) インスタンスに関連付けることができます。関連付けられると、そのロールの一時認証情報は、インスタンスで実行中のコードで使用できるようになります。認証情報は、Amazon EC2 メタデータサービスを通じて配信されます。詳細については、Linux インスタンス用 Amazon EC2 ユーザーガイドの「Amazon EC2 の IAM ロール」および「IAM ユーザーガイド」の「インスタンスプロファイルの使用 」を参照してください。
- コンテナ認証情報 – IAM ロールを各 Amazon Elastic コンテナサービス (Amazon ECS) タスク定義に関連付けることができます。関連付けられると、そのロールの一時認証情報は、そのタスクのコンテナで使用できるようになります。詳細については、Amazon Elastic Container Service 開発者ガイドの「タスク用の IAM ロール」を参照してください。
たくさんありますが実際のサービスで使われる認証情報を抜き出して並べてみるとこんな感じ。
- プログラム内でAWS SDKクライアントを呼び出す際に付加された認証情報
- システム環境変数
- 設定ファイル
- EC2インスタンスに設定されたIAMロール
わかりやすい。まずクライアントの設定、次にサーバへの設定が優先されてIAMロールは一番最後。また同じIAMロールでもEC2の方がECSより優先されるみたいですね。
以上を踏まえて、この辺の話の続きです
AWSが不正利用された件に対する対応（その3・技術対応編）
アクセスキーで動かしていたのをロールに切り替えたのは良かったんですけど、一部のプログラムがアクセスキーを削除してもロールで動いてくれなくてしばらく困りました。どこかに認証情報があるのにどこにあるのかわからない……答えは、AWS CLIでの設定ファイルでした。
aws configure list で確認出来ます。$ aws configure list
Name Value Type Location
---- ----- ---- --------
profile None None
access_key ****************ABCD shared-credentials-file
secret_key ****************ABCD shared-credentials-file
region us-west-2 env AWS_DEFAULT_REGION Typeに「shared-credentials-file」とある場合、AWS CLIで設定され設定ファイル ~/.aws/credentials に保存されています。これらを削除するためには、
aws configure set で空の値を設定するか、$ aws configure set aws_access_key_id ""
$ aws configure set aws_secret_access_key ""credentials ファイルをリネームしてやればOKです。
$ mv ~/.aws/credentials ~/.aws/credentials.oldこのサーバでは環境変数には何も設定されておらず、これで設定ファイルもなくなったので、無事ロールの認証情報が使われるようになりました。
逆に言えばIAMロールの認証情報で動いているEC2インスタンスでうっかり環境変数やAWS CLIの設定ファイルに認証情報を設定してしまうと、優先される認証情報が変わってプログラムが動かなくなることがあるということですね。そんなことせんやろと思いたいですが、案外こういうの、「大丈夫でしょ」とかいってやっちゃうことあるからなー。注意が必要ですね（戒め）。
