0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS ECRログイン

Posted at

AWS ECRログインでプロファイル名を指定したら成功した!

こんにちは!AWSを使ってコンテナイメージを管理している皆さん、ECRへのログインでこんな経験はありませんか?

「いつものように Get-ECRLoginCommand を実行したのに、なぜかログインできない…」

そして、藁にもすがる思いで -ProfileName オプションを追加したら、あっさり成功!

# ログインに失敗したコマンド
(Get-ECRLoginCommand -Region ap-northeast-1).Password | `
docker login --username AWS --password-stdin {数字}.dkr.ecr.ap-northeast-1.amazonaws.com

# プロファイル名を指定したらログインに成功したコマンド
(Get-ECRLoginCommand -ProfileName test -Region ap-northeast-1).Password | `
docker login --username AWS --password-stdin {数字}.dkr.ecr.ap-northeast-1.amazonaws.com

今回は、この「なぜプロファイル名を指定するとうまくいくのか?」という疑問について、その理由を調査しました。

結論:適切な「鍵」を選んであげる必要があるから

一言でいうと、「どのAWSアカウントの権限を使ってECRにアクセスするかを明示的に指定する必要があった」ということです。

Get-ECRLoginCommand は、ECRへDockerがログインするためのパスワードを生成してくれる便利なコマンドです。このコマンドがパスワードを生成する際には、AWSの認証情報(アクセスキーIDやシークレットアクセスキーなど)が必要になります。

ここでポイントとなるのが、PC上に複数のAWSアカウントの認証情報(プロファイル)を設定している場合です。

プロファイルとは? AWS認証情報の使い分け

AWS CLIやSDKを利用する際、私たちはAWSアカウントの認証情報をPCに設定します。通常、これらの情報は ~/.aws/credentials~/.aws/config といったファイルに保存されます。

複数のAWSアカウントを利用している場合や、同じアカウントでもIAMユーザーごとに権限を使い分けたい場合、これらのファイルに複数の「プロファイル」を作成して管理することができます。

例えば、credentials ファイルは以下のようになっているかもしれません。

[default]
aws_access_key_id = YOUR_DEFAULT_ACCESS_KEY
aws_secret_access_key = YOUR_DEFAULT_SECRET_KEY

[test]
aws_access_key_id = YOUR_test_ACCESS_KEY
aws_secret_access_key = YOUR_test_SECRET_KEY

この例では、「default」プロファイルと「test」プロファイルの2つの認証情報が設定されています。

なぜプロファイル名を指定しないと失敗したのか?

-ProfileName オプションを指定せずに Get-ECRLoginCommand を実行した場合、AWS CLIは以下の優先順位で認証情報を探しに行きます。

  1. コマンドラインオプション: (今回は指定なし)
  2. 環境変数: (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY など)
  3. 共有認証情報ファイル (credentials): デフォルトプロファイル ([default])
  4. CLI設定ファイル (config): デフォルトプロファイル ([default])
  5. インスタンスプロファイル認証情報: (EC2インスタンス上で実行している場合など)

つまり、-ProfileName を指定しない場合、デフォルトのプロファイル ([default]) に設定されている認証情報を使ってECRへのアクセスを試みます。

もし、ECRリポジトリへのアクセス権限を持つのが「test」プロファイルであり、「default」プロファイルにはその権限がない場合、当然ながら認証は失敗し、ログインできないという結果になります。

なぜプロファイル名を指定すると成功したのか?

一方、-ProfileName test のようにプロファイル名を指定した場合、Get-ECRLoginCommand は明示的に「test」プロファイルに設定されている認証情報を使用します。

この「test」プロファイルが、対象のECRリポジトリ ({数字}.dkr.ecr.ap-northeast-1.amazonaws.com) への適切なアクセス権限(例えば、ecr:GetAuthorizationToken やリポジトリへの読み書き権限など)を持っていれば、無事にパスワードが生成され、Dockerログインも成功するというわけです。

具体的に何が異なったのか?

コマンド実行時に内部で起こっていることを比較してみましょう。

  • プロファイル名指定なし (失敗ケース):

    1. Get-ECRLoginCommand が実行される。
    2. AWS CLIがデフォルトプロファイルの認証情報を読み込む。
    3. その認証情報を使って、ECR (ap-northeast-1 リージョン) へ一時的なログインパスワードの発行をリクエストする。
    4. デフォルトプロファイルには対象ECRへのアクセス権限がないため、AWSからエラーが返されるか、不適切なパスワードが生成される。
    5. docker login がそのパスワードで試みるが、認証に失敗する。
  • プロファイル名指定あり (成功ケース):

    1. Get-ECRLoginCommand -ProfileName test が実行される。
    2. AWS CLIが「test」プロファイルの認証情報を読み込む。
    3. その認証情報を使って、ECR (ap-northeast-1 リージョン) へ一時的なログインパスワードの発行をリクエストする。
    4. 「test」プロファイルには対象ECRへのアクセス権限があるため、AWSから正しい一時パスワードが発行される。
    5. docker login がそのパスワードで試み、認証に成功する。

まとめ:適切なプロファイル指定で快適なAWSライフを!

複数のAWSアカウントやIAMユーザーを使い分けている環境では、どの認証情報を使ってコマンドを実行するのかを意識することが非常に重要です。

ECRへのログインに限らず、AWS CLIで「権限がない」といったエラーに遭遇した場合は、まず適切なプロファイルが指定されているか、あるいはデフォルトプロファイルの設定が正しいかを確認してみましょう。

今回のケースのように、-ProfileName オプションで適切な「鍵」を選んであげることで、スムーズに目的の操作を実行できるようになります。

この記事が、皆さんのAWS運用の一助となれば幸いです!


0
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
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?