🔑

aws loginを触ってみた。ログインエラーとトークンの期限切れで詰まった話。

Shogo-B

2025/11/21に公開

 はじめにどうも、馬場です!
11/19に access key の撲滅に有効そうな aws login というコマンドが公開されたので、触ってみて詰まったところや、実運用意識するとどうなりそうか？をメモがてら記事にします。
https://aws.amazon.com/jp/blogs/security/simplified-developer-access-to-aws-with-aws-login/

 詰まりポイントdefaultのプロファイルに注意

→ .aws/credentialsの "[default]" プロファイルにKEY情報などがあるとそちらを優先する挙動をして  tokenの時間切れエラーが起きるので、削除かコメントアウトをする必要がある
権限追加が必要になるケースあり

→ 権限管理が厳しい場合 signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token が含まれておらず、追加する必要があって 通常の手段からだとログインできる のに aws loginからだとログインできない という状態になる。権限を追加しましょう。

 触ってみた
 準備現在のバージョンを確認 : aws --version

aws cliのupdateを使うので、現在の場所を確認: which aws | xargs ls -l
/usr/local/bin/aws -> /usr/local/aws-cli/v2/current/bin/aws
こんなの出てくると思うので、① ”XXX/bin/aws の/bin まで” と ② ”YYY/aws-cli” までをメモる。

↑のケースだと ① "/usr/local/bin" , ②"/usr/local/aws-cli"になる。（後でawsコマンドのオプションで使います。）
あれだったら適当な場所に "cd" して最新のaws cli をダウンロード(下記コマンドはx86前提)

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzipする

unzip awscliv2.zip
アップデートする

sudo ./aws/install --bin-dir {①のパス} --install-dir {②のパス} --update

例)
sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
成功すると
You can now run: /usr/local/bin/aws --version
と出てくるので

aws --version で2.32.0 以上になっていることを確認する（自分がやったときは2.32.1でした）

 aws loginを実行してみるコマンドはシンプルに
aws login
defaultのプロファイルなどでregionを設定していないと最初にリージョンを聞かれるらしい
If you have not set a default Region, the CLI prompts you to specify the AWS Region of your choice (e.g., us-east-2, eu-central-1). The CLI remembers which Region you set once you enter it into this prompt.
https://aws.amazon.com/jp/blogs/security/simplified-developer-access-to-aws-with-aws-login/
コマンドを実行するとデフォルトのブラウザを開こうとするが、WSL2のUbuntuで実行していたので開かずログイン用のURLが表示され、それを開くように言われる

URLを開くと現在の有効なセッションと新しくログインするか？を聞かれる

せっかくなので新しいセッションを選択



IAM Userでログインする方法を選択



いつもの画面に来るのでログイン


 aws login に必要な権限ここでトラブル

なぜかログインできない！！！

→signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token の権限が足りなかったので権限を追加（CloudFormation のYAMLテンプレートだとこんな権限
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - signin:AuthorizeOAuth2Access
              - signin:CreateOAuth2Token
            Resource: "*"
            # MFAを有効化している場合、以下もあるべき
            Condition:
              Bool:
                "aws:MultiFactorAuthPresent": "true"
再チャレンジ→接続成功



cli側も Updated profile default to use ログインユーザーのARN credentials.　と表示されました。

 aws login後にaws cliを試してみるとりあえず接続情報を確認してみる
aws sts get-caller-identity
ここでトラブル

怒られた



.aws/credentialsの "[default]" プロファイルにKEY情報があったり、 export AWS_ACCESS_KEY_IDで環境変数としてアクセスキーなどを設定しているとそちらが優先されるっぽい。
それらを消して、再度 aws loginをしてプロファイルを上書いたところ aws sts get-caller-identity や aws s3 ls が動くようになりました。

 実運用を考えてみるaws loginを前提に運用をする場合、 defaultのプロファイルは常に空の状態にすることで

いちいち エラー発生してからdefault消さなきゃ となるのを防ぐ必要がありそうです。
例えば、以下のような踏み台アカウントを経由して作業用アカウントに接続する運用を取っている場合

aws loginの認証後、aws sts assume-role を実行して返ってきたtokenを

defaultプロファイル や export AWS_ACCESS_KEY_ID ではなく、switch role先の作業用アカウント用プロファイルを用意してそこにtokenを配置し、以降 --profile XXX をつけて操作を行うことで毎回エラーにぶつからずにaws loginを活用した運用ができるのではないか？と思いました。

 最後に統制を意識した運用をしていくと気になってくる ACCESS_KEYはなるべく発行したくないが、必要になってくるケース に対する銀の弾丸になりそうな aws login がリリースされ、今後の運用に関するベストプラクティスが変わりそうできちんと情報を追っていかないといけないなと思うとともに、よりセキュアに運用を行える素晴らしいものがリリースされたので、皆に待ち望まれた機能なのかなと思いました。

今後もこういった機能が出てくるのが楽しみです！