AWS Systems Manager Automationを活用した運用Runbookの活用│Soy Pocket

こんにちはますのです。
AWS Summit Tokyo 2023のセッションの中でAWS Systems Managerに関するセッションを拝聴しました。

インシデントを起点に考える、システム運用のユースケースご紹介

こちらのセッションでは「インシデントが発生してから解決、分析するまでの流れ」をAWSのマネージドサービスで完結させる例を紹介していました。

影響判断
- インパクトの検出：CloudWatch Dashboard
診断
- ログの横断検索・分析：CloudWatch Logs insights
- イベントのクエリ：AWS CloudTrail Lake
緩和
- 定型処理の実現：SSM Automation
- 承認フローの追加：SSM Change Manager
- シェルアクセス：SSM Session Manager
分析
- 分析による改善を実現：Incident Manager 分析テンプレート

CloudWatchやSystems Managerのフル活用です。
扱ったことの無い機能も多々あるなか、今回はセッション内で紹介されていた「Runbookの活用」（Automation）を触ってみたいと思います。

1 SSM Automation を使ったオペレーションの省力化！

SSM オートメーションとは

EC2やRDS、S3など各種AWSマネージドサービスに対して、各種メンテナンスやデプロイ、修復に関するタスクをRunbookから実行する機能となります。

オートメーションは、AWS のサービス (Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Relational Database Service (Amazon RDS)、Amazon Redshift、Amazon Simple Storage Service (Amazon S3) など) でのメンテナンス、デプロイ、および修復に関する一般的なタスクを簡素化するための AWS Systems Manager の機能です。

引用：AWS Systems Manager Automation

AMIに最新のパッチを適用
EC2インスタンスのドライバアップグレード
SSH接続のトラブルシュート
セキュリティグループのSSH/RDPでパブリックアクセスが無いかチェックする

などなど。

どんなものがあるか興味のある方は、SystemsManagerのリファレンスから参照すると良いかもしれません。
Systems Manager Automation runbook reference

AutomationでRunbookを実行してみる

実際にどんな動きになるのか試してみようと思います。
今回は「AWSSupport-TroubleshootSSH」でSSH接続のトラブルシューティングがどのように動くか見ていきます。

実行手順は下記のナレッジセンター記事を参照

参考手順

AWS Systems Manager > オートメーション > [オートメーションの実行] をクリック
オートメーションドキュメント：[AWSSupport-TroubleshootSSH] を選択
入力パラメータで下記設定 > [実行] をクリック
- 対象のEC2インスタンスを選択
- Action：[FixAll] を選択

前提

EC2インスタンスは起動した状態である
Session Manager上からはssh接続が出来る状態である
sshd.serviceが起動していない状態である
実行結果は「出力」から確認する

検証１：sshdを「systemctl stop」で停止している場合

結果はsshdサービスは停止したままでした。

[root@ip-172-31-8-4 ~]# systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2023-05-04 12:25:06 UTC; 7s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 3095 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 3095 (code=exited, status=0/SUCCESS)

May 04 12:08:16 ip-172-31-8-4.ap-northeast-1.compute.internal systemd[1]: Starting OpenSSH server daemon...
May 04 12:08:16 ip-172-31-8-4.ap-northeast-1.compute.internal sshd[3095]: Server listening on 0.0.0.0 port 22.
May 04 12:08:16 ip-172-31-8-4.ap-northeast-1.compute.internal sshd[3095]: Server listening on :: port 22.
May 04 12:08:16 ip-172-31-8-4.ap-northeast-1.compute.internal systemd[1]: Started OpenSSH server daemon.
May 04 12:25:06 ip-172-31-8-4.ap-northeast-1.compute.internal systemd[1]: Stopping OpenSSH server daemon...
May 04 12:25:06 ip-172-31-8-4.ap-northeast-1.compute.internal systemd[1]: Stopped OpenSSH server daemon.

Automationのログで「[SUCCESS] All configuration checks passed or all detected problems fixed.」とあります。
しかし、サービスは起動せずssh接続は出来ない状態です。
サービス停止程度では異常とは判定しないようです。

troubleshootSSH.Output

Running EC2 Rescue for Linux
-----------[Backup  Creation]-----------
No backup option selected. Please consider backing up your volumes or instance
----------[Configuration File]----------
Configuration file saved:
/var/tmp/ec2rl/2023-05-04T12_25_40.773942/configuration.cfg
-------------[Output  Logs]-------------
The output logs are located in:
/var/tmp/ec2rl/2023-05-04T12_25_40.773942
--------------[Module Run]--------------
Running Modules:
openssh
----------[Diagnostic Results]----------
module run/openssh               [SUCCESS] All configuration checks passed or all detected problems fixed.
--------------[Run  Stats]--------------
Total modules run:               1
'diagnose' modules run:          1
    successes:                   1
    failures:                    0
    warnings:                    0
    unknown:                     0

----------------[NOTICE]----------------
Please note, this directory could contain sensitive data depending on modules run! Please review its contents!

検証２：「sshd_config」を削除（移動）した場合

今回はsshd_configを別名保存で退避しました。
検証１とは異なり、サービス起動が出来ない状況です。

結果は、sshd_configが新規作成されてsshdのサービスが起動した状態となりました。

[root@ip-172-31-8-4 ssh]# ls -la
total 616
drwxr-xr-x  2 root root        228 May  4 12:37 .
drwxr-xr-x 82 root root       8192 May  4 04:28 ..
-rw-r--r--  1 root root     581843 Jan 13  2022 moduli
-rw-r--r--  1 root root       2276 Jan 13  2022 ssh_config
-rw-------  1 root root       3957 May  3 07:57 sshd_config_bk
-rw-------  1 root ssh_keys    227 May  3 07:57 ssh_host_ecdsa_key
-rw-r--r--  1 root root        162 May  3 07:57 ssh_host_ecdsa_key.pub
-rw-------  1 root ssh_keys    387 May  3 07:57 ssh_host_ed25519_key
-rw-r--r--  1 root root         82 May  3 07:57 ssh_host_ed25519_key.pub
-rw-------  1 root ssh_keys   1679 May  3 07:57 ssh_host_rsa_key
-rw-r--r--  1 root root        382 May  3 07:57 ssh_host_rsa_key.pub

[root@ip-172-31-8-4 ssh]# systemctl start sshd
Job for sshd.service failed because the control process exited with error code. See "systemctl status sshd.service" and "journalctl -xe" for details

Result部分が先ほどの結果から追記があります。
「– FIXED Missing configuration file: /etc/ssh/sshd_config」

troubleshootSSH.Output

Running EC2 Rescue for Linux
-----------[Backup Creation]-----------
No backup option selected. Please consider backing up your volumes or instance
----------[Configuration File]----------
Configuration file saved:
/var/tmp/ec2rl/2023-05-04T12_43_20.984352/configuration.cfg
-------------[Output Logs]-------------
The output logs are located in:
/var/tmp/ec2rl/2023-05-04T12_43_20.984352
--------------[Module Run]--------------
Running Modules:
openssh
----------[Diagnostic Results]----------
module run/openssh [SUCCESS] All configuration checks passed or all detected problems fixed.
-- FIXED Missing configuration file: /etc/ssh/sshd_config
--------------[Run Stats]--------------
Total modules run: 1
'diagnose' modules run: 1
successes: 1
failures: 0
warnings: 0
unknown: 0
----------------[NOTICE]----------------
Please note, this directory could contain sensitive data depending on modules run! Please review its contents!

検証２で作成されたsshd_configを確認する

sshdサービスは起動されました。
さすがに自動起動の設定までは反映されず、disableのままとなります。

[root@ip-172-31-8-4 ssh]# systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: enabled)
Active: active (running) since Thu 2023-05-04 12:43:29 UTC; 5min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 3709 (sshd)
CGroup: /system.slice/sshd.service
└─3709 /usr/sbin/sshd -D

続いてsshd_configを確認します。
データの作成はされていますが、権限設定はroot以外でも読み取り可能な設定です。
また、「x」で実行権限も付与されているのでパーミッションの修正が必要です。

-rw-r-xr-x 1 root root 263 May 4 12:43 sshd_config
-rw------- 1 root root 3957 May 3 07:57 sshd_config_bk

sshd_configの中身を見てみましょう

[root@ip-172-31-8-4 ssh]# cat sshd_config
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes

Amazon Linux2のデフォルトで入っている設定とは若干異なる様子。
デフォルトのsshd_configで他に設定されていた設定は以下になります。

sshd_config_bk
---------------
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
----
X11Forwarding yes
----
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
----
Subsystem sftp /usr/libexec/openssh/sftp-server
----
AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f
AuthorizedKeysCommandUser ec2-instance-connect

「AcceptEnv」の環境変数周りが抜けているのが気になるところですが、一時復旧という意味では成功しました。
ですが、パーミッションやconfigファイルの中身に関しては確認したほうが良いということが分かりました。

Noticeの箇所にも「Please review its contents!」とある通り、修復は出来たものの修復箇所は改めて確認したほうが良さそうです。
実際に運用に利用する場合はAMIから復元して検証するなど既存への影響を考慮して、実運用には工夫が必要と感じます。

他にも色々とRunbookはあるので、AWS環境のお掃除やセキュリティチェックなどの運用で利用出来そうなものは検討の余地ありと感じました。
新たな運用方法を求めてもう少し模索していきたい所存です。

参考サイト

最新情報をチェックしよう！

フォローする

AWS Systems Manager Automationを活用した運用Runbookの活用

SSM オートメーションとは

おすすめRunbookの紹介

AutomationでRunbookを実行してみる

参考手順

前提

検証１：sshdを「systemctl stop」で停止している場合

検証２：「sshd_config」を削除（移動）した場合

検証２で作成されたsshd_configを確認する

参考サイト

SSM Automation を使ったオペレーションの省力化！

AWSの最新記事

特定のIPまたはVPCからのみ許可するS3バケットポリシーの設定

特定のS3バケットへの通信だけプライベート接続を実現したい

systemctl disableしてもcloud-initでサービスが起動して困ったお話

AWS Systems Manager Automationを活用した運用Runbookの活用