AWS認証情報を確認！`aws sts get-caller-identity` コマンドの使い方

By /

AWS認証情報を確認！aws sts get-caller-identity コマンドの徹底解説

クラウド環境での作業において、自分が「誰」として操作を行っているのかを正確に把握することは、セキュリティ、権限管理、そしてトラブルシューティングの観点から極めて重要です。AWSでは、様々な方法でAWSリソースにアクセスするための認証情報が提供されています。ルートユーザー、IAMユーザー、IAMロール、フェデレーションユーザーなど、利用シーンに応じた多様なプリンシパル（操作を行う主体）が存在します。

これらの多様な認証情報が存在する中で、「今、このAWS CLIコマンドはどのプリンシパルとして実行されているのか？」を知りたいと思ったことはありませんか？あるいは、プログラムやスクリプトが意図したIAMロールの権限で実行されているかを確認したいと思ったことは？

そんな疑問に答えるための最も簡単で、かつ決定的なコマンドが aws sts get-caller-identity です。

この記事では、aws sts get-caller-identity コマンドについて、その基本的な使い方から、コマンドが返す情報の詳細な意味、様々な認証情報での実行例、応用的な使い方、そしてトラブルシューティングまで、徹底的に解説します。この記事を読み終える頃には、あなたは get-caller-identity コマンドを自在に使いこなし、AWS環境での認証情報の確認と理解に自信を持てるようになっているはずです。

1. はじめに：なぜ認証情報の確認が重要なのか？

AWSのようなクラウドプラットフォームでは、あらゆる操作（EC2インスタンスの起動、S3バケットへのアクセス、Lambda関数のデプロイなど）は、何らかの「プリンシパル」によって、特定の「権限」に基づいて実行されます。

  • セキュリティ: 不正アクセスや意図しない操作を防ぐためには、誰がどのような権限を持っているかを厳密に管理する必要があります。そして、実際に操作を行っている主体が、想定しているプリンシパルであるかを確認することは、セキュリティ対策の第一歩です。
  • 権限管理とトラブルシューティング: ある操作が許可されない場合（Access Deniedエラーなど）、その原因は認証情報に関連する権限不足であることがほとんどです。このとき、「自分はどのプリンシパルとして実行しているのか？」を正確に把握できていれば、問題の切り分けと解決が格段に容易になります。
  • スクリプトと自動化: AWS CLIやSDKを使ったスクリプトや自動化処理では、適切な認証情報が設定されているか、意図した権限で実行されるかを事前に確認することが不可欠です。
  • クロスアカウントアクセス: 異なるAWSアカウント間でリソースにアクセスする場合、どのプリンシパルがどのアカウントのどのロールを引き受けているのかを明確に理解する必要があります。

aws sts get-caller-identity コマンドは、このような状況で「今、実行している環境が、どのような認証情報（誰）でAWSにアクセスしようとしているか」を即座に教えてくれる、非常に強力なツールです。

2. AWS認証情報とは？基本を理解する

get-caller-identity コマンドの詳細に入る前に、AWSの認証情報の種類について簡単に振り返りましょう。これにより、コマンドの出力が示す意味がより深く理解できます。

AWSにおける主な「プリンシパル」とその認証情報は以下の通りです。

  • AWSアカウントのルートユーザー: AWSアカウント作成時に最初に作成されるユーザー。アカウントのすべてのリソースと操作に対して無制限のアクセス権を持ちます。非常に強力なため、日常的な作業には推奨されず、認証情報は厳重に管理されるべきです。認証情報としては、メールアドレスとパスワード、MFA（多要素認証）を使用します。APIアクセス用のアクセスキーペアも生成可能ですが、これも非推奨です。
  • IAMユーザー: AWSアカウント内に作成される個別のユーザー。特定の人物やアプリケーションに割り当てられます。IAMポリシーを使って、きめ細やかな権限管理を行います。認証情報としては、ユーザー名とパスワード（コンソールアクセス用）、アクセスキーIDとシークレットアクセスキー（CLI/SDKアクセス用）を使用します。MFAも設定可能です。
  • IAMロール: IAMユーザーとは異なり、特定の人物に関連付けられず、権限の集合体として定義されます。アプリケーション（EC2インスタンス、Lambda関数など）やAWSサービス、あるいは他のAWSアカウントのユーザーやサービスに「引き受けられる（Assume）」ことを想定しています。ロールを引き受けると、一時的な認証情報（アクセスキーID、シークレットアクセスキー、セッショントークン）が発行され、その認証情報を使って操作を行います。この一時的な認証情報こそが、ロールの権限で操作を実行するための鍵となります。
  • フェデレーションユーザー: 企業ディレクトリ（Active Directoryなど）やSAML、OpenID ConnectなどのIDプロバイダーと連携して、既存のユーザーIDでAWSにアクセスできるようにする仕組みです。フェデレーションにより取得される認証情報も、一時的な認証情報です。

これらの認証情報のうち、AWS CLIやSDKからのAPIアクセスに使用されるのは、主にアクセスキーペア（IAMユーザーの場合）または一時的な認証情報（IAMロール、フェデレーションユーザー、ルートユーザーのAPIアクセス用キーなど）です。

3. AWS Security Token Service (STS) とは？

aws sts get-caller-identity コマンドの sts は、AWS Security Token Service（STS）を指します。STSは、一時的な限定的な権限を持つ認証情報を作成および提供するAWSのサービスです。

STSの主な役割は以下の通りです。

  • 一時的な認証情報の発行: IAMロールを引き受ける (AssumeRole)、フェデレーションユーザーのために認証情報を取得する (GetFederationToken)、あるいは一時的なユーザー認証情報を作成する (GetSessionToken) といったAPIを通じて、有効期限付きの一時的な認証情報（アクセスキーID、シークレットアクセスキー、セッショントークン）を発行します。
  • クロスアカウントアクセス: IAMロールとSTSを組み合わせることで、別のアカウントのユーザーやサービスが、自アカウントのリソースに一時的にアクセスできるようになります。
  • ID連携: 企業ディレクトリやウェブIDプロバイダーとの連携をサポートします。

get-caller-identity は、このSTSが提供するAPIの一つです。このAPIは、現在APIコールを行っている認証情報が、STSによって発行された一時的なものであるかどうかにかかわらず、その認証情報がどのプリンシパル（IAMユーザー、IAMロール、ルートユーザーなど）に紐づいているかを問い合わせるために使用されます。STSはグローバルサービスであり、特定のリージョンに依存しません。

4. aws sts get-caller-identity コマンドの基本

aws sts get-caller-identity コマンドは、現在AWS CLIが使用している認証情報が、どのAWSアカウントの、どのプリンシパル（ユーザー、ロール、ルートユーザー）に関連付けられているかを確認するために使用します。

このコマンドを実行するには、まずAWS CLIがインストールされ、何らかの認証情報（環境変数、設定ファイル、IAMロールなど）が設定されている必要があります。

4.1. AWS CLIのインストールと設定（簡単ガイド）

まだAWS CLIがインストールされていない場合は、以下のAWS公式ドキュメントを参照してインストールしてください。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html

インストール後、aws configure コマンドを使って認証情報を設定するのが一般的です。

bash
aws configure

このコマンドを実行すると、AWSアクセスキーID、シークレットアクセスキー、デフォルトのリージョン、デフォルトの出力形式を入力するよう求められます。

AWS Access Key ID [None]: YOUR_ACCESS_KEY_ID
AWS Secret Access Key [None]: YOUR_SECRET_ACCESS_KEY
Default region name [None]: your-region
Default output format [None]: json

これらの情報は、~/.aws/credentials ファイルや ~/.aws/config ファイルに保存されます。AWS CLIは、これらのファイルや環境変数、EC2インスタンスメタデータなど、いくつかの場所から認証情報を自動的に検索して使用します。

4.2. 基本的な使い方

aws sts get-caller-identity コマンドの最も基本的な使い方は非常にシンプルです。ターミナルを開いて、以下のコマンドを実行するだけです。

bash
aws sts get-caller-identity

インターネット接続があり、AWS CLIが何らかの有効な認証情報を見つけることができれば、コマンドは成功し、現在使用している認証情報に関する情報がJSON形式で出力されます。

4.3. コマンドを実行するための権限

sts:GetCallerIdentity アクションは、AWSアカウントに関する情報（アカウントID、プリンシパルのARNなど）を返しますが、これは非常に安全なアクションと見なされています。なぜなら、このアクションは認証情報の正当性を確認し、その認証情報が「誰」のものであるかを示すだけで、アカウント内のリソースに対する操作（読み取りや書き込み）を一切行わないからです。

そのため、特別な理由がない限り、IAMポリシーで sts:GetCaller-Identity アクションを明示的に拒否する必要はありません。通常、デフォルトの権限設定では、IAMユーザーやIAMロールは sts:GetCallerIdentity アクションを実行する権限を持っています。もしこのコマンドの実行が Access Denied エラーで失敗する場合は、お使いのIAMポリシーがこのアクションを意図せず拒否している可能性があります。

json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetCallerIdentity",
"Resource": "*"
}
]
}

上記のようなポリシーは、特定のプリンシパルに対して get-caller-identity の実行を許可する最もシンプルな例です。多くの場合、このアクションはワイルドカード * で許可されていてもセキュリティ上の問題は少ないです。

5. get-caller-identity コマンドの出力詳解

aws sts get-caller-identity コマンドは、実行に使用された認証情報に関連付けられたプリンシパルに関する情報を、JSON形式で返します。出力には通常、以下の3つのフィールドが含まれます。

  • UserId
  • Account
  • Arn

これらのフィールドは、現在あなたがAWSにアクセスしている主体が「誰」であり、「どのアカウント」の「どのリソース（プリンシパル）」であるかを明確に示します。それぞれのフィールドについて詳しく見ていきましょう。

5.1. UserId フィールド

UserId フィールドは、AWSアカウント内でプリンシパルを一意に識別する内部的なIDです。このIDは、プリンシパルのタイプによって特定のプレフィックスを持ちます。

  • IAMユーザー: AIDA から始まる16桁の英数字の文字列。例: AIDAJQABLZS4A3B6XXXXX
  • IAMロール: AROA から始まる16桁の英数字の文字列。例: AROAIQP3P57J47G6XXXXX
  • ルートユーザー: AWSアカウントの12桁の数字（Account フィールドと同じ値）。
  • 引き受けられたIAMロール（一時的な認証情報）: AROAI から始まるIDと、それに続くコロン : 、そしてセッション名（RoleSessionName）をURLエンコードした文字列。例: AROAIQP3P57J47G6XXXXX:MySessionName
  • フェデレーションユーザー（一時的な認証情報）: AIDA から始まるID（元のIAMユーザーのID）と、それに続くコロン : 、そしてセッション名（FederatedUserSessionName）をURLエンコードした文字列。例: AIDAJQABLZS4A3B6XXXXX:MyFederatedUser
  • GetSessionToken による一時的な認証情報: 元のプリンシパル（IAMユーザーまたはルートユーザー）の UserId と、それに続くコロン : 、そしてセッション名（SessionName）をURLエンコードした文字列。例（IAMユーザーの場合）: AIDAJQABLZS4A3B6XXXXX:MyTemporarySession

UserId は、AWSの内部的な識別子であり、ユーザーフレンドリーな名前（IAMユーザー名やロール名）ではありません。トラブルシューティングやログ分析で特定の操作を行った主体を追跡する際に使用されることがあります。特に、一時的な認証情報の場合、UserId にはセッション名が含まれるため、どの「セッション」が操作を行ったかを識別するのに役立ちます。

5.2. Account フィールド

Account フィールドは、現在アクセスしているAWSアカウントの12桁の数値IDです。これは、AWSアカウントを一意に識別するグローバルなIDです。

例: 123456789012

このフィールドは、コマンドが実行されているAWSアカウントが何であるかを即座に確認するのに役立ちます。特に複数のAWSアカウントを管理している場合や、クロスアカウントアクセスをテストしている場合に、自分が正しいアカウントにアクセスしていることを確認するために頻繁に使用されます。

ルートユーザーとして実行した場合の UserId は、この Account フィールドの値と同じになります。

5.3. Arn フィールド

Arn (Amazon Resource Name) フィールドは、AWSリソースを一意に識別するための標準的な命名規約です。get-caller-identity コマンドの出力における Arn は、現在アクセスしている「プリンシパル」のARNを示します。

ARNの一般的な構造は以下の通りです。

arn:partition:service:region:account-id:resource-type/resource-id

get-caller-identity の出力における Arn の形式は、プリンシパルのタイプによって異なります。

  • IAMユーザー: arn:aws:iam::account-id:user/user-name
    例: arn:aws:iam::123456789012:user/MyIAMUser
    partition は通常 aws、service は iam、region はIAMがグローバルサービスであるため空 (: の後に account-id が続く)、account-id は12桁のアカウントID、resource-type/resource-id は user/ にユーザー名が続きます。
  • IAMロール: arn:aws:iam::account-id:role/role-name
    例: arn:aws:iam::123456789012:role/MyIAMRole
    形式はIAMユーザーと似ていますが、resource-type が role/ になります。
  • ルートユーザー: arn:aws:iam::account-id:root
    例: arn:aws:iam::123456789012:root
    resource-type/resource-id が root になります。
  • 引き受けられたIAMロール（一時的な認証情報）: arn:aws:sts::account-id:assumed-role/role-name/role-session-name
    例: arn:aws:sts::123456789012:assumed-role/MyIAMRole/MySessionName
    重要な点として、service が sts になります。resource-type は assumed-role となり、その後ろに元のロール名と、そのロールを引き受けた際につけられたセッション名が続きます。この形式は、その操作が一時的な認証情報によって行われたことを示唆します。
  • フェデレーションユーザー（一時的な認証情報）: arn:aws:sts::account-id:federated-user/user-name
    例: arn:aws:sts::123456789012:federated-user/MyFederatedUser
    service は sts、resource-type は federated-user となり、その後にフェデレーションユーザー名（セッション名）が続きます。
  • GetSessionToken による一時的な認証情報: arn:aws:sts::account-id:federated-user/session-name (IAMユーザーの場合) または arn:aws:sts::account-id:root (ルートユーザーの場合)
    正確には、GetSessionToken の場合は、arn:aws:sts::account-id:federated-user/session-name 形式（ユーザー名部分がセッション名になる）が一般的です。ルートユーザーの場合は arn:aws:iam::account-id:root となる場合もありますが、一時的な認証情報であることを示すためにセッション名を含む federated-user 形式になることもあります。混乱を避けるため、一時的な認証情報は service: sts となり、assumed-role または federated-user が含まれる、と覚えておくと良いでしょう。

Arn フィールドは、どの具体的なプリンシパル（IAMユーザー名、IAMロール名、特定のセッション）としてコマンドが実行されたかを識別する最も直接的な情報です。特に一時的な認証情報の場合、ARNに含まれるセッション名は、誰が、いつ、どのような目的でその一時的な認証情報を取得したのかを追跡する上で非常に役立ちます。

6. 様々な認証情報での get-caller-identity 出力例

ここからは、実際の様々なシナリオで aws sts get-caller-identity コマンドを実行した場合の出力例と、その意味について詳しく見ていきましょう。

6.1. IAMユーザーとして実行した場合

AWS CLIが、アクセスキーIDとシークレットアクセスキーを使って設定されたIAMユーザーの認証情報を使用している場合。

シナリオ: MyIAMUser というIAMユーザーが、AWS CLIを設定し、コマンドを実行。

コマンド:
bash
aws sts get-caller-identity

出力例:
json
{
"UserId": "AIDAJQABLZS4A3B6XXXXX",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/MyIAMUser"
}

解説:
* UserId: AIDA で始まるIDは、これがIAMユーザーであることを示します。
* Account: アクセスしているAWSアカウントのIDです。
* Arn: arn:aws:iam::account-id:user/user-name という形式で、具体的なIAMユーザー名 (MyIAMUser) が含まれています。

この出力から、現在使用している認証情報が、アカウント 123456789012 のIAMユーザー MyIAMUser のものであることが分かります。

6.2. IAMロールを引き受けて (AssumeRole) 実行した場合

IAMユーザーなどが sts:AssumeRole APIを呼び出して一時的な認証情報を取得し、その認証情報を使ってAWS CLIコマンドを実行している場合。

シナリオ: MyIAMUser が、別アカウント（987654321098）の AnotherAccountRole というロールを引き受け、そのロールの権限でコマンドを実行。セッション名として CrossAccountSession を指定。

コマンド:
まず、sts:AssumeRole で一時的な認証情報を取得します。これは通常、スクリプト内で行われるか、環境変数に一時的に設定されます。
“`bash

例: AssumeRole を実行し、一時的な認証情報を環境変数に設定

temp_credentials=$(aws sts assume-role –role-arn “arn:aws:iam::987654321098:role/AnotherAccountRole” –role-session-name “CrossAccountSession” –output json)
export AWS_ACCESS_KEY_ID=$(echo $temp_credentials | jq -r ‘.Credentials.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(echo $temp_credentials | jq -r ‘.Credentials.SecretAccessKey’)
export AWS_SESSION_TOKEN=$(echo $temp_credentials | jq -r ‘.Credentials.SessionToken’)

その後、get-caller-identity を実行

aws sts get-caller-identity
``
*注意:jq` はJSON処理ツールです。インストールされていない場合は、他の方法でJSONから値を取り出す必要があります。*

出力例:
json
{
"UserId": "AROAIQP3P57J47G6XXXXX:CrossAccountSession",
"Account": "987654321098",
"Arn": "arn:aws:sts::987654321098:assumed-role/AnotherAccountRole/CrossAccountSession"
}

解説:
* UserId: AROA で始まるIDにコロン : とセッション名 (CrossAccountSession) が続いています。これは、一時的な認証情報であり、元のプリンシパルがIAMロールであることを示します。セッション名は、一時的な認証情報を作成する際に指定したものです。
* Account: ロールが存在するアカウント（引き受けた側のアカウント）のIDです。コマンドは、このアカウントの権限で実行されています。
* Arn: arn:aws:sts::account-id:assumed-role/role-name/session-name という形式です。サービスは sts となり、assumed-role というタイプに、元のロール名 (AnotherAccountRole) とセッション名 (CrossAccountSession) が含まれます。

この出力は、コマンドがアカウント 987654321098 の AnotherAccountRole というロールの権限を、CrossAccountSession という名前のセッションで引き受けて実行されていることを明確に示します。この ARN を見れば、一時的な認証情報であることが一目で分かります。

6.3. EC2インスタンスにアタッチされたIAMロールから実行した場合

EC2インスタンス起動時にIAMロールをアタッチし、そのインスタンス内で実行されるアプリケーションやスクリプトが、インスタンスメタデータサービス経由で一時的な認証情報を自動的に取得してAWS APIを呼び出す場合。

シナリオ: MyEC2InstanceRole というIAMロールがアタッチされたEC2インスタンス内で、AWS CLIコマンドを実行。

コマンド:
EC2インスタンス内で以下のコマンドを実行。AWS CLIは自動的にメタデータサービスから認証情報を取得します。
bash
aws sts get-caller-identity

出力例:
json
{
"UserId": "AROAIQP3P57J47G6XXXXX:i-0abcdef1234567890",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/MyEC2InstanceRole/i-0abcdef1234567890"
}

解説:
* UserId: AROA で始まるIDに、通常はインスタンスID（例: i-0abcdef1234567890）を含むセッション名が続きます。これは、EC2インスタンスメタデータサービスが一時的な認証情報を発行する際に、デフォルトでインスタンスIDをセッション名に使用するためです。
* Account: EC2インスタンスが存在するアカウントのIDです。
* Arn: arn:aws:sts::account-id:assumed-role/role-name/session-name という形式で、アタッチされているIAMロール名 (MyEC2InstanceRole) とインスタンスIDを含むセッション名が表示されます。

この出力は、コマンドがアカウント 123456789012 のEC2インスタンス i-0abcdef1234567890 にアタッチされた MyEC2InstanceRole というロールの権限で実行されていることを示します。これは、EC2インスタンス上のアプリケーションが期待通りの権限で動作しているかを確認する際に非常に便利です。

6.4. AWS Lambda関数から実行した場合

AWS Lambda関数にIAMロールを設定し、そのLambda関数がそのロールの権限で他のAWSサービスを呼び出す場合。

シナリオ: MyLambdaFunctionRole というIAMロールで実行されるLambda関数内で、AWS SDKやAWS CLIを使ってコマンドを実行。

コマンド:
Lambda関数のコード内でAWS SDKのEquivalent (例: Python boto3 の sts.get_caller_identity()) を呼び出すか、ランタイム環境からAWS CLIコマンドを実行します。
“`python

Python Lambda function code (boto3)

import boto3

sts = boto3.client(‘sts’)

def lambda_handler(event, context):
try:
identity = sts.get_caller_identity()
print(f”Caller Identity: {identity}”)
# … rest of your function logic
except Exception as e:
print(f”Error getting caller identity: {e}”)
# … error handling
``
Lambda実行ログに出力されるidentity` の内容。

出力例:
json
{
"UserId": "AROAIQP3P57J47G6XXXXX:MyLambdaFunctionName",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/MyLambdaFunctionRole/MyLambdaFunctionName"
}

解説:
* UserId: AROA で始まるIDに、通常はLambda関数名（例: MyLambdaFunctionName）を含むセッション名が続きます。
* Account: Lambda関数がデプロイされているアカウントのIDです。
* Arn: arn:aws:sts::account-id:assumed-role/role-name/session-name という形式で、設定されたIAMロール名 (MyLambdaFunctionRole) とLambda関数名を含むセッション名が表示されます。

この出力は、Lambda関数がアカウント 123456789012 の MyLambdaFunctionRole というロールの権限で実行されていることを示します。Lambda関数が他のサービスにアクセスできないなどの問題が発生した場合、この出力で期待したロールが使用されているかを確認することが、トラブルシューティングの第一歩となります。

6.5. ルートユーザーとして実行した場合（非推奨）

AWSアカウントのルートユーザーのアクセスキーペアを使用してAWS CLIを設定し、コマンドを実行した場合。これは日常的な作業では推奨されません。

シナリオ: ルートユーザーのアクセスキーペアを使ってAWS CLIを設定し、コマンドを実行。

コマンド:
bash
aws sts get-caller-identity

出力例:
json
{
"UserId": "123456789012",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:root"
}

解説:
* UserId: アカウントIDと同じ12桁の数字になります。これはルートユーザーであることを示す特徴の一つです。
* Account: アクセスしているAWSアカウントのIDです。
* Arn: arn:aws:iam::account-id:root という形式で、ルートユーザーであることが明確に示されます。

この出力を見たら、すぐにルートユーザーのアクセスキーの使用をやめ、無効化または削除することを強く推奨します。 日常的な作業は必ずIAMユーザーまたはIAMロールを使用してください。

6.6. GetSessionToken で取得した一時的な認証情報として実行した場合

ルートユーザーまたはIAMユーザーが sts:GetSessionToken APIを呼び出して、自身の一時的な認証情報を取得し、それを使用している場合。これは通常、MFAを要求されるAPI操作を行う前に、MFAコードを使って一時的な認証情報を取得するシナリオで利用されます。

シナリオ: MFAが有効なIAMユーザー MyMFAUser が、MFAコードを使って GetSessionToken で一時認証情報を取得し、その認証情報を使ってコマンドを実行。セッション名を MFASession と指定。

コマンド:
まず、sts:GetSessionToken で一時認証情報を取得し、環境変数に設定します。
“`bash

例: GetSessionToken を実行し、一時的な認証情報を環境変数に設定

MFAデバイスのARNと現在のMFAコードが必要

mfa_device_arn=”arn:aws:iam::123456789012:mfa/MyMFAUser”
mfa_code=”123456″ # 例: 実際にはMFAデバイスに表示されるコード

temp_credentials=$(aws sts get-session-token –serial-number $mfa_device_arn –token-code $mfa_code –duration-seconds 3600 –output json)
export AWS_ACCESS_KEY_ID=$(echo $temp_credentials | jq -r ‘.Credentials.AccessKeyId’)
export AWS_SECRET_ACCESS_KEY=$(echo $temp_credentials | jq -r ‘.Credentials.SecretAccessKey’)
export AWS_SESSION_TOKEN=$(echo $temp_credentials | jq -r ‘.Credentials.SessionToken’)

その後、get-caller-identity を実行

aws sts get-caller-identity
“`

出力例:
json
{
"UserId": "AIDAJQABLZS4A3B6XXXXX:MFASession",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:federated-user/MFASession"
}

解説:
* UserId: 元のIAMユーザーの UserId にコロン : とセッション名 (MFASession) が続いています。これは、元のプリンシパルがIAMユーザーであり、一時的な認証情報を使用していることを示します。
* Account: 元のIAMユーザーが存在するアカウントのIDです。
* Arn: arn:aws:sts::account-id:federated-user/session-name という形式になることが多いです。サービスは sts となり、federated-user というタイプに、セッション名 (MFASession) が含まれます。これは、元のIAMユーザーやルートユーザーから派生した一時的な認証情報であることを示します。

この出力は、コマンドがアカウント 123456789012 のIAMユーザー AIDAJQABLZS4A3B6XXXXX から GetSessionToken で取得された一時的な認証情報（セッション名 MFASession）で実行されていることを示します。これは、MFAが必要な操作を行う前に認証情報が正しく取得できたかを確認する際に役立ちます。

6.7. AWS SSO (IAM Identity Center) の一時的な認証情報として実行した場合

AWS IAM Identity Center (旧 AWS SSO) を利用してAWSアカウントにアクセスし、CLI/SDKアクセスのために取得した一時的な認証情報を使用している場合。

シナリオ: IAM Identity Center から払い出された一時的な認証情報を使ってAWS CLIを設定し、コマンドを実行。

コマンド:
IAM Identity Center 経由でCLIを設定すると、通常は ~/.aws/config にプロファイルが作成され、そのプロファイルを指定してコマンドを実行します。
bash
aws sts get-caller-identity --profile sso-profile-name

出力例:
json
{
"UserId": "AROAIQP3P57J47G6XXXXX:[email protected]",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_MyPermissionSet_abcdefgh/[email protected]"
}

解説:
* UserId: AROA で始まるIDにコロン : とセッション名が続きます。IAM Identity Center の場合、セッション名には連携したユーザー名（またはメールアドレス）やシステムが生成した一意のIDが含まれることが多いです。これは一時的な認証情報であることを示します。
* Account: アクセスしているAWSアカウントのIDです。IAM Identity Center は通常、引き受けたロール（パーミッションセット）に関連付けられているアカウントのIDを表示します。
* Arn: arn:aws:sts::account-id:assumed-role/role-name/session-name という形式になります。role-name 部分は、IAM Identity Center で設定した「パーミッションセット」に関連付けられた内部的なロール名（通常は AWSReservedSSO_PermissionSetName_... の形式）となり、セッション名が含まれます。サービスは sts となり、assumed-role タイプであることが示されます。

この出力は、コマンドがアカウント 123456789012 に対して、IAM Identity Center 経由で払い出された一時的な認証情報（特定のロールとセッション名）で実行されていることを示します。これにより、どのIDセンターユーザーが、どのパーミッションセット（ロール）を使ってアクセスしているかを確認できます。

これらの例から分かるように、get-caller-identity コマンドの出力、特に UserId と Arn の形式は、現在使用している認証情報がIAMユーザー、IAMロール、ルートユーザーのいずれであるか、そしてそれが一時的な認証情報であるか、一時的であればどのセッションで実行されているか、といった詳細な情報を教えてくれます。ARNの形式を理解することが、出力の意味を正確に解釈する鍵となります。

7. get-caller-identity の応用的な使い方

aws sts get-caller-identity コマンドは、単に実行するだけでなく、AWS CLIの標準的な機能と組み合わせて、より便利に使うことができます。

7.1. 特定のフィールドだけを取得 (--query)

AWS CLIは、JMESPathというクエリ言語を使ってJSON出力をフィルタリングしたり、整形したりする --query オプションをサポートしています。get-caller-identity の出力から特定のフィールドだけを取得したい場合に便利です。

  • UserId だけを取得:
    bash
    aws sts get-caller-identity --query UserId --output text
    --output text を指定することで、引用符や余計なJSON構造なしに値だけが出力されます。
    出力例: AIDAJQABLZS4A3B6XXXXX

  • Account ID だけを取得:
    bash
    aws sts get-caller-identity --query Account --output text
    出力例: 123456789012

  • Arn だけを取得:
    bash
    aws sts get-caller-identity --query Arn --output text
    出力例: arn:aws:iam::123456789012:user/MyIAMUser

これらのコマンドは、シェルスクリプトなどで現在のアカウントIDやプリンシパルARNを取得し、それを後続の処理で使用する場合に非常に役立ちます。例えば、現在のアカウントIDを取得して変数に格納するようなことができます。

bash
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "Current Account ID: $AWS_ACCOUNT_ID"

7.2. 出力形式の変更 (--output)

デフォルトの出力形式は json ですが、--output オプションを使って text や table など、他の形式で出力することも可能です。

  • Text 形式:
    bash
    aws sts get-caller-identity --output text
    出力例:
    USERID ACCOUNT ARN
    AIDAJQABLZS4A3B6XXXXX 123456789012 arn:aws:iam::123456789012:user/MyIAMUser
    これは、--query オプションを使わずにシンプルなテキスト出力が欲しい場合に便利です。

  • Table 形式:
    bash
    aws sts get-caller-identity --output table
    出力例:
    -------------------------------------------------------------
    | GetCallerIdentityResponse |
    +-----------------------+--------------+--------------------+
    | Arn | Account | UserId |
    +-----------------------+--------------+--------------------+
    | arn:aws:iam::... | 123456789012 | AIDAJQABLZS4... |
    +-----------------------+--------------+--------------------+
    これは、人間が読みやすい表形式で情報を確認したい場合に便利ですが、スクリプトでの利用には向きません。

7.3. プロファイル指定 (--profile)

複数のAWS認証情報プロファイルが設定されている場合、--profile オプションを使って、特定のプロファイルに関連付けられた認証情報でコマンドを実行できます。

シナリオ: ~/.aws/credentials または ~/.aws/config に dev と prod というプロファイルが設定されている。dev プロファイルで認証情報を確認したい。

コマンド:
bash
aws sts get-caller-identity --profile dev

このコマンドは、デフォルトのプロファイルではなく、明示的に指定した dev プロファイルの設定を使って認証情報を取得し、その認証情報で get-caller-identity APIを呼び出します。これにより、どのプロファイルがどのプリンシパルに紐づいているかを確認できます。

--profile オプションは、複数の環境やアカウントを管理している場合に、誤った環境で作業するのを防ぐために非常に重要です。

7.4. リージョン指定 (--region)

aws sts get-caller-identity 自体はグローバルサービス（リージョンに関係なく同じエンドポイント）なので、厳密には get-caller-identity コマンド自体にリージョンを指定する必要はありません。しかし、AWS CLIはデフォルトで設定されているリージョンを使用しようとします。--region オプションを指定してもエラーにはなりませんが、出力内容に影響はありません。

ただし、AWS CLIの動作としては、認証情報の解決はリージョン設定よりも優先されるため、--region は通常、get-caller-identity の実行そのものには不要です。他のリージョン依存のコマンド（例: aws ec2 describe-instances）を実行する際には重要になります。

8. get-caller-identity が役立つシナリオ

aws sts get-caller-identity コマンドは、日常的なAWS運用から高度なトラブルシューティングまで、様々な場面で役立ちます。

  • 作業環境の確認: 現在、AWS CLIがどのAWSアカウントに、どのプリンシパル（ユーザー、ロール）としてアクセスしようとしているのかを素早く確認したいとき。特に複数のAWSアカウントやプロファイルを切り替えながら作業している場合に、意図しないアカウント/プリンシパルで操作してしまうリスクを軽減できます。
  • IAM権限のトラブルシューティング: ある操作が権限不足で失敗した場合、その原因を切り分ける第一歩として、まずは get-caller-identity を実行し、自分が「誰」として操作を行っているのかを確認します。想定していたプリンシパルと異なる場合は、認証情報の設定に問題がある可能性があります。想定通りのプリンシパルである場合は、そのプリンシパルに付与されているIAMポリシーを確認することで、具体的な権限不足箇所を特定しやすくなります。
  • スクリプトやアプリケーションのデバッグ: EC2インスタンス、Lambda関数、ECS/EKSタスクなどで実行されるスクリプトやアプリケーションが、期待通りのIAMロールの権限で動作しているかを確認したい場合。スクリプトの実行開始直後や、権限関連のエラー発生時に get-caller-identity の出力をログに出力することで、問題分析に役立ちます。
  • クロスアカウントアクセスの確認: あるアカウントから別のアカウントのロールを引き受けて作業している場合に、コマンドが正しく引き受けたロールの権限で実行されているかを確認します。Arn フィールドに引き受けたロール名とセッション名が含まれていることを確認します。
  • 一時的な認証情報の有効性確認: STSから取得した一時的な認証情報（アクセスキー、シークレットキー、セッショントークン）が正しく設定されているか、まだ有効期限内であるかを確認したい場合。（ただし、get-caller-identity 自体は認証情報が有効であれば成功するので、有効期限が切れている場合は認証情報のエラーになります。有効期限そのものを確認するには、一時認証情報に含まれる Expiration タイムスタンプを確認する必要があります。）
  • AWS CloudShell/CodeBuildなどの環境: AWS CloudShellやCodeBuildなどのAWSマネージドサービス環境でコマンドを実行する場合、これらのサービスは内部的にIAMロールを使用して権限を管理しています。get-caller-identity を実行することで、これらのサービスがどのIAMロールとして動作しているのかを確認できます。

9. トラブルシューティング

aws sts get-caller-identity コマンドの実行中に発生する可能性のある一般的な問題とその対処法です。

  • Unable to locate credentials または同様のエラー: AWS CLIが有効な認証情報を見つけられなかった場合に発生します。

    • AWS CLIがインストールされ、PATHが通っているか確認します。
    • aws configure を実行して認証情報を設定したか確認します。
    • 環境変数（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN）に認証情報が設定されていないか確認します。環境変数は設定ファイルよりも優先されます。
    • ~/.aws/credentials および ~/.aws/config ファイルが存在し、適切な認証情報（またはプロファイル設定）が含まれているか確認します。
    • --profile オプションを使用している場合は、指定したプロファイル名が設定ファイルに存在するか確認します。
    • EC2インスタンス上などで実行している場合は、インスタンスにIAMロールがアタッチされており、メタデータサービスにアクセス可能か確認します。
    • IAM Identity Center (SSO) を利用している場合は、aws configure sso で設定が完了しており、セッションが有効か確認します。aws sso login が必要かもしれません。
    • aws configure list コマンドを実行して、AWS CLIが現在どの認証情報源を認識しているかを確認します。

  • An error occurred (AccessDenied) when calling the GetCallerIdentity operation: コマンドを実行しようとしたプリンシパルに sts:GetCallerIdentity アクションを実行する権限がない場合に発生します。

    • 現在使用している認証情報に関連付けられたIAMユーザーまたはIAMロールに付与されているIAMポリシーを確認します。
    • そのポリシーに sts:GetCallerIdentity アクションを許可するステートメントが含まれているか確認します。
    • Effect が Deny となっているステートメントで、明示的に sts:GetCallerIdentity が拒否されていないか確認します。明示的な拒否は許可よりも優先されます。
    • 通常、このアクションは安全なので、該当プリンシパルに対するポリシーで Action: "sts:GetCallerIdentity", Effect: "Allow" を追加することで解決できます。

  • 出力される情報が期待と異なる: 例えば、IAMユーザーとして実行しているつもりがルートユーザーと表示される、別のアカウントが表示される、別のロールが表示されるなど。

    • AWS CLIがどの認証情報を使用しているかを再度確認します。環境変数、credentials ファイル、config ファイル、インスタンスメタデータサービス、IAM Identity Center など、AWS CLIは複数の場所から認証情報を自動的に検索し、特定の優先順位で使用します。意図しない場所の認証情報が優先されている可能性があります。
    • aws configure list コマンドを実行して、どのソースから認証情報がロードされているかを確認します。
    • AWS_PROFILE 環境変数が設定されていないか確認します。これが設定されていると、~/.aws/config の指定されたプロファイルが優先されます。
    • AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN といった環境変数が設定されている場合、これらが最優先されます。これらの環境変数が意図せず設定されていないか確認します。

10. 関連コマンド

get-caller-identity と組み合わせて使用すると便利なAWS CLIコマンドをいくつか紹介します。

  • aws configure list: 現在のAWS CLI設定（プロファイル名、リージョン、出力形式、認証情報源など）を表示します。どの認証情報が使われているかを推測するのに非常に役立ちます。
    bash
    aws configure list

  • aws iam list-users / aws iam list-roles: AWSアカウント内のIAMユーザーやIAMロールの一覧を表示します。（これらのコマンドを実行するには、実行しているプリンシパルに適切なIAM権限が必要です。例えば、iam:ListUsers や iam:ListRoles。）
    bash
    aws iam list-users
    aws iam list-roles

  • aws iam get-user / aws iam get-role: 特定のIAMユーザーまたはIAMロールの詳細情報を表示します。（これらのコマンドを実行するには、適切な権限が必要です。）
    bash
    aws iam get-user --user-name MyIAMUser
    aws iam get-role --role-name MyIAMRole

  • aws iam list-user-policies / aws iam list-role-policies / aws iam list-attached-user-policies / aws iam list-attached-role-policies: IAMユーザーやロールに直接アタッチされているインラインポリシーやマネージドポリシーの一覧を表示します。（権限が必要。）

  • aws sts assume-role: 別のIAMロールを引き受けて一時的な認証情報を取得するコマンドです。get-caller-identity の出力形式（サービスがsts、assumed-role タイプを含むARN）が、このコマンドの実行結果であることを理解する上で重要です。

これらの関連コマンドと get-caller-identity を組み合わせることで、AWSアカウントのIAM設定や認証情報の流れをより深く理解し、トラブルシューティングを効果的に行うことができます。

11. セキュリティ上の考慮事項

aws sts get-caller-identity コマンドは、認証情報そのもの（アクセスキーやシークレットキー）を出力するわけではないため、通常は実行してもセキュリティリスクは低いと考えられます。しかし、出力される情報（アカウントID、ARN、セッション名など）は、お使いのAWS環境に関する情報です。

  • 出力情報の取り扱い: get-caller-identity の出力（特にアカウントIDやARN）は、完全に公開しても問題ない機密情報ではありません。不用意に公開された場合、攻撃者にアカウント構造に関するヒントを与える可能性があります。ログやトラブルシューティング情報を共有する際は、これらの情報が含まれていないか、あるいは必要最小限に留めるように注意してください。
  • sts:GetCallerIdentity 権限: 前述の通り、このアクション自体は非常に安全であり、リソースへのアクセスを許可するものではありません。そのため、通常はすべてのプリンシパルに許可しても問題ないアクションです。しかし、セキュリティ上の理由で特定のプリンシパルにこの情報すら取得させたくないという厳格な要件がある場合は、明示的に拒否することも可能です。
  • 認証情報の管理: get-caller-identity コマンドは、あくまで「今使っている認証情報が何者か」を確認するツールです。認証情報自体のセキュリティ（アクセスキーの漏洩防止、ルートユーザーキーの未使用、IAMユーザーキーの定期的なローテーション、MFAの有効化など）を適切に行うことが、AWSアカウント全体のセキュリティにおいて最も重要です。

12. まとめ

この記事では、AWS認証情報を確認するための必須コマンドである aws sts get-caller-identity について詳細に解説しました。

  • このコマンドは、現在使用しているAWS CLIの認証情報が、どのAWSアカウントの、どのプリンシパル（IAMユーザー、IAMロール、ルートユーザーなど）に関連付けられているかを確認するために使用されます。
  • コマンドの出力には、UserId、Account、Arn の3つの重要なフィールドが含まれます。これらのフィールドの値や形式は、プリンシパルの種類によって異なり、特に Arn は、一時的な認証情報であるか否か、どのセッション名が使用されているかといった詳細な情報を提供します。
  • IAMユーザー、IAMロール（EC2インスタンス、Lambdaなど）、ルートユーザー、AssumeRoleによる一時的な認証情報、GetSessionTokenによる一時的な認証情報、IAM Identity Center 経由の認証情報など、様々なシナリオにおける出力例を確認しました。これらの例を理解することで、ご自身の環境でコマンドを実行した際の結果を正確に解釈できるようになります。
  • --query や --profile といったAWS CLIの共通オプションと組み合わせることで、コマンドをより効果的に活用する方法についても触れました。
  • 認証情報の確認、IAM権限のトラブルシューティング、スクリプト/アプリケーションのデバッグなど、get-caller-identity が役立つ具体的なシナリオを紹介しました。
  • コマンド実行時の一般的なエラー（認証情報が見つからない、権限不足など）とその対処法についても説明しました。

aws sts get-caller-identity は、AWS環境で作業する上で非常に基本的でありながら、最も強力なツールの一つです。このコマンドとその出力の意味をしっかりと理解しておくことで、認証情報や権限に関する問題に直面した際に、迅速かつ正確に原因を特定し、解決することができるようになります。

ぜひ、ご自身のAWS環境で aws sts get-caller-identity コマンドを実行し、その出力を確認してみてください。そして、様々な認証情報（例えば、IAMユーザーとして、あるいは一度IAMロールを引き受けてから）で実行した場合の出力の違いを観察し、理解を深めてください。

この記事が、あなたのAWS認証情報への理解を深め、日々のAWS運用に役立つことを願っています。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール