8
0

AWSCLIv1でクロスアカウントアクセスができなかった時の話

Posted at

初めに

AWSでクロスアカウントアクセス設定をしていて詰まった話になります。
CLIv1を使用している方には参考になるかと思います。

前提

アカウントA

  • クロスアカウント元
  • EC2からアカウントBのS3へアクセスしたい
  • awscliのバージョンは1.18.58
  • アカウントBへのassume-role権限を持つポリシーを持ったIAMロールがEC2へアタッチされている
  • credentialsとconfigの設定は以下
credentials
[profile名]
role_arn = "[クロスアカウント先のarn]"
credential_source=Ec2InstanceMetadata
config
[default]
region = ap-northeast-1

アカウントB

  • クロスアカウント先
  • アカウントAの信頼性ポリシーとS3アクセスを許可したポリシーを持つIAMロールがある

何が起こったか

アカウントAからアカウントBへS3のクロスアカウントアクセス設定をして、テストをしている際に
いつまでたっても応答がない状態となりました。
実行したときのコマンドは以下

aws s3 ls s3://[バケット名] --profile [profile名] 

試したこと

  • --debugオプションの使用
    • ConnectTimeoutError: Connect timeout on endpoint URL: "https://sts.amazonaws.com/"
      と表示され、タイムアウトしていることが分かった
  • aws sts get-caller-identity の実行
    • オプションなしで実行しても応答がない
    • --regionオプションを追加してap-northeast-1を指定しても変化なし
  • aws s3 ls の実行
    • オプションなし
      • 自アカウントのS3を表示
    • --profile オプションあり
      • 応答なし
  • --endpoint-url オプションの追記
    • 東京リージョンにあるエンドポイントを指定する。
      • aws s3 ls オプションなし
        • 応答あり、自アカウントのS3をlsで表示できた
      • aws s3 ls --profile
        • 応答なし

原因

--endpoint-urlを指定した場合としなかった場合のデバック内容を見ていたところ、エンドポイントURLが異なることがわかりました。
指定しない場合は、グローバルのエンドポイント
指定した場合は、指定のエンドポイント
のように接続先が異なりました。

どうやらstsエンドポイントのデフォルト動作がCLI v1とv2で異なるようで、v1だとグローバルのSTSエンドポイントに送信し、接続制限に引っ掛かりタイムアウトしてしまうようです。

・AWS CLI バージョン 2 はデフォルトで、現在設定されている AWS リージョンのリージョンエンドポイントにすべての AWS Security Token Service (AWS STS) API リクエストを送信します。
・AWS CLI バージョン 1 はデフォルトで、AWS STS リクエストをグローバル AWS STS エンドポイントに送信します。

結論

CLIのバージョンは最新版を使おう!

8
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
8
0