Published on

AWS CLIのDefault Profileは絶対Test環境のみにする理由

Authors
  • avatar
    Name
    グレッグ
    Twitter

Overview

IAM Access Keyを用いて、AWS CLI の Default Profile に絶対 Test 環境用 Credential にしないといけない理由を解説します。

出来れば、Multi Project をする方は基本的に Default Profile は空きにした方が良いこと！

毎日使っている便利な AWS CLI。うっかり、知らずに起こすかも知れない事故防止のため、Profile の使い方を一度考えておきましょう。

例）間違って実行しちゃった！

  1. Staging 環境と Test 環境が同じ S3 Bucket を持っていると想定します
  2. Staging の Credential が Default Profile として指定されている
  3. 開発のために作業をしていた
    terminal-test-profile
    export AWS_PROFILE=TEST_ENV
aws s3 ...
...
  4. Terminal の追加 Tab を開いて引き続き Command を実行した
    terminal-default-profile
    aws s3 rm s3://bucket_sample_A/pp --recursive
delete: s3://bucket_sample_A/pp/file1
delete: s3://bucket_sample_A/pp/file2
delete: s3://bucket_sample_A/pp/file3
delete: s3://bucket_sample_A/pp/file4
...

グレッグ君〜Staging からエラー出ている報告入ったよ。ちょっと確認してみて。

ああーーー

何となく想像出来るでしょうか？

Terminal Tab が複数になってくると、新しい Tab が前回の続きだと勘違いして Default Profile 向けに Command を実行する恐れがあります。 作業が多い日は十分ありえるミスかも知れません。

Default Profile が無いにしても、複数の Tab を行き来しながら作業すると Profile 指定の間違えってありあり得るものです。

この件に限ると単純に考えて間違った Command を実行しちゃっても良い環境か Default Profile が設定されて無ければ防げる事故です。 おそらく権限が無いので次のようなメッセージが出て終わったと思います。

fatal error: An error occurred (InvalidAccessKeyId) when calling the ListObjectsV2 operation: The AWS Access Key Id you provided does not exist in our records.

または Test 環境ならば削除されても影響は少なかったと思います。

Linux の使い始めったごろのrm -rf /の実行と似ている

sudo rm -rf /

個人的にも経験がある Command ですが、Human Miss ってありえないことをしてしまうですよね。 運転と同じくなれ始めたごろにより危険なことを犯してしまうリスクが高まります。

AWS CLI も便利な分、どう悪く使ってしまうか知れませんので常に現在の Profile を意識する習慣が大切かと思います。

AWS CLI 意外でも勝手に Default Profile が実行される Risk、アプリケーションからでも

AWS CLI の Profile って AWS SDK より便利に読み取られます。 ※AWS SDK がアクセスするために AWS を信頼し安易に Application へ Read Access 権限を与えてしまう可能性が高いです。

JAVA の場合次のProfileCredentialsProvider.java#L82から読み取れるように設定可能です

ProfileCredentialsProvider.java#82
...
    /**
     * Creates a new profile credentials provider that returns the AWS security credentials
     * configured for the default profile. Loading the credential file is deferred until the
     * getCredentials() method is called.
     */
    public ProfileCredentialsProvider() {
        this(null);
    }
...

このように profile を指定しない場合 Default Profile を自動的に読み込むように設定が可能です。

自分が経験したプロジェクトでは S3 に社内用 Java Library（Jar）が配置されていて、それを読み込む設定が Gradle Build 設定に入っていました。 そのためには AWS Profile 設定が必要だし、Default Profile を使うようになっていました。 ※通常の Application ならば実行時 Profile 指定して実行すれば良いけど、Gradle Project Setting がこのようになっていると IDE が Project を Import する際に Profile 指定が難しいため Default Profile を活用せざるおえないケースがあります。使用者が指定出来ない点から良い使い方では無いです。

そもそも、影響を与えてはいけない環境（例、Staging や Production）に対して Over Permission を持っている自分自身が悪いこともありますが、せめて Default Profile からその要素を外しておくである程度の Risk は回避出来る訳です。

また、AWS SDK を活用するアプリケーションの場合 Default Profile よりは明示的に Profile Name を指定するように開発ガイドラインを設けた方が良いですね。

立場によって付与された権限は自ら確認する

立場が変わって Project が複数で実行する権限もどんどん増えて来ると思います。

自分も知らず強い IAM 持っていた時期がありました。

※ご自身のために自ら Over Permission は返却しましょう。

管理対象が増えるとその度に IAM 権限変更が面倒なので強い権限を安易に持たせておく場合もあるかも知れません。

Default を無くすために設定する場所

私は基本的に Profile をいつも指定するようにしているので、次の File から [default]の項目は消して使っています

  • ~/.aws/credentials
  • ~/.aws/config

現状の Profile 確認方法

Profile の指定は次のように

  • export AWS_PROFILE=PROFILE_NAME

  •    export AWS_DEFAULT_PROFILE=PROFILE_NAME

    Environment Variable として指定するか

  • aws s3 rm s3://bucket_sample_A/pp --recursive --profile PROFILE_NAME

のように CLI の Option として渡す方法があります。

CLI Option は明示的なものなのですぐ気づくと思います。ただ、Default や Environment Variable に設定されているものは　aws configure list を実行することで何か適用されているのか確認出来ます。

実際適用されて無いのか確認

sh-3.2$ aws configure list
      Name                    Value             Type    Location
      ----                    -----             ----    --------
   profile                <not set>             None    None
access_key     ****************ZRSA shared-credentials-file
secret_key     ****************Q4oR shared-credentials-file
    region           ap-northeast-1      config-file    ~/.aws/config
sh-3.2$

Profile Value がが <not set>になってますね

aws configure list

なので変更を行う Command の場合は aws configure list を一度実行して現在の Profile と Region を確認する習慣を身につけると良いと思います。 この記事でこの Command を覚えるだけでもう、目標は達成したものと同じかも知れません。

Default を設定せざる追えなかった場合は必ず元に戻すこと！

経験した Project では必要な Library が S3 に乗っていて、その S3 が Staging 環境にあるものでした。

Build Tooling の問題とかで Default の Profile として設定しないと Profile 指定が Build Tooling が認識出来ず仕方なく Default の Profile を指定するケースがありました。

その場合はすぐ Default 値を元に戻すように注意しましょう

Discuss on Twitter • View on GitHub