あきろぐ

いろいろめもするよ🐈🐈🐈

ECSコンテナインスタンスにSSMセッションマネージャを使えるようにする

概要

今までECSのコンテナインスタンスの中に入ってDockerコンテナのデバッグするためには、踏み台サーバー経由して対象のインスタンスsshする必要がありましたが、ECSエージェントのアップデートによりsshなし踏み台なしでコンテナインスタンスの中に入ることができるようになりました。

SSMセッションマネージャを使えば、わざわざセキュリティグループで22ポート開けなくていいし、踏み台サーバーも用意しなくていいし管理の手間が省けるのでとても素晴らしいアップデートです🙏🏻 やり方はクラスメソッドさんの記事に書かれているので、実際にやってみてつまずいたポイントがあるのでそれをまとめておきます。

aws.amazon.com

dev.classmethod.jp

何をしようとしたか

  • ECSエージェントのバージョンを1.36.2以上にあげる
  • SSMセッションマネージャを使うためのポリシーをコンテナインスタンスにアタッチする

何がうまくいかなかったか

コンテナインスタンスのAMIイメージがSSMセッションマネージャに対応していなかった

そもそも論なんですけど、今回のアップデートはAmazon ECS Optimized Linux 2」に対してなので、「Amazon ECS Optimized Linux 」は対応してないんですね。。。 自分のコンテナインスタンスAmazon Linux2だと思い込んでたので、気づくのが遅かったです。 コンテナインスタンスのOS情報は/etc/system-releaseの中に書かれています。

# /etc/system-release
Amazon Linux release 2 (Karoo)

事前に確認しておきましょう。

必要なポリシーを勘違いしていた

早とちりしていたのですが、必要なポリシーは以下のものを追加すれば良いと思っていました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:UpdateInstanceInformation",
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetEncryptionConfiguration"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "key-name"
        }
    ]
}

実際にはこれだけでは不十分でセッションマネージャーは使うことができません。下記のドキュメントにもこのように書かれています。

インスタンスのアクセス許可に対して AWS 提供のデフォルトポリシー [AmazonSSMManagedInstanceCore] に依存しない既存の IAM インスタンスプロファイルに Session Manager のアクセス許可を埋め込むには、以下の手順に従います。この手順では、アクセスを許可するアクションに対する他の Systems Manager の ssm アクセス権限が既存のプロファイルにすでに含まれていることを前提としています。このポリシーだけでは、Session Manager を使用するには十分ではありません。

この手順では、アクセスを許可するアクションに対する他の Systems Manager の ssm アクセス権限が既存のプロファイルにすでに含まれていることを前提としています。このポリシーだけでは、Session Manager を使用するには十分ではありません。

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/getting-started-add-permissions-to-existing-profile.html

このポリシーだけでは、SSMセッションマネージャを使うには不十分なのです。SSMアクセス権限がすでにコンテナインスタンスのロールにアタッチされている前提なのです。コンテナインスタンスのロールにSSMアクセス権限がついていないのであればAmazonSSMManagedInstanceCoreポリシーをアタッチする必要があります。(AmazonEC2RoleforSSMポリシーは権限が強すぎるので)

追記

最小権限を求めて、いろいろと検証したら最低限以下のアクションがあればセッションマネージャを使うことができました!

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssmmessages:CreateControlChannel",
                "ssmmessages:CreateDataChannel",
                "ssmmessages:OpenControlChannel",
                "ssmmessages:OpenDataChannel",
                "ssm:UpdateInstanceInformation"
            ],
            "Resource": "*"
        }
    ]
}

https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/setup-instance-profile.html

この2点を解消することで無事セッションマネージャをコンテナインスタンス対して使うことができました。 おわり