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

session-manager-kms-encryption-error
接続エラー 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ポリシー」など、ポリシー地獄を覚悟する必要があり、間違えるとアプリ開発チームやその他のチームやプロジェクト出資者から恨まれることを保証しますw

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 インスタンスプロファイルを作成するを参考に。

AWSの記事でコメントをいただくことがしばしばあるため、コメント機能を有効化しました。
ただ、申し訳ないのですが過去のコメントについては、WPの仕様で基本的に表示できません。
そのうち調べて表示します。お気軽にコメントください。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください