- 公開日
- 最終更新日
AWS CLI の認証情報の優先順位
この記事を共有する
はじめに
AWS CLIが認証情報を利用するのには優先順位があります。
私はEC2に認証情報を設定したつもりでも、そのことを知らず認証に失敗することが過去に何度かありました。
今回は自戒も込めて認証情報の優先順位についてまとめたいと思います。
設定と認証情報の優先順位 （AWS CLI の場合）
- コマンドラインオプション
- 環境変数
- AssumeRole
- AssumeRole（ウェブ ID）
- IAM Identity Center (SSO)
- credentials ファイル
- カスタムプロセス
- config ファイル
- コンテナ認証情報
- インスタンスプロファイルの認証情報
AWS CLI の設定を構成する - AWS Command Line Interface
結構多いですね、、、
ひとつひとつ見ていきます。
コマンドラインオプション
AWS CLI の --region、--profile などですね。
これらのオプションを利用すると設定を上書きします。これが最も優先されるようです。
環境変数
AWS_ACCESS_KEY_ID 、 AWS_SECRET_ACCESS_KEYといった環境変数です。
サポートされている環境変数は他にもあるので興味ある方は以下をご確認ください。
AWS CLI の環境変数の設定 - AWS Command Line Interface
AssumeRole
aws sts assume-role を使って スイッチロールをした場合です。
AssumeRole（ウェブ ID）
aws sts assume-role を使うところまでは同じですが、ウェブ ID フェデレーションと Open ID Connect (OIDC) を使用してロールを引き受けた場合です。
config ファイルに web_identity_token_file=/path/to/a/token といった形でトークンファイルのパスを追加します。
OIDC federation - AWS Identity and Access Management
IAM Identity Center (SSO)
aws sso login を利用してSSOする場合の認証方法です。
こちらの設定はconfigファイルに追加するかaws configure ssoをすることで可能です。
credentials ファイル
皆さんご存知かと思いますが、credentials ファイルです。
Linuxでは ~/.aws/credentials
WindowsではC:\Users\USERNAME\.aws\credentials
にあります。
カスタムプロセス
AWS CLIで直接サポートされていない認証情報をシェルスクリプトやpython等を利用して認証情報を取得する場合に利用します。
config ファイルにcredential_process = /path/to/program-fileといった形で設定します。
config ファイル
こちらもcredentials ファイルとセットで良く見るファイルですね。
Linuxでは ~/.aws/config
WindowsではC:\Users\USERNAME\.aws\config
にあります。
コンテナ認証情報
ECSのタスク定義に関連付けされているIAMロールです。
インスタンスプロファイルの認証情報
EC2に関連付けされているIAMロールです。これが最も優先順位が低いです。
EC2に適切なロールをつけてるのにAWS CLI ができない っていうトラブルは、別の認証情報を使ってしまっているからってことがほとんどです。初心者がよく引っかかってしまうポイントですが優先順位が一番低いのでこのようなことが起きてしまうんですね。
ちなみにEC2が関連付けされたIAMロールの認証情報を取得できるのは IMDS というサービスのおかげです。
もしIMDSをオフにするとインスタンスメタデータにアクセスができないため、IAMロールの認証情報を取得できなくなります。
今どの認証情報を使っているのか確認する方法
優先順位がわかっても自分が今何の認証情報を利用しているのかわからないとトラブルシュートのときに困りますよね。
そんなときにはaws configure listを利用するのが良いと思います。
Typeの列を確認することで各設定値の取得元の確認ができます。
以下は一部のパターンの表示例です。
# プロファイルを指定した場合（--profile test）
Name Value Type Location
---- ----- ---- --------
profile test manual --profile
access_key ****************XXXX shared-credentials-file
secret_key ****************YYYY shared-credentials-file
region ap-northeast-3 config-file ~/.aws/config
# 環境変数を指定した場合
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************XXXX env
secret_key ****************YYYY env
region ap-northeast-1 env ['AWS_REGION', 'AWS_DEFAULT_REGION']
# AssumeRoleした場合
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************XXXX assume-role
secret_key ****************YYYY assume-role
region ap-northeast-1 config-file ~/.aws/config
# credentials ファイルに記載されている場合
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************XXXX shared-credentials-file
secret_key ****************YYYY shared-credentials-file
region ap-northeast-1 config-file ~/.aws/config
# IAMロールが利用されている場合
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************XXXX iam-role
secret_key ****************YYYY iam-role
region ap-northeast-1 imds
# IMDSを無効にしcredentialsファイルなども無い場合
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key <not set> None None
secret_key <not set> None None
region <not set> None None
まとめ
普段はあまり優先順位を意識しないかと思いますが、たまにこの仕様に苦しむことがあると思います。
優先順位そのものは覚えなくていいですが、この記事を見て「優先順位があるんだな～」くらいには頭の片隅に入れてもらえたら嬉しいです。
今回はAWS CLIについての優先順位を上げていますが、SDKなどでも固有の認証設定の方法はありつつも基本的な考え方は変わらない認識です。
設定リファレンス - AWS SDKs および ツール
皆さんの参考になれば幸いです。
この記事は私が書きました
渡邉 和貴
記事一覧CCoEをやってます。あと森と山に出没します。 好きなAWSサービスは CloudFormation
