整理
-
ここでは、Systems Managerで以下の2つが行えるようにすること。
-
セッションマネージャを利用できること。
-
パッチマネージャでOSパッチの自動適用が行えること。
-
EC2をパブリックサブネットに配置した場合、プライベートサブネットに配置した場合など複数の環境下での注意点について整理する。
Systems Managerにおいて参考としたら良いハンズオンは以下のページが良いと思いますが、IAMポリシーが古かったりする場合があるので、ただハンズオン通り進めるのではなく、考えながら進めていくのが良いでしょう。
条件1
- Linux2でEC2をパブリックサブネットに起動済。（SSM AgentはLinux2のため、デフォルトでインストールされている。）
- EC2のセキュリティグループにおいて、443番ポートへのアウトバウンドが許可されていること。
1a.ロールの作成
AmazonSSMManagedInstanceCoreのポリシーをアタッチしたIAMロールを作成し、EC2にロールをアタッチする。
なお、記事によっては情報が古いため、AmazonEC2RoleforSSMを紹介しているものもあるが、これは広範囲、非推奨であり、ドキュメントにはこのポリシーはまもなく廃止されると記載されている。
必要最小限のポリシーをアタッチするという基本的な原則に従って、AmazonSSMManagedInstanceCoreを付与する。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ssm:DescribeAssociation",
"ssm:GetDeployablePatchSnapshotForInstance",
"ssm:GetDocument",
"ssm:DescribeDocument",
"ssm:GetManifest",
"ssm:GetParameter",
"ssm:GetParameters",
"ssm:ListAssociations",
"ssm:ListInstanceAssociations",
"ssm:PutInventory",
"ssm:PutComplianceItems",
"ssm:PutConfigurePackageResult",
"ssm:UpdateAssociationStatus",
"ssm:UpdateInstanceAssociationStatus",
"ssm:UpdateInstanceInformation"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssmmessages:CreateControlChannel",
"ssmmessages:CreateDataChannel",
"ssmmessages:OpenControlChannel",
"ssmmessages:OpenDataChannel"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2messages:AcknowledgeMessage",
"ec2messages:DeleteMessage",
"ec2messages:FailMessage",
"ec2messages:GetEndpoint",
"ec2messages:GetMessages",
"ec2messages:SendReply"
],
"Resource": "*"
}
]
}
1b.フリートマネージャー
1〜2分ぐらいすると、フリートマネージャーのマネージドインスタンスに表示されていることが確認できます。
フリートマネージャーとは、マネジメントコンソールのWEB UIでマネージドインスタンスを管理できる機能です。
以前は、マネジメントコンソールのWEB UIからマネージドインスタンスとして存在していましたが、フリートマネージャーに統一されているようです。
1c.セッションマネージャー
対象となるインスタンスを選択して、「セッションを開始する」をクリックするだけです。
パブリックサブネットにある場合は、ルートテーブルにIGWへの通信経路が存在すれば、EC2とセッションマネージャー間の通信が可能となるだけですので、至ってシンプルに接続することが可能です。
1d.パッチマネージャ
パッチマネージャを利用して、Linux2パッチの自動適用が行えるようにします。
手順は以下ワークショップの「5. インスタンスへのOSパッチの自動適用 > 5.1 Linux (OSパッチの自動適用)」の通り実行するだけですので、割愛します。
なお、操作そのものはパッチマネージャーとメンテナンスウインドウを行いますが、
パッチマネージャーの実態はRun Commandであり、AWS-RunPatchBaselineドキュメントを利用してLinux2パッチの自動適用が行われます。以下の図がとてもわかりやすく紹介されておりますので、知識を深めると良いです。
条件2
- Linux2でEC2をプライベートサブネットに起動済。（SSM AgentはLinux2のため、デフォルトでインストールされている。）
- EC2のセキュリティグループで443番ポートへのアウトバウンドが許可されていること。
- パブリックサブネットにはNAT gatewayを作成し、プライベートサブネットのルートテーブルに反映していること。
- 1aの手順で作成したAmazonSSMManagedInstanceCoreのポリシーを付与したIAMロールを付与済であること。
以上の条件をクリアすれば、同様に、フリートマネージャー、セッションマネージャー、パッチマネージャーで管理することができる。
条件3
-
Linux2でEC2をプライベートサブネットに起動済。（SSM AgentはLinux2のため、デフォルトでインストールされている。）
-
EC2のセキュリティグループで443番ポートへのアウトバウンドが許可されていること。
-
1aの手順で作成したAmazonSSMManagedInstanceCoreのポリシーを付与したIAMロールを付与済であること。
-
条件2のようにNAT gatewayがない場合、もしくはセキュアな環境でプライベートサブネットのみで管理したい場合、プライベートサブネットにVPCエンドポイントを利用します。
-
com.amazonaws.region.ssm
-
com.amazonaws.region.ec2messages
-
com.amazonaws.region.ssmmessages
-
上記のVPCエンドポイントのセキュリティグループは、EC2から443番ポートのインバウンドを許可する必要があることに注意が必要です。
DHMC
公式のアップデート情報のとおりですが、アカウント内のすべての EC2 インスタンスでデフォルトで AWS Systems Manager を有効にするという機能です。
上記で記事を書いてる方の内容が参考になります。
これまで Systems Manager で EC2 インスタンスを管理するために以下の事前準備が必要でしたが、2.の作業が不要になるとのことです。
- EC2 インスタンスに SSM エージェントがインストールされていること
- IAM インスタンスプロファイル（IAM ロール）を EC2 インスタンスにアタッチする
- EC2 インスタンスから Systems Manager への通信経路確保
アカウント内の EC2 インスタンスすべての権限を設定したいといった場合は有効だと思いますが、アカウント内の一部の EC2 インスタンスのみSSMの管理外にしたいといった場合などは、従来通りの方がよさそうですね。