AWSでセッションマネージャのログ出力をする際の設定と注意事項、ハマりどころなど
セッションマネージャーとは
AWSにはSystems Managerという便利なサービスがあります。
Systems Managerとは、サーバ上にAgentをインストールするなど適切に設定すると、
そのサーバをマネージドインスタンスとして管理下に置き、
それらのサーバにさまざまなことをコンソールやcliなどから行うことができるようにするサービスです。
できることの中の1つ[1]にSession Manager（セッションマネージャー）というものがあります。
セッションマネージャーとは、簡単に言うとSSHのポートを使わずにAWSの認証情報を使ってサーバにシェルアクセスできるサービスです。
これを使うとSSH Agentも起動せず、秘密鍵なども使わずに、IAMの情報でサーバのシェルにアクセスできます。
また、SSHやSCPを行うこと「も」できます[2]。
AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました
いまだと設定が済んでいればEC2のコンソールからもセッションマネージャーで接続できるので便利です。
適切に設定をすればプライベートサブネットにあるインスタンスにも接続できてしまいます。
これはEC2インスタンスではなくオンプレミスのサーバでも使うことができるたいへん便利なサービスなのですが、
本記事ではEC2インスタンスに限って説明します。
Systems Managerの設定方法
セッションマネージャーを使うためにはSystems Managerで該当のサーバをマネージドインスタンスにする必要があります。
そのためには下記の設定が必要です。
- SSM[3] Agentのインストール
- 現行のAmazon Linuxであればデフォルトでインストール済み
- SSMのAPIへの経路確保
- ここでハマりどころがあります（後述）
- IAMロールの付与
-
SSMManagedInstanceCoreのポリシーか、それと同等の権限が割り当てられたロールが必要
-
下記スライドのP15〜17の記載もご参照ください。
また、クイックセットアップで設定する方法もこちらの資料には記載されています。
20200212 AWS Black Belt Online Seminar AWS Systems Manager
ただ使うだけであればこれでも十分ですが、セッションマネージャーで証跡をきっちり残したいのであればS3やCloudWatch Logsに出力するように別途設定をする必要があります。
デフォルトではセッションマネージャーの設定は下記のようになっています。(20210131時点)
CloudWatch LogsやS3に操作内容や表示内容を記録したいのであれば、CloudWatch loggingやS3 loggingをEnabledにする必要があります。
ただし、ここに落とし穴があります。
セッションマネージャーのログを出力する権限はサーバ上のロール側に必要
何も考えずにS3やCloudWatch Logsにログを出力する設定をオンにすると、突然セッションマネージャーでつなげなくなることでしょう。
これはなぜかというと、EC2インスタンスに設定してあるロールにログの出力先S3バケットや、出力先のCloudWatch Logsのロググループに対する書き込み権限がないからです。
セッションマネージャー側でうまいことやってくれるわけではなく、
明示的にインスタンスに設定したロールに権限を割り当てる必要があります。
具体的には下記のような権限が必要です。
バケット名、リージョン、アカウントID、ロググループ名は自分のものに修正してください。
万が一過不足あればご指摘ください。
前半がS3、後半がCloudWatch Logsに対して必要な書き込みの権限です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetEncryptionConfiguration",
"s3:PutObjectTagging",
],
"Resource": [
"arn:aws:s3:::<バケット名>/*",
"arn:aws:s3:::<バケット名>",
]
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:<リージョン>:<アカウントID>:log-group:<ロググループ名>*"
]
}
]
}
なお、CloudWatch LogsはS3に比べてログの保存料金が高いため、
CloudWatch Logsグループは自動作成されるものでなく自分で作成し、
明示的に保存期間を設定することをお勧めします。
また、暗号化したロググループを使用することも推奨します（KMSのキーが必要なため、KMSのキーの料金がかかります）。
参考：Amazon S3とCloudWatch Logsのログ保存料金とサイズを見てみた
長期保存の用途ではS3を使用しましょう。
S3に保存するときも、最低限SSE暗号化はしておくとよいです。
こちらはS3バケットの設定で可能です。
その他のハマりどころ
自分が遭遇したものや、他の記事で言及されているものを記載しておきます。
※備忘録の意味もあるため、あとで追記するかもしれません。
SSMのAPIへの経路が確保できていない
これは割とやってしまいがちです。
こちらの記事で3つのパターンが記載されています。
セッションマネージャーのハマりどころをパターンごとに整理してみる
書いていないものとして、
パブリックサブネットにあるインスタンスの場合パブリックIPがないとSSMのAPIが該当インスタンスを見つけられないことがあるようです。
ドキュメントや資料には「インバウンドのアクセス設定は不要」と書いてあり、
たしかにセキュリティグループでインターネットからのアクセスを絞っていてもSSMを使うことができます。
ただ、テストで適当なインスタンスを立てた時に、
パブリックIPなしで立ててしまってセッションマネージャーで入れなくて困る、
という現象に複数回遭遇しています。
パブリックサブネットにインスタンスを建てるときはEIPでなくてもよいので自動割当IPをちゃんと設定しましょう。
パブリックサブネットに立てる以上、普通は設定するはずですけどね…。
なぜパブリックサブネットのみかというと、
プライベートサブネットにあるインスタンスにセッションマネージャーでつなぎたい場合、
通常はNAT GatewayかVPCエンドポイントが設定してあるはずだからです。
上に貼ったハマりどころの記事に記載してあるところですね。
対して、パブリックサブネットでは通常NAT Gatewayを経由して通信はしませんし、
VPCエンドポイントもわざわざ設定することは少ないでしょう。
プライベートサブネットにあるインスタンスにセッションマネージャーで接続できない、というケースは貼った記事をご参照ください。
地味ですが気付かずにハマるポイントなので挙げさせていただきます。
終わりに
Systems Manager、あまり知られてない（自分も機能を把握しきれてない）ですが、便利なサービスなので活用していきましょう。
Discussion