AWS CLI の aws login コマンドよりアクセスキー認証が優先された場合の対処法

皆さん aws login コマンドは利用されてますでしょうか。
神アプデだと思い、アクセスキーから早速移行したのですが、意外なところで躓きました。皆さんの参考になれば幸いです。

原因＆対処法まとめ

• AWS CLI では .aws/config よりも.aws/credentials の優先順位が高く設定されているため、先にアクセスキー認証が走る
• ./aws/credencials から該当プロファイルのアクセスキーの記述を削除したり、./aws/credencials 自体をリネームまたは削除することで、aws login で取得した認証情報が参照される

---

以降は aws login を知らない方向けの解説と、実際の検証内容の紹介になります。

aws login とは？

ブラウザベースの認証による AWS CLI の実行を可能にするコマンドです。 aws login を利用することで、

• AWS にサインアップした直後でも AWS CLI を利用できる
• IAM ポリシーや MFA 認証を AWS CLI 利用時にも強制できる
• アクセスキーをローカルに保存する必要がない！

といった利点があります。とっても素敵。

利用条件

AWS CLI のアップデート

aws login は、 AWS CLI のバージョンを 2.32.0 以降からサポートされてます。適宜 AWS CLI のアップデートを行ってください。

IAM ポリシーの確認

aws login は下記のアクションが許可されていない場合、認証に失敗します。

• signin:AuthorizeOAuth2Access
• signin:CreateOAuth2Token

上記アクションは、AWS 管理ポリシー SignInLocalDevelopmentAccess を付与すれば、自分でポリシーを作成することなく権限付与が可能です。

SignInLocalDevelopmentAccess ポリシーの詳細（JSON）

SignInLocalDevelopmentAccess

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "signin:AuthorizeOAuth2Access",
                "signin:CreateOAuth2Token"
            ],
            "Resource": "arn:aws:signin:*:*:oauth2/public-client/*"
        }
    ]
}

aws login の利用方法

初回入力時はリージョンを入力するように求められるため、適宜入力してください。

aws login にも、 --profile オプションの付与ができます。

入力後、ブラウザが立ち上がりAWSへサインインするセッションの選択画面に遷移します。
事前にブラウザ上で AWS マネージメントコンソールへログインしている場合は、画像のように選択肢として表示されます。

「sign into new session」をクリックすると、新しいセッションの追加・リフレッシュを選択できます。

成功すると画像のようにログイン成功画面が表示されます。

以上で AWS CLI の各種コマンドが実行可能になります。

アクセスキーが設定されたプロファイルを aws login で上書きしてみる

ここで少し検証してみましょう。

.aws/credentials にアクセスキーが設定されているプロファイル（今回は test_user ）に対し、aws login を実行してみます。

「test_user」プロファイルに設定されているアクセスキーには、下記のIAMユーザー 「test_user_A」 が紐づいてます。

アカウント ID	IAM ユーザーARN
000000000000	arn:aws:iam::000000000000:user/test_user_A

aws login でログインするIAMユーザーは下記の 「test_user_B」 です。

アカウント ID	IAM ユーザーARN
999999999999	arn:aws:iam::999999999999:user/test_user_B

aws login が完了した後、aws sts get-caller-identity を実行します。するとアクセスキーに紐づく 「test_user_A」 でコマンドを実行していることが分かります。

aws sts get-caller-identity の実行結果

{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "000000000000",
    "Arn": "arn:aws:iam::000000000000:user/test_user_A"
}

さらにアクセスキーを無効化し、再度 aws login を実行します。
その後 aws sts get-caller-identity を実行してみると

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation:
The security token included in the request is invalid.

アクセスキーでの認証が優先された結果、エラーになってしまいました。

原因

調べてみたところ AWS CLI の設定読込の優先順位によって起きる仕様のようです。ドキュメントによると .aws/credentials は .aws/config よりも優先順位が高く設定されているようで、その結果アクセスキーによる認証が先に走ってしまいます。

対処法

./aws/credencials から該当プロファイルのアクセスキーの記述を削除したり、./aws/credencials 自体をリネームまたは削除することで、aws login で取得した認証情報が参照されます。

上記の対応を行うと、aws login でログインしたIAMユーザー「test_user_B」でコマンドを実行できました。

aws sts get-caller-identity の実行結果

{
    "UserId": "XXXXXXXXXXXXXXXXXXXXX",
    "Account": "999999999999",
    "Arn": "arn:aws:iam::999999999999:user/test_user_B"
}

所感

意図しないAWSアカウント・IAMユーザーでコマンドを実行してしまう可能性があるので、既にアクセスキーが設定されているプロファイルから aws login に移行する際は注意しましょう。

特にデフォルトプロファイル(プロファイル指定なし)だと気づきにくいかも。

前述した対処法でアクセスキーを無効化してから aws login を試した後、本移行するのがおすすめです。

補足

ちなみに既に aws login を行ったプロファイルに対して再度 aws login を実行し、前回と別の AWS アカウント・IAM ユーザーを選択しログインしようとすると下記のように注意文言が表示されます。

Profile test_user is already configured to use session arn:aws:iam::000000000000:user/test_user_A. 
Do you want to overwrite it to use arn:aws:iam::999999999999:user/test_user_B instead? (y/n): 

n を入力すればキャンセルできるので、誤って本番用のAWSアカウントにログインしようとしてしまった場合も安心ですね。

参考文献