aws loginしてもdefaultのcredentialsが優先される場合の対処法と認証情報の優先順位
こんにちは、臼田です。
みなさん、aws loginしてますか?(挨拶
待望のaws loginコマンドが出てきましたね。ガリガリ使っていますでしょうか?
私も早速試したらdefaultのcredentialsが優先されて上手く動作しなかったので、調査してみました。
aws loginが上手く動かない方はいろんな要因があるのでユーザーガイドのトラブルシューティングをご確認いただきつつ、この記事のタイトルのように優先順位に関わる問題だと考えられる場合には本記事をご参照ください。
aws loginしたけど元のクレデンシャルが使われる件
早速aws loginしたら下記のようになりました。
# デフォルトの状態を確認
% aws sts get-caller-identity
{
"UserId": "AIDAAAAAAAAAAAAAAAAAA",
"Account": "999999999999",
"Arn": "arn:aws:iam::999999999999:user/default-credentials-user"
}
# ログインする
% aws login
Attempting to open your default browser.
If the browser does not open, open the following URL:
[中略]
Updated profile default to use arn:aws:sts::999999999999:assumed-role/login-role/login-role credentials.
# ログイン後の認証情報を確認する
% aws sts get-caller-identity
{
"UserId": "AIDAAAAAAAAAAAAAAAAAA",
"Account": "999999999999",
"Arn": "arn:aws:iam::999999999999:user/default-credentials-user" # 変わっていない
}
今回はこうなっている方向けの内容です。
トラブルシューティングのガイドにはaws configure listを利用して、現在利用している認証情報が何をベースにしたものなのかを確認する手順があります。
やってみるとこうなりました。
% aws configure list
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
この結果からは、access_keyとsecret_keyがshared-credentials-fileを参照している、ということがわかります。
shared-credentials-fileはファイルで言うと.aws/credentialsの事を指します。つまりデフォルトで設定されている認証情報を参照しているんですね。
AWS CLIの認証情報の優先順位を理解する
AWS CLIを利用する際に使用する認証情報はいろんな手段で設定・選択可能です。
この優先順位は下記のようにガイドに記述されています。
- コマンドラインオプション(
--profile) - 環境変数(
AWS_ACCESS_KEY_ID) - ロールの継承
- ウェブIDによるロール継承(
aws sso login) - AWS IAM Identity Center
- 認証情報ファイル(
~/.aws/credentials) - カスタムプロセス
- 設定ファイル(
~/.aws/config) - コンテナ認証情報
- EC2インスタンスプロファイル認証情報
先程確認したデフォルトの状態はつまり「6. 認証情報ファイル(~/.aws/credentials)」になります。
ではaws loginはどこでしょうか?
ガイドにはaws login後には~/.aws/configにdefaultとしてlogin_session = arn:aws:iam::0123456789012:user/usernameが記載されると書かれています。
つまり、aws loginの優先順位は「8. 設定ファイル(~/.aws/config)」となるということです。
なのでデフォルトの認証情報がある場合にはそちらが優先されたのですね。
aws loginの認証情報を使えるようにする
デフォルトの認証情報よりaws loginを優先したい場合に次の手法が考えられます。
aws login --profile xxxとプロファイル指定することで明示的に優先順位を上げる「1. コマンドラインオプション(--profile)」の活用
これも悪くないですが、毎回入力するのは手間ですね。毎回profileを入れる代わりに環境変数でprofileを指定することもできますがそれもいまいちです。
ではより簡単な手法は何でしょうか?
少しアプローチは変わりますが、下記選択肢がより良いように思います。
.aws/credentialsを削除する(あるいはファイル内のdefaultのみ削除する)
元々aws loginを利用するメリットの1つはIAM Userのアクセスキーを無くすことができることです。その考えに則る場合、このデフォルトの設定を残さないことも選択肢の1つだと思います。
どう利用したいかに合わせてご検討ください。
やってみた
それでは、それぞれの手法を試してみましょう。
profile指定
以下のようになり、--profileを明示的に指定した場合のみaws loginの認証情報を利用できました。
# プロファイルを指定したaws login
% aws login --profile override
No AWS region has been configured. The AWS region is the geographic location of your AWS resources.
If you have used AWS before and already have resources in your account, specify which region they were created in. If you have not created resources in your account before, you can pick the region closest to you: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html.
You are able to change the region in the CLI at any time with the command "aws configure set region NEW_REGION".
AWS Region [us-east-1]: ap-northeast-1 # リージョンの設定を入れる
Attempting to open your default browser.
If the browser does not open, open the following URL:
[中略]
Updated profile override to use arn:aws:sts::999999999999:assumed-role/login-role/login-role credentials.
Use "--profile override" to use the new credentials, such as "aws sts get-caller-identity --profile override"
# プロファイル無しで動作確認、引き続きデフォルトが優先された
% aws sts get-caller-identity
{
"UserId": "AIDAAAAAAAAAAAAAAAAAA",
"Account": "999999999999",
"Arn": "arn:aws:iam::999999999999:user/default-credentials-user"
}
% aws configure list
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
# プロファイルを指定するとaws loginの認証情報が使えた
% aws sts get-caller-identity --profile override
{
"UserId": "AROAIAAAAAAAAAAAAAAAA:cm-usuda.keisuke",
"Account": "999999999999",
"Arn": "arn:aws:sts::999999999999:assumed-role/login-role/login-role"
}
# TYPEがloginとなる
% aws configure list --profile override
NAME : VALUE : TYPE : LOCATION
profile : override : manual : --profile
access_key : ****************DDDD : login :
secret_key : ****************EEEE : login :
region : ap-northeast-1 : config-file : ~/.aws/config
credentialsの削除
以下のようになりました。
# 中身を空っぽに
% vi .aws/credentials
# 優先順位が変わった
% aws configure list
NAME : VALUE : TYPE : LOCATION
profile : <not set> : None : None
access_key : ****************DDDD : login :
secret_key : ****************EEEE : login :
region : ap-northeast-1 : config-file : ~/.aws/config
# プロファイル無しでaws loginの認証情報に変わった
% aws sts get-caller-identity
{
"UserId": "AROAIAAAAAAAAAAAAAAAA:cm-usuda.keisuke",
"Account": "999999999999",
"Arn": "arn:aws:sts::999999999999:assumed-role/login-role/login-role"
}
まとめ
認証情報の優先順位によって本来思っていたのと違う認証情報を使ってしまうことがあります。
どのように運用したいかイメージしながらaws loginも使っていきましょう。






