IAMロールを使用して一時クレデンシャルを使用する（AWS SSOは使用しない）

こんにちは、永続的なクレデンシャルを使いたくない上野です。

自分のPCでAWS関連の開発をしたい場合、みなさんどうしていますでしょうか？

AWS SSOを使用すると、次のように簡単に一時的なクレデンシャルを発行できます。
（デフォルトでは1時間で有効期限切れとなります。）

f:id:fu3ak1:20220131152630p:plain

私もこの機能がめちゃくちゃ好きでよく使うのですが、AWS SSOを使う場合はAWS Organizationsの使用が前提となります。AWS Organizationsが使用できない場合や、Organizations経由で発行されたアカウントのみを使用する場合、AWS SSOは使用できません。

ということで、AWS SSOを使用しないで、一時的なクレデンシャルを使用する1つの方法を紹介します。

※もっと良いやり方を知っている方がいれば教えていただきたいです！

実装する構成

IAMユーザーとIAMロールを使用します。IAMユーザーはログインだけ行い、特定のIAMロールにAssumeRoleをして一時的なクレデンシャルを取得します。 AssumeRoleの実行はCloudShell経由で行います。

f:id:fu3ak1:20220131185853p:plain

やってみる

まずはIAMロールを準備しておきます。

信頼されたエンティティには「別のAWSアカウント」を指定し、ログインするAWSアカウントのIDを入力します。

f:id:fu3ak1:20220131165334p:plain

IAMロールに付与する権限は、今回はAdministratorAccessにします。（※使用状況に応じて必要な権限を設定します）

f:id:fu3ak1:20220131165531p:plain

任意の名前をつけて作成します。

f:id:fu3ak1:20220131180705p:plain

つづいてAssumeRoleする（AWSへログインする）IAMユーザーです。権限は最低限以下のとおり付与しておきます。CloudShellの実行と、作成したRoleへAssumeRoleする権限です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudShell",
            "Effect": "Allow",
            "Action": "cloudshell:*",
            "Resource": "*"
        },
        {
            "Sid": "AllowAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::[アカウントID]:role/FromMyAccount"
        }
    ]
}

IAMユーザーにはクレデンシャルは発行しません。パスワードでマネジメントコンソールにログインできるようにしておきます。

ユーザーが作成できたら一時的なクレデンシャル発行をやってみます。

今回はクレデンシャルを使いやすい形に整形するため、Pythonスクリプトを用意しておきます。

import boto3

sts = boto3.client('sts')

# AssumeするRoleのARNを記載
role = 'arn:aws:iam::123456789012:role/FromMyAccount'
caller_info = sts.get_caller_identity()
# ARNから/区切りで2つ目の文字列をユーザー名として取得し、assume_roleのSession名に使用
# "arn:aws:iam::123456789012:user/ueno"
session = caller_info.get('Arn').split('/')[1]

response = sts.assume_role(
    RoleArn=role,
    RoleSessionName=session
)

print('export AWS_ACCESS_KEY_ID=' + response.get('Credentials').get('AccessKeyId'))
print('export AWS_SECRET_ACCESS_KEY=' + response.get('Credentials').get('SecretAccessKey'))
print('export AWS_SESSION_TOKEN=' + response.get('Credentials').get('SessionToken'))

スクリプトをローカルに用意しておき、AWSマネジメントコンソールへログイン後、CloudShellを起動します。

CloudShellではファイルアップロードが使えるので、そこから先ほど作成したPythonのスクリプトをアップロードします。ここではsts.pyというファイル名にしておきます。

f:id:fu3ak1:20220131182151p:plain

CloudShellの起動後すぐにアップロードすれば、以下のようにホームディレクトリにアップロードされます。

f:id:fu3ak1:20220131182321p:plain

あとはスクリプトを実行するだけです。python3 sts.pyで実行します。次のように、Linuxの環境変数を設定する方式で出力してくれます。

$ python3 sts.py 
export AWS_ACCESS_KEY_ID=ASIAQQJYHOGEHOGEHOGE
export AWS_SECRET_ACCESS_KEY=ZiIe4BIBRX6qM5AVapwHOGEHOGEHOGE
export AWS_SESSION_TOKEN=FwoGZXIvY~省略~yf9yI1+CEWJPQiEx20Yh13g==

python3 $HOME/sts.py をホームディレクトリにある.bashrcやに追記しておけば、CloudShell起動の都度一時キーを表示してくれるようになります。

あとは出力されたexport ~の3行を、ローカルPC環境でコピペすればOKです。

私の場合は、Window PCにWSL2を導入した環境で試しています。（Ubuntu）
Visual Studio Code上で実行しています。

以下のような感じです。

f:id:fu3ak1:20220131183304p:plain

あとは自由にAWS CLIや、ローカルで作成したスクリプトを実行してAWSへアクセスできます。

# バケットの一覧
$ aws s3 ls
2019-09-05 14:26:58 aws-athena-query-results-123456789012-ap-northeast-1
2019-09-05 14:31:54 test-bucket01
・・・

# CloudFormation Stackの一覧
$ aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE | jq .StackSummaries[].StackName
"Test-Stack01"
"Test-Stack02"
・・・

安全に開発ができそうです！

応用編

この方法を活かした応用例をいくつか紹介します。

CodeCommitへのアクセス

CodeCommitへのGit接続は、通常SSH用の公開キーや、HTTPS接続用の認証情報を作成して行いますが、IAMロールを使用した場合認証情報ヘルパーを使用してアクセスできます。CodeCommit専用の認証情報は不要です。

ドキュメントにあるとおり、以下のコマンドをローカルPC上で実行すればOKです。

git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true

設定後は以下のとおりGitコマンドでCodeCommitへ接続できます。

git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/[リポジトリ名]

別アカウントへのスイッチロールも可能

今回は1つのAWSアカウント内の例を紹介しましたが、IAMロールは別アカウントにあっても問題なくAssumeできます。 AWS SSOは使えないけど複数アカウントの権限を使いたい。という場合に便利です。

IAMロールを作成する際に、信頼されたエンティティにログインするAWSアカウントを指定すればOKです。

f:id:fu3ak1:20220131185904p:plain

まとめ

紹介以上です。最近AWS SSOを使用することが多いのですが、環境によってはAWS SSOを使えないことも多く、どうにか一時キーで開発しようと思って考えてみた方法です。長期的な開発を見越すのであれば、永続的なキーを発行するというのも一案なのですが、サクッと少し開発したい場合はこのように永続的なキーなしで開発を進めるのも良いと思います。

アクセスキーの扱いに悩まれている方、少しでも参考になれば幸いです。