📝

AWS CLI と AWS SDK の認証情報の優先順位について

2025/01/03に公開

AWS CLI や AWS SDK で AWS API を実行するには IAM の認証情報が必要ですが、使用される認証情報には優先順位があり、認証情報プロバイダーチェーンと呼ばれています。
AWS SDKs and Tools standardized credential providers - AWS SDKs and Tools

All SDKs have a series of places (or sources) that they check in order to find valid credentials to use to make a request to an AWS service. After valid credentials are found, the search is stopped. This systematic search is called the credential provider chain.

優先順位についてはツール間で共通している順位もあればツールごとに異なる順位もあります。
今回はよく使用されると思われる AWS CLI の認証情報の優先順位について確認してみました。

なお、ツールごとの優先順位については上記ドキュメントをご確認ください。

AWS CLI の認証情報の優先順位

Configuring settings for the AWS CLI - AWS Command Line Interface
AWS CLI の場合は以下の優先順位で認証情報が利用されます。

  1. Command line options
  2. Environment variables
  3. Assume role
  4. Assume role with web identity
  5. Credentials file
  6. Custom process
  7. Container credentials
  8. Amazon EC2 instance profile credentials

よくある事象

EC2 における以下のようなケースでアクセス拒否されるケースがあります。

  • EC2 で aws configure を実行して IAM ユーザーの認証情報を設定
    • IAM ユーザーには EC2 に関する権限のみ付与されている
  • AdministratorAccess を付与した IAM ロールを EC2 にアタッチ

上記設定で s3 ls コマンドなどの EC2 以外の API を実行した場合アクセス拒否となります。
上述の優先順位を確認すると、以下の優先順位であることがわかります。

  1. IAM ユーザーの認証情報 = Credentials file
  2. EC2 にアタッチした IAM ロールの認証情報 = Amazon EC2 instance profile credentials

AdministratorAccess を付与した IAM ロールの優先順位は最も低いため、優先順位が上位である IAM ユーザーの認証情報が使用されることになります。
IAM ユーザーには S3 に関するアクセス権限が付与されていないため、s3 ls コマンドを実行してもアクセス拒否が発生します。

IAM ロールの認証情報を使用したい場合、Credentials file を削除する必要があります。
Credentials file のパスは以下の通りです。
Location of the shared config and credentials files - AWS SDKs and Tools

  • Linux または macOS
    • ~/.aws/config
    • ~/.aws/credentials
  • Windows
    • %USERPROFILE%.aws\config
    • %USERPROFILE%.aws\credentials

上記事象からもわかる通り、優先順位が下位の認証情報を使用するためには上位の認証情報を無効化する必要があります。
Environment variables (環境変数) もよく使用されると思われますので、EC2 にアタッチした IAM ロールの認証情報を使用できていない場合には上位の認証情報の有無を確認してください。

試してみた

上記事象について試してみました。
IAM ユーザーと IAM ロールの権限は以下の通りです。

ec2-role を EC2 にアタッチして EC2 を起動します。
この時点では EC2 内で IAM ユーザーの認証情報を設定していないため、IAM ロールの認証情報が使用されます。
そのため、S3 へのアクセスも可能です。

$ aws s3 ls
2024-12-30 01:07:43 amazon-connect-xxxxxx
2024-11-12 11:49:41 cdk-hnb659fds-assets-0123456789012-ap-northeast-1
2024-11-30 06:54:50 cf-templates-xxx-ap-northeast-1
2024-11-09 10:33:51 config-bucket-0123456789012

続いて EC2 内で aws configure を実行し、IAM ユーザーの認証情報を設定します。

$ aws configure
AWS Access Key ID [None]: xxx
AWS Secret Access Key [None]: xxx
Default region name [None]: ap-northeast-1
Default output format [None]: json

ホームディレクトリ配下に Credentials file が作成されました。
この状態で再度 s3 ls コマンドを実行するとアクセス拒否となります。

$ ls .aws
config  credentials

$ aws s3 ls
An error occurred (AccessDenied) when calling the ListBuckets operation: User: arn:aws:iam::0123456789012:user/ec2-user is not authorized to perform: s3:ListAllMyBuckets because no identity-based policy allows the s3:ListAllMyBuckets action

拒否されている IAM プリンシパルが IAM ユーザーであることから、使用された認証情報が IAM ロールではなく IAM ユーザーの認証情報であることがわかります。
sts get-caller-identity コマンドでも IAM ユーザーの情報が返ってきます。

$ aws sts get-caller-identity
{
    "UserId": "xxx",
    "Account": "0123456789012",
    "Arn": "arn:aws:iam::0123456789012:user/ec2-user"
}

この状態では IAM ロールの認証情報は使用されません。
Credentials file を削除してから再度 s3 ls コマンドを実行すれば IAM ロールの認証情報でアクセスできます。

$ rm -r .aws
$ ls .aws
ls: cannot access '.aws': No such file or directory

$ aws sts get-caller-identity
{
    "UserId": "xxx:i-0812b6693c11e8eb7",
    "Account": "0123456789012",
    "Arn": "arn:aws:sts::0123456789012:assumed-role/ec2-role/i-0812b6693c11e8eb7"
}

$ aws s3 ls
2024-12-30 01:07:43 amazon-connect-xxxxxx
2024-11-12 11:49:41 cdk-hnb659fds-assets-0123456789012-ap-northeast-1
2024-11-30 06:54:50 cf-templates-xxx-ap-northeast-1
2024-11-09 10:33:51 config-bucket-0123456789012

以上より、AWS CLI の認証情報の優先順位通りの挙動であることを確認できました。

まとめ

今回は AWS CLI と AWS SDK の認証情報の優先順位について紹介しました。
どなたかの参考になれば幸いです。

参考資料

Discussion