はじめに

こんにちは、クラウド事業部の梅本です。

今回は VSCode で Cline を使った AI 活用を行おうとしたときの話です。

Cline は VSCode の拡張機能で提供される、AI を活用したコーディング支援ツールです。チャットによるコーディング支援のほか、MCP（Model Context Protocol）による外部のツールやデータソースとの連携が可能です。

github.com

そんな Cline の AI 部分の設定を Amazon Bedrock（Claude）にして利用を考えていたところ、IAM Policy が壁となりました。今回は、その奮闘録になります。

Cline の設定

Cline の AI モデル設定画面は以下の通りです。 AI プロバイダー（ Amazon Bedrock や OpenAI など）や、利用する生成 AI のモデルなどを選択できます。

AWS の場合、認証情報として以下の選択肢が用意されています。

AWS Bedrock API Key
AWS Profile（ローカルの AWS CLI のプロファイル）
AWS Credentials（Access Key/Secret Key）

今回は、この認証設定が壁となりました。

調査開始前までは、以下の2つの方法で試したのですがアクセスできませんでした。

AWS Bedrock API Key
AWS Credentials（Access Key/Secret Key）

エラー時のチャット画面

エラーメッセージ

[ERROR] Failed to process response: User: arn:aws:iam::xxxx:user/xxxx@xxxx.co.jp is not authorized to perform: bedrock:InvokeModelWithResponseStream on resource: arn:aws:bedrock:us-east-1:xxxx:inference-profile/us.anthropic.claude-haiku-4-5-20251001-v1:0 with an explicit deny in an identity-based policy

壁となった IAM Policy（MFA 関連）

壁となっていたのは、以下の IAM Policy でした。

{
    "Version": "2012-10-17",
    "Statement": [
        ...
        （途中省略）
        ...
        {
            "Sid": "xxxxx",
            "Effect": "Deny",
            "NotAction": [
                ...
                （途中省略）
                ...
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

このポリシーは、「MFAで認証されていない（aws:MultiFactorAuthPresent が "false" の）場合、NotAction に記載されているアクション以外は、すべて "Deny"（拒否）する」という意味です。

前章のエラー（bedrock:InvokeModelWithResponseStream）がこの NotAction のリストに含まれていなかったため、MFA 認証を経ていないアクセスキーや Bedrock API Key でのリクエストが拒否されていたのです。

社内の検証環境のポリシーなのですが、セキュリティ意識高めな設定ですね。

参考

docs.aws.amazon.com

dev.classmethod.jp

試行1：AWS CloudShell で一時クレデンシャル利用（失敗）

（先に結論を言うと）最短の解決策は、端末にインストールした AWS CLI から MFA を使ってセッショントークンを作成することです。

が、普段から使い勝手の良い（アクセスキーを発行せずに済む）AWS CloudShell（以降 CloudShell）を利用していたため、これでどうにかならないかを模索してしまっていました・・・。

まず、 CloudShell からセッショントークンが発行できないか試してみました。

# コマンド例
aws sts get-session-token \
    --serial-number [MFAデバイスのARN] \
    --token-code [6桁のMFAコード]

# 実際の実行ログ
aws sts get-session-token \
    --serial-number xxxx \
    --token-code 012345

An error occurred (AccessDenied) when calling the GetSessionToken operation: Cannot call GetSessionToken with session credentials

これは、CloudShell が起動時点で既に一時的なセッショントークン（セッションクレデンシャル）を自動で読み込んで動作しているためです。エラーメッセージ（Cannot call GetSessionToken with session credentials）が示す通り、「セッションクレデンシャルを使って、さらにセッショントークン（GetSessionToken）を取得する」ことはできないため、エラーとなっていました。

参考

repost.aws

では、払い出されているセッショントークンを参照すればと思い、、、

# CloudShell 内で利用する認証情報を取得
# 環境変数は CloudShell を起動した段階で設定されている
curl -H "Authorization: ${AWS_CONTAINER_AUTHORIZATION_TOKEN}" \
"${AWS_CONTAINER_CREDENTIALS_FULL_URI}"

# 実行例
curl -H "Authorization: ${AWS_CONTAINER_AUTHORIZATION_TOKEN}" \
"${AWS_CONTAINER_CREDENTIALS_FULL_URI}"

{
        "Type": "",
        "AccessKeyId": "xxxx",
        "SecretAccessKey": "xxxx",
        "Token": "xxxx",
        "Expiration": "2025-10-27T15:23:13Z",
        "Code": "Success"
}

取得はできたものの、ここで取得できるクレデンシャルは CloudShell の実行環境内でのみ有効なキーです。そのため、ローカル PC で動作している Cline からはこのクレデンシャルを利用できず、この方法も失敗に終わりました。

試行2：ローカル AWS CLI でセッショントークンを取得（成功）

原点に立ち返り、ローカル PC に AWS CLI をインストールし、セッショントークンを取得することにしました。

まず、MFA 認証の元となる IAM ユーザーのアクセスキー/シークレットキーを生成し、

# default Profile に登録
aws configure

AWS Access Key ID [None]: xxxx
AWS Secret Access Key [None]: xxxx
Default region name [None]: us-east-1 
Default output format [None]: json

# default Profile を使って MFA 認証を実行し、セッショントークンを取得
aws sts get-session-token --serial-number ${ARN} --token-code xxxx
{
    "Credentials": {
        "AccessKeyId": "xxxx",
        "SecretAccessKey": "xxxx",
        "SessionToken": "xxxx",
        "Expiration": "2025-10-30T02:57:12+00:00"
    }
}

この払い出された一時的なクレデンシャル（AccessKeyId, SecretAccessKey, SessionToken）を Cline の設定（AWS Credentials）に直接登録しても良いのですが、折角なのでAWS CLI に「MFA認証済み」のプロファイルを追加します。

# 「mfa」という名前で新しいプロファイルを作成
# get-session-token で取得した「一時的な」キーを登録する
aws configure --profile mfa

AWS Access Key ID [None]: [get-session-token で取得した AccessKeyId]
AWS Secret Access Key [None]: [get-session-token で取得した SecretAccessKey]
Default region name [None]: us-east-1
Default output format [None]: json

# 対話モードでは設定できないセッショントークンを、mfa プロファイルに追加
aws configure set aws_session_token [取得したSessionToken] --profile mfa

aws configure の対話モードではセッショントークン（aws_session_token）は設定できないため、最後の aws configure set コマンドで明示的に追加しました。

これで準備は整いました。

Cline の設定画面で、認証方法として「AWS Profile」を選択し、先ほど作成したプロファイル名（mfa）を指定します。

この設定で Cline からチャットを行うと、、、

無事にチャットを開始することができました。

終わりに

今回はちょっと遠回りをしてしまいましたが、何とか Cline を始めるまで至ることができました。

今回の「奮闘」の核心は、やはり aws:MultiFactorAuthPresent: "false" を条件に持つ IAM ポリシーでした。ローカル PC で動作するツールには、CloudShell のような（すでにセッションが発行済みの）環境のクレデンシャルを流用するのではなく、ローカルの AWS CLI で MFA 認証を通過させた「セッショントークン」が必須だという、基本に立ち返る結果となりました。

次回は AWS から提供されている MCP を Cline から試してみたいと思います。

Explicit Deny エラーや MFA ポリシーで同じ様に詰まっている方の参考になれば幸いです。