AWS CLIでCodeCommitにGitアクセスする方法｜IAMロール×スイッチロール×環境変数を徹底解説【失敗例あり】

こんにちは！PCIソリューションズエンタープライズビジネス事業本部 ITインフラ事業部の山岡です。

これまでAWSの資格取得や、Kiroについてお話してきましたが

これまでの記事をまだ読んでいない方はこちらから

現場で仕事をする中の疑問を検証してきたので、今回はその紹介です。

今回扱う話は、AWS CLIの「aws login」を用いたEC2内でのIAMユーザーログイン（以下CLIログインと呼びます）と、Gitクライアントを用いるための設定の話です。

チームで運用作業を行う際の設計などの参考になればと思います。

こんな悩みを抱えていませんか？

・EC2上でGitコマンドを使いたいが、AWS CLIでログイン後にCodeCommitへのアクセスが通らない

・IAMロールにスイッチロールしたはずなのに、IAMユーザーの権限でアクセスされてしまう

・複数チームが同じEC2を使うため、インスタンスプロファイルでは権限を使い分けられない

本記事ではこれらをすべて解決します。

3つの検証（失敗2回・成功1回）を通じて、「IAMロールへのスイッチロール後に一時的な認証情報を環境変数へ設定する」という正解にたどり着くまでの過程を、AWS CLIコマンドとCloudTrailの出力を交えながら丁寧に解説します。

CodeCommitへのGitアクセス設計で悩んでいるエンジニアの方に特に参考になる内容です。

(1). AWS CLIログイン（aws login）とは？要件と検証内容の整理

前提の話になります。

要件について

今回考慮する要件は以下の3点です。

・EC2へはCLIログインをして、Gitクライアントを用いてCodeCommitにアクセスするなどの作業をしたい。

・CodeCommitへは別で用意したIAMロールでアクセスしたい。

・いろんな領域が同じEC2を使うので、インスタンスプロファイルのロールではアクセスしたくない。

また、処理イメージは以下の通りとなります。

検証内容について

IAMロールにスイッチロールした権限でCodeCommitにアクセスすることが出来たら検証成功とします。

今回は大きく3つの検証をしました。成功した検証の内容を知りたい方は3の検証をご覧ください。

1．IAMユーザーがIAMロールにスイッチする権限を持っていれば、コマンド実行時に勝手にスイッチロールされてアクセスできるのか。（検証失敗）

2．IAMユーザーがIAMロールに明示的にスイッチロールすることで、ロールの権限でアクセスできるのか。（検証失敗）

3．明示的にスイッチロールした後に、何らかの処理が必要なのか。（検証成功。検証の中で調査も交えていきます）

(2). 環境構築｜EC2・IAMポリシー・IAMロール・CodeCommitの準備手順

用意するものたちです。（以降アカウントIDは念のため伏せています）

EC2

・OSはRHELの9系を用います。

EC2内に用意するもの

・AWS CLI v2（2.32.0 以上）…AWS CLIログインに対応していること。

・Gitクライアント…以下の初期設定がされていること。

1．ユーザー名設定

git config --global user.name "Ryota Yamaoka"

2．Eメールアドレス設定

git config --global user.email "●●●@●●●.co.jp”

3．AWS CLIの認証情報を使うようにする設定

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

4．リポジトリへのアクセスURL全体を参考に、認証情報を使い分けるようにキャッシュする設定

git config --global credential.UseHttpPath true

IAMで用意するもの

・IAMポリシー（CLIログイン用）…「signin:AuthorizeOAuth2Access」「signin:CreateOAuth2Token」の権限を許可するIAMポリシーを作成する。今回はMFA認証も行う権限も追加しているが無くても良いです。

例)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowOAuthWithMFA",
            "Effect": "Allow",
            "Action": [
                "signin:AuthorizeOAuth2Access",
                "signin:CreateOAuth2Token"
            ],
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        }
    ]
}

・IAMポリシー（スイッチロール用）…「sts:AssumeRole」を許可する以下のようなポリシーを付与する。Resourceにはスイッチロール先のIAMロールのARNを指定しよう。

例)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::XXXXXXXXXXXX:role/MY-ROLE"
        }
    ]
}

・IAMロール（CodeCommitアクセス用）…CodeCommitにアクセスするためのIAMロールを作成する。自身の用途に応じて以下の公式ドキュメントより設計して設定しましょう。

CodeCommit アクセス許可リファレンス – AWS CodeCommit

今回使うロールは「AdministratorAccess」を付与し、何でもできるようにしています。

ロール名は「MY-ROLE」です。

・IAMユーザー（CLIログイン用）…以下のようにポリシーを付与する。ポリシーは上記で作成したモノ2つをつけているだけですね。ユーザー名は「IAM-test01」にしています。

CodeCommitで用意するもの

・リポジトリ…今回は空のリポジトリを作成。このリポジトリへはHTTPSを用いてアクセスする。リポジトリ名は「my-test」としました。

(3). 検証作業｜IAMロール×スイッチロールでCodeCommitにGitアクセスできるか3パターン試した

まずCLIログインを行う手順について紹介します。

①「aws login –remote」を実行

EC2サーバ内で「aws login –remote」を実行します。RHELでは「–remote」オプションが必要になるので注意です。

aws login –remote

すると、以下のようにURLが表示されます。（青字）このURLにアクセスしましょう。

②Windows環境でIAMユーザー認証を行う

URLをクリックすると以下のようなページにたどり着きました。既にログイン済みのセッションがある場合は利用するセッションを選択する画面になります。

今回は未ログインなのでこのページの「Continue with Root or IAM user」を押下して続行します。

すると以下のようにIAMユーザーでAWSコンソールログインを行う画面になるので、認証情報を入れていきます。

ログイン成功すると以下の画面になります。
「Copy verification code」をクリックし、検証コードをコピーします。

ちなみにIAMポリシーでCLIログイン許可がされてない場合、失敗しました（1敗）

③EC2のサーバに戻って検証コードを入力する。

コピーしたコードを入力してログイン成功。

IAMユーザーでログインを出来ていることを確認する。

aws sts get-caller-identity

ちゃんとIAM-test01でログイン出来ていることが分かりますね！

以降は(1). AWS CLIログイン（aws login）とは？要件と検証内容の整理 で解説した検証について書いていきます。

1．IAMユーザーがIAMロールにスイッチする権限を持っていれば、コマンド実行時に勝手にスイッチロールされてアクセスできるのか。（検証失敗）

クローンコマンドを入力してアクセスを確認します。クローンコマンドはCodeCommitのリポジトリに表示されているのでコピーしてきましょう。

ではコマンド実行。
ですが失敗……

CloudTrailの出力も確認しましたが、IAMユーザーでアクセスしたようですね。

一部抜粋）

"errorCode": "AccessDenied",



"errorMessage": "User: arn:aws:iam::XXXXXXXXXXXX:user/IAM-test01 is not authorized to perform: codecommit:GitPull on resource: arn:aws:codecommit:ap-northeast-1: XXXXXXXXXXXX:my-test because no identity-based policy allows the codecommit:GitPull action",

アクセスしたユーザーは以下の”userIdentity”フィールドの出力から、ログインした時点のIAMユーザーで間違いなさそうです。

    "userIdentity": {
        "type": "IAMUser",
        "principalId": "AIDAQOD4QQ6IJDVKSXNPE",
        "arn": "arn:aws:iam::XXXXXXXXXXXX:user/IAM-test01",

2．IAMユーザーがIAMロールに明示的にスイッチロールすることで、ロールの権限でアクセスできるのか。（検証失敗）

コマンドを実行する前にIAMロールにスイッチロールします。スイッチロールのコマンドは以下の通り。

aws sts assume-role \
–role-arn arn:aws:iam::XXXXXXXXXXXX:role/MY-ROLE \
–role-session-name testMY-ROLE

このコマンドではMY-ROLEにスイッチロールを行い、ロールの利用中のセッション名を「testMY-ROLE」としています。

スイッチロールが成功すると以下のような表示が出ます。

この状態でGitクローンコマンドを実行してみます。
ですが失敗。

CloudTrailの出力も1と同様で、IAMユーザーの認証情報でアクセスされていました。

3．明示的にスイッチロールした後に、何らかの処理が必要なのか。（検証成功。検証の中で調査も交えていきます）

こんな公式ドキュメントを見つけました。

参考：https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_use-resources.html

AWS CLI で一時的なセキュリティ認証情報を使用する
AWS CLI コマンドを実行すると、AWS CLI によって特定の順序で資格情報が検索されます。最初は環境変数で、次に構成ファイルで検索されます。したがって、一時的な認証情報を環境変数に設定すると、AWS CLI でこれらの認証情報がデフォルトで使用されます（コマンドで profile パラメーターを指定すると、AWS CLI は環境変数をスキップします。代わりに、AWS CLI は構成ファイルを調べます。これにより、必要に応じて環境変数の資格情報をオーバーライドできます。）

ここから分かるように、2でスイッチロールした後にIAMロールの資格情報をOSの環境変数に設定すると、AWS CLIがそちらの資格情報を最初に参照してくれるそうです。

このドキュメントを参考に、環境変数にパラメーターを設定していきます。

export AWS_ACCESS_KEY_ID=ASIAQOD4QQ6IASGP4WI6
export AWS_SECRET_ACCESS_KEY=bMay2c+0qga9TzULacHVuTzrw3ilS/727wiwrofM
export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2 ……

これらの入力値は検証2のスイッチロール成功時に表示された値です。

遡ってスクリーンショットを見てもらうと、同様の値が表示されていることが確認できると思います。これらの入力値は検証2のスイッチロール成功時に表示された値です。

この時点でのAWS CLIで今使っている資格情報を確認しましょう！

aws sts get-caller-identity

ちゃんと「MY-ROLE」の資格情報になっていますね。これならできそう！

ではGitクローンコマンドを実行してみます。

成功です～～。（Warningなのはリポジトリが空になっているためです。）

この実行のCloudTrailの出力は以下のようになっていました。

一部抜粋）

    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAQOD4QQ6IGMLACR6Z6:testMY-ROLE",
        "arn": "arn:aws:sts::XXXXXXXXXXX:assumed-role/MY-ROLE/testMY-ROLE",

“userIdentity”フィールドでIAMロールとなっていることが確認できました。

(4). まとめ｜AWS CLIログイン×スイッチロール×CodeCommit Gitアクセスの正しい設計と注意点

今回検証したCLIログインと認証情報設定の話は、現場で設計を考えている際にかなり躓いたので、検証して記事にしてみました。

今回のような設計は、CLIログインで用いるユーザーやCodeCommitへアクセスするロール両方でポリシーを分けることが出来るため、様々な領域がサーバからCodeCommit等のリポジトリへGitコマンドを用いてアクセスするような場合に有効かなと思います。

ただし、CLIログインもスイッチロールも「一時的な認証情報を取得する」というものなので、制限時間があるという点には注意してください。

・IAMユーザーのセッション制限時間…12時間、変更不可

・IAMロールのセッション制限時間…1～12時間。変更可

山岡亮太

AWSを活用した社内システム開発や、大手保険機関のシステム開発に従事。 /AWSをより多くの方々に普及するためブログを書いています。

保有AWS資格
・AWS Certified Cloud Practitioner ・AWS Certified AI Practitioner ・AWS Certified Solutions Architect - Associate ・AWS Certified Developer - Associate ・AWS Certified CloudOps Engineer - Associate ・AWS Certified Solutions Architect - Professional ・AWS Certified DevOps Engineer - Professional 等

保有AWS資格一覧