AWS Vaultで発行した一時認証情報でIAM APIが操作できない原因を調べた
こんにちは。クラウド事業本部の桑野です。
皆さんはAWS Vault使っていますか?私は使っています。
以前、以下の記事を投稿しました。
ローカルで開発用に構築したDockerコンテナにAWS Vault経由で安全にIAM権限を付与するという内容なのですが、この中で紹介している手順通りに進めても、IAMの操作ができないというトラブルに遭遇しました。
意外と解決に時間がかかったので、今回はその原因と解決策を共有します。
前提
下記の条件で検証しています。
- OS:macOS Tahoe バージョン 26.2
- チップ:Apple M4
- Docker Client:28.4.0
- Docker Server:28.3.3
- Colima:0.8.4
- docker compose:2.39.3
- AWS Vault:7.2.0
また、冒頭で紹介している記事の手順の4まで進めているものとします。
事象
以下の通り、AWS CLIでIAMユーザーのリストを取得しようとすると、エラーが発生しました。
xxxxxxxxxxx:/# aws iam list-users
An error occurred (InvalidClientTokenId) when calling the ListUsers operation: The security token included in the request is invalid
どうやらセキュリティトークンが無効なようです。
ナンデダ…。
原因
原因はとても単純です。
これはGetSessionTokenAPIを呼び出して取得した一時認証情報がMFAによる追加認証がされていない状態でIAM操作を実行したことによって発生します。
GetSessionTokenを呼び出すときに取得する一時的な認証情報には、次の機能と制限があります。
- フェデレーションのシングルサインオンエンドポイント AWS マネジメントコンソール に認証情報を渡すことで https://signin.aws.amazon.com/federation にアクセスできます。詳細については、「AWS コンソールへのカスタム ID ブローカーアクセスを有効にする」を参照してください。
- 認証情報を使用して IAM または AWS STS API オペレーションを呼び出すことはできません。認証情報を使用してその他の サービスの API オペレーションを呼び出すことはできますAWS。
AWS Vaultは内部の仕組みとしてGetSessionTokenとAssumeRoleを利用しています。
aws-vault uses Amazon's STS service to generate temporary credentials via the GetSessionToken or AssumeRole API calls. These expire in a short period of time, so the risk of leaking credentials is reduced.
今回の使用方法ではGetSessionTokenによって資格情報が払い出されたため、MFAの設定を行っていない場合にIAM操作をしようとするとエラーが発生したわけですね。
コンソールを見に行きました。

登録していませんね。
では、どのように対処していくかを続けて共有します。
対処法
対処方法は2つあります。
- MFAデバイスを登録し、MFA認証するように設定する
- IAM操作が可能な権限を持ったIAMロールを用意し、AssumeRoleで認証する
以下はGetSessionToken、AssumeRole、その他のSTS APIについて表形式で整理されたドキュメントです。
AssumeRoleの場合、MFA認証をしなくてもIAM操作が可能です。
1. MFAデバイスを登録し、MFA認証するように設定する
MFAデバイスを登録し、MFA認証するようにします。

MFAデバイスを登録したら、.aws/configのプロファイルにmfa_serialを追記します。
渡す値は、MFAの識別子です。上の画像で、黒塗りにしている部分です。
[profile terraform-runner]
region=ap-northeast-1
output=json
mfa_serial=arn:aws:iam::xxxxxxxxxx:mfa/xxxxxxxxxxx
ここまで完了したら、再びaws-vault execを実行し、資格情報を発行します。
この際、MFAデバイスによる認証が要求されます。
% aws-vault exec terraform-runner -- docker compose up -d infra
Enter MFA code for arn:aws:iam::xxxxxxxxxxx:mfa/xxxxxxxxxxx:
これでMFAデバイスによる認証を通過した資格情報を次のコマンドに渡すことが可能になります。
もう一度IAMユーザーのリストを取得してみましょう。
xxxxxxxxxxx:/# aws iam list-users
{
"Users": [
{
"Path": "/",
"UserName": "terraform-runner",
"UserId": "xxxxxxxxxxxxxxxxxxxx",
"Arn": "arn:aws:iam::xxxxxxxxxxxx:user/terraform-runner",
"CreateDate": "2025-09-18T02:53:09+00:00"
},
],
...
}
ちゃんと取得できていますね。
2. IAM操作が可能な権限を持ったIAMロールを用意し、AssumeRoleで認証する
以下のようなIAMロールを作成しました。
このロールを引き受けたいと思います。

まず、このロールを引き受けることができるユーザーを信頼関係で定義します。
principalに引き受けてもいいよ〜というIAMユーザーのARNを記述します。

次に、IAMユーザー側では引き受けたいIAMロールに対してsts:AssumeRoleを実行できる許可が必要となります。
以下のようなポリシーを付与します。ResourceにはIAMロールのARNを指定します。

最後に、AWS VaultでGetSessionTokenの代わりに、AssumeRoleを実行するように設定します。
.aws/configを開き、AssumeRoleを実行したいプロファイルに対し、role_arnを指定します。
ここに指定するARNは引き受けるIAMロールのARNです。
[profile terraform-runner]
region=ap-northeast-1
output=json
role_arn=arn:aws:iam::xxxxxxxxxxx:role/terraform-runner
ここまで設定した状態で、aws-vault execを実行し、資格情報を発行します。
もう一度IAMユーザーのリストを取得すると、MFA認証は要求されませんが、ちゃんとエラーなく実行できることが確認できます。
まとめ
いかがだったでしょうか。
AWS VaultはGetSessionTokenやAssumeRoleによってセキュアな認証を実現していました。
以下の2点を押さえていれば、今回のトラブルは簡単に解決できたんだろうなと痛感しています。
- 「どちらの仕組みを使って認証しているのか」という意識
- 「それぞれどのような違いがあるのか」という理解
エラーの解決を通して自分のレベルが上がったと感じることができるので、何かしらうまくいかないことが出てきた場合、それは逆にチャンスと捉えるように意識しています。
本記事がAWS VaultやSTSでIAM操作がうまくいかない人の解決に少しでも貢献できれば幸いです。
最後までご覧いただきありがとうございました。







