本記事はAWS Systems managerの触りということで、以下をご紹介していきます。
- ssm agentインストール
- マネージドインスタンスの一覧表示
- インベントリ管理
- リモート接続
- Runコマンド
※前提：Windows Server、外部通信は社内プロキシ経由。
以下、目次となります。
マネージドインスタンス
EC2がsystems managerのコントロール配下（マネージドインスタンス）になるためには、該当EC2にssm agentのインストール等が必要です。
基本的な要件は次の通りです。
- ssm agentがインストールされていること。
- ssm agentがインターネット通信出来ること。
- EC2がsystem managerへのアクセス権「AmazonSSMManagedInstanceCore」を有していること（IAMロール設定）。
ssm agentのインストール及びプロキシ設定
ssm agentはAmazonオフィシャルのAMIを使った場合やオンプレから移行した場合は、最初から入っていることも多いです。入っていない場合は次のpowershellコマンドでインストールします。
# ダウンロード
Invoke-WebRequest -Uri https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/windows_amd64/AmazonSSMAgentSetup.exe -OutFile $env:USERPROFILE\Desktop\SSMAgent_latest.exe
# インストール
Start-Process -FilePath $env:USERPROFILE\Desktop\SSMAgent_latest.exe -ArgumentList "/S"続いて、プロキシ経由でインターネット通信出来るようにします。
# URL:PORTは環境に合わせて書き換え。
$serviceKey = "HKLM:\SYSTEM\CurrentControlSet\Services\AmazonSSMAgent"
$keyInfo = (Get-Item -Path $serviceKey).GetValue("Environment")
$proxyVariables = @("http_proxy=URL:PORT", "no_proxy=169.254.169.254")
If($keyInfo -eq $null)
{
New-ItemProperty -Path $serviceKey -Name Environment -Value $proxyVariables -PropertyType MultiString -Force
} else {
Set-ItemProperty -Path $serviceKey -Name Environment -Value $proxyVariables
}
# SSM Agent再起動
Restart-Service AmazonSSMAgent※IGW利用やVPCエンドポイントやNATゲートウェイでインターネットと通信出来る場合は、プロキシ設定不要です。
マネージドインスタンスの一覧表示
IAMロール設定（AmazonSSMManagedInstanceCore）は省略しますが、SSM Agentの要件が満たされていれば、system managerのマネージドインスタンスに表示されます。
AWS Systems Manager → フリートマネージャーに表示されればOK。
インベントリの収集・検索
マネージドインスタンスからは、インベントリ（アプリ、サービス、アップデート情報・・・）などを収集することが出来ます。最初に収集するための設定（セットアップインベントリ）が必要で、基本的にデフォルトのままでもOKです。
- 対象インスタンスは指定可能
- 収集間隔はデフォルト30分
- レジストリ情報の収集も可能（追加設定要）
- ファイル情報の収集も可能（追加設定要）
設定後、暫くするとEC2の各情報がSystems Managerのインベントリ情報に集められます。
個別のインスタンス情報より、各種情報を確認することも出来ますし、インベントリのトップ画面から任意アプリがインストールされたEC2を簡単に検索することも出来ます。
何が嬉しいのか？
例えば、脆弱性の含まれる「アプリ」や「バージョン」が含まれるEC2の検索が非常に簡単です。この手段を使わない場合は、別途管理簿で管理するか、1台1台EC2にログインして確認といった手間のかかる操作になるでしょう。
リモート接続（session manager）
マネージドインスタンスであり、該当IAMユーザに権限があれば、AWSマネジメントコンソール上からリモート接続を行うことが可能です。
- リモートデスクトップは不要です。
- RDPのインバウンド接続不要です。
- 接続ユーザはssm-userです。
セッションを開始すると、パスワード不要でPowerShellのプロンプトが表示されます。以下では試しに「pwd」や「whoami」のコマンドを実行しています。
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
PS C:\Windows\system32> pwd
Path
----
C:\Windows\system32
PS C:\Windows\system32> whoami
hostname\ssm-userEC2サービスからも「接続」メニューより同じようにセッションを始めることが出来ます。このようにパスワード不要で入れてしますため、IAMユーザの権限には注意しましょう。
Runコマンド
該当EC2に対して任意コマンド実行が可能です。
Runコマンドは「非同期」実行です。実行後の結果は後から確認する必要があります。結果の各種手段はSystems manager、S3、CloudWatch logsがあります。
Systems managerから発行
Systems managerの管理画面からコマンドを実行することが出来ます。
- コマンド実行結果はマネジメントコンソールから確認可能（最大4万8000文字）
- コマンド実行結果はS3にも保存可能（上限無し）
- 実行先EC2は個別または複数が選択可能。
Systems ManagerのRun Commandメニューへ進み、Windows Serverの場合はコマンドドキュメント「AWS-RunPowerShellScript」を選択します。
続いて、コマンドやS3保存の有無を選択して、実行していきます。
もしも日常的にログインしてコマンドを複数EC2に発行しているのであれば、こちらのRun Commandを使うことで楽になりそうです。今回は割愛しますが、AWS EventBrdigeと組み合わせることで、定期的な自動実行も可能です。
AWS CLIから発行してみる
以下の順でご紹介します。
- run command発行
(aws ssm send-commad) - run command結果確認
(list-command-invocations)
次のように実行するとコマンドの受付結果、命令IDなどが返ってきます。
aws ssm send-command \
--instance-ids "i-1234567890" \
--document-name "AWS-RunPowerShellScript" \
--parameters 'commands=["pwd","whoami"]'# 結果例（一部抜粋）
{
"Command": {
"CommandId": "xxx-xxx-xxx-xxx",
"DocumentName": "AWS-RunPowerShellScript",
"DocumentVersion": "$DEFAULT",
"Comment": "",
"ExpiresAfter": "2022-08-30T09:04:27.695000+00:00",
"Parameters": {
"commands": [
"pwd",
"whoami"
]
},
}非同期コマンドのため、実際の実行結果は後から別のコマンドで確認します。受付時の命令IDを引数にして次のように実行します。
aws ssm list-command-invocations --command-id xxx-xxx-xxx-xxx --details# 結果例（一部抜粋）
{
"CommandInvocations": [
{
"CommandId": "xxx-xxx-xxx-xxx",
"InstanceId": "i-1234567890",
"InstanceName": "xxxxx",
"Comment": "",
"DocumentName": "AWS-RunPowerShellScript",
"DocumentVersion": "$DEFAULT",
"RequestedDateTime": "2022-08-30T06:35:53.833000+00:00",
"Status": "Success",
"StatusDetails": "Success",
"StandardOutputUrl": "",
"StandardErrorUrl": "",
"CommandPlugins": [
{
"Name": "aws:runPowerShellScript",
"Status": "Success",
"StatusDetails": "Success",
"ResponseCode": 0,
"ResponseStartDateTime": "2022-08-30T06:35:54.270000+00:00",
"ResponseFinishDateTime": "2022-08-30T06:35:55.240000+00:00",
"Output": "\r\nPath \r\n---- \r\nC:\\Windows\\system32 \r\nnt authority\\system\r\n\r\n\r\n",
"StandardOutputUrl": "",
"StandardErrorUrl": "",
"OutputS3Region": "ap-northeast-1",
"OutputS3BucketName": "",
"OutputS3KeyPrefix": ""
}
],
}
]
}なお、コマンドが実行中だとStatusは「InProgress」になります。一連の流れで結果を取得したい場合は、Statusをポーリングしながら結果を確認する必要があります。
AWS CLI＠ssmに関する公式情報は以下の通りです。
https://docs.aws.amazon.com/cli/latest/reference/ssm/
(参考) Inspector
Run Commandまでセットアップ出来ていれば、「AWS Inspector」も簡単に走らせることが出来ます（内部的にはRun Commandを利用するため）
※「AWS Inspector」とはEC2内の基本ソフトウェアやミドルウェア等の脆弱性を診断してくれるサービスです。Inspectorはデフォルト無効ですが、有効にすれば、管理下のEC2に対して自動で脆弱性診断をサクサク実施してくれます（無料期間あります）。
(参考) SSM Agentが起動しない
EC2をAMI化して再デプロイしたところ、フリートマネージャ―に表示されなかった。SSM Agentのログ（C:\ProgramData\Amazon\SSM\Logs）を確認すると、以下のエラーが発生していた。
ERROR failed to find identity, retrying: failed to find agent identity
INFO Checking if agent identity type OnPrem can be assumed
INFO Checking if agent identity type EC2 can be assumed
ERROR [EC2Identity] failed to get identity instance id. Error: RequestError: send request failed
caused by: Get "http://169.254.169.254/latest/meta-data/instance-id": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
INFO Checking if agent identity type CustomIdentity can be assumed
ERROR Agent failed to assume any identity
ERROR failed to get identity: failed to find agent identity
ERROR Failed to start agent. failed to get identity: failed to find agent identityメタデータにアクセス出来ないようです。
上の記事に沿って、powershellから以下を実行したところ、無事に解消しました。
Import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1 ; Add-Routes※初回起動時に静的ルートのクリーンアップまではしてくれないのですね・・・。
まとめ
今回はsystems mangerの基本的なところに触れました。systems manger自体の利用は無償のため、積極的に使っていけば、管理効率を上げれるでしょう。今後はsystems mangerを利用したwindows patchの自動化（patch manager）についても触れていく予定です。
最後までご覧いただきありがとうございました。
コメント