SSMセッションマネージャーでKMS encryption（暗号化）有効化したらhandshakeエラー

接続エラー IAMユーザー名-〇△×〇△×〇△×〇△×

セッションが次の理由で終了されました。  ----------ERROR------- Encountered error while initiating handshake. Fetching data key failed: Unable to retrieve data key, Error when decrypting data key AccessDeniedException: The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access. status code: 400, request id: 〇△×〇△×〇△×〇△×
〇△×〇△×〇△×〇△×

SSM（AWS Systems Manager）のSession Managerで、KMS encryption（暗号化）すると上記のhandshakeエラーが出ます。無効化するとprivate subnet経由でシェルアクセスできます。

SSM Agent バージョン　3.0.222.0　、AmazonLinux2です。

aws-cli/1.16.300 Python/2.7.18 Linux/4.14.186-146.268.amzn2.x86_64 botocore/1.13.36　です。

古くね？これ？AWS CLI v2が必要？環境制約でいじられない部分・・・。

インスタンスプロファイルロールをAmazonSSMManagedInstanceCoreからAmazonEC2RoleforSSMに変えてみても駄目でした。

IAMロールのポリシー付け替えって、結構、反映に時間がかかって設定後に0.00000001秒で即検証出来ない時がある様な気がする。

Secureにセッションマネージャー使えない・・・。

プライベートサブネットEC2インスタンスでセッションマネージャーを使うための経路確保確認してみる

SSMエージェントが対象のプライベートサブネットのEC2インスタンスにインストールされ、有効化（active）になっているか？バージョンは古くないか？それぞれ確認。

amazon-ssm-agent確認コマンド(AmazonLinux2)

sudo systemctl status amazon-ssm-agent

amazon-ssm-agent起動コマンド(2つのどちらでもいい)(AmazonLinux2)

sudo systemctl start amazon-ssm-agent

sudo systemctl enable amazon-ssm-agent

VPCエンドポイント

以下4つが必要

1. com.amazonaws.リージョンを選ぶ.ssm
2. com.amazonaws.リージョンを選ぶ.ec2messages
3. com.amazonaws.リージョンを選ぶ.ssmmessages
4. com.amazonaws.リージョンを選ぶ.s3

1,2,3 はGatewayタイプではなくInterface型なのでセキュリティグループが必要。セキュリティグループは、1つ作って3つのVPCエンドポイントに同じセキュリティグループを使えばよい。3つのVPCエンドポイントで共用するセキュリティグループは、インバウンドのHTTPSで「VPC」か「該当するEC2インスタンスのプライベートサブネット」を開放する。

そして、プライベートサブネットのEC2インスタンスからS3バケットへの経路確保も必要。リージョンを指定するため、aws s3 lsコマンドが使えなくなり、以下のようにリージョン指定しなければならない。これハマってセキュリティグループまで開放しまくった・・・。超迷惑・・・。

aws s3 ls --region ap-northeast-1

のように東京などのリージョン指定したAWS CLIがプライベートサブネットのEC2インスタンスからS3に対して必要になる。

S3のVPCエンドポイント経路ができると、InternatGateway経由で外部ネットワークと通信出来なくても、プライベートサブネットのEC2インスタンスでyum check-updateできちゃうケースが発生するので要注意。S3内にAWSが用意しているAmazonLinux2のyumリポジトリがあり、S3フルアクセスなどのIAMポリシーを他でも使っていてS3バケット単位でアクセス制限していない場合になります。「S3バケットポリシー」、「EC2のIAMロールのIAMポリシー」、「VPC エンドポイントポリシー」、「S3のACLポリシー」など、ポリシー地獄を覚悟する必要があり、間違えるとアプリ開発チームやその他のチームやプロジェクト出資者から恨まれることを保証しますｗ

4 のcom.amazonaws.リージョンを選ぶ.s3のVPCエンドポイントは、ルートテーブルの設定が必要。プライベートサブネットのルートテーブルを選択。

プライベートサブネットのEC2インスタンスのセキュリティグループの経路確保

プライベートサブネットのEC2インスタンスのセキュリティグループでSSMのVPCエンドポイント達に送るためのアウトバウンドHTTPS開放が必要

プライベートサブネットのEC2インスタンスのIAMロールにIAMポリシーをアタッチ

余分なものも書いてますが、念の為に確認。

プライベートサブネットのAmazonLinux2のEC2インスタンスのIAMロールに以下のIAMポリシーをアタッチ

• AmazonSSMManagedInstanceCore

プライベートサブネットのWindows Server の EC2 インスタンスを Microsoft AD ディレクトリに結合

• AmazonSSMDirectoryServiceAccess

CloudWatchエージェント をインストールして実行する場合

• CloudWatchAgentServerPolicy

IAMポリシーのjsonの例

ステップ 4: Systems Manager の IAM インスタンスプロファイルを作成するを参考に。