SSM Agent テクニカルリファレンス - AWS Systems Manager
SSM Agent バージョン 3.2.x.x 認証情報の動作SSM Agent 認証情報の優先順位ローカル ssm-user アカウントについてSSM Agentと Instance Metadata Service (IMDS)保持 SSM Agent up-to-dateSSM Agent インストールディレクトリが変更、移動、削除されていないことの確認SSM Agent による ローリング更新 AWS リージョンVM とオンプレミスインスタンスでの SSM Agent のインストールハードウェアフィンガープリントを使用したハイブリッドアクティベーションマシンの検証SSM AgentGitHub での

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SSM Agent テクニカルリファレンス

このトピックの情報は、 AWS Systems Manager エージェント (SSM Agent) を実装し、エージェントの仕組みを理解するのに役立ちます。

SSM Agent バージョン 3.2.x.x 認証情報の動作

インスタンスが、Quick Setup のデフォルトのホスト管理設定を使用してオンボーディングされた場合、SSM Agent は一時的な認証情報のセットを /var/lib/amazon/ssm/credentials (Linux と macOS の場合)、または %PROGRAMFILES%\Amazon\SSM\credentials (Windows Server の場合) に格納します。一時的な認証情報には、デフォルトのホスト管理設定で選択した IAM ロールに指定した許可が含まれます。Linux では、これらの認証情報にアクセスできるのは、root アカウントだけです。Windows Server では、SYSTEM アカウントとローカル管理者のみがこれらの認証情報にアクセスできます。

SSM Agent 認証情報の優先順位

このトピックは SSM Agent がリソースにアクションを実行するためにどのようにアクセス許可が付与されるか、重要な情報について説明します。

注記

エッジデバイスのサポートは少し異なります。 AWS IoT Greengrass Core ソフトウェアを使用するようにエッジデバイスを設定し、 AWS Identity and Access Management (IAM) サービスロールを設定し、 を使用してSSM Agentデバイスにデプロイする必要があります AWS IoT Greengrass。詳細については、「エッジデバイス用に AWS Systems Manager のセットアップ」を参照してください。

SSM Agent がマシンにインストールされている場合、Systems Manager サービスと通信するには許可が必要です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスでは、このようなアクセス許可は、インスタンスにアタッチされたインスタンスプロファイルで提供されます。非 EC2 マシンの場合、SSM Agent は通常、必要な許可を共有認証情報ファイルから取得し、/root/.aws/credentials (Linux と macOS) または %USERPROFILE%\.aws\credentials (Windows Server) に保存されています。必要な許可は、ハイブリッドアクティベーションプロセス中にこのファイルに追加されます。

ただし、まれに、SSM Agent がタスクを実行するための許可をチェックする複数の場所に、マシンの許可が追加されてしまうことがあります。

例えば、Systems Manager によって管理されるように EC2 インスタンスを設定したとします。その設定にはインスタンスプロファイルのアタッチが含まれます。しかし、そのインスタンスをデベロッパーまたはエンドユーザーのタスクにも使用し、そのインスタンス に AWS Command Line Interface (AWS CLI) をインストールすることにしました。このインストールでは、インスタンス上の認証情報ファイルに追加のアクセス許可が追加されます。

インスタンスで Systems Manager コマンドを実行すると、SSM Agent は、インスタンスプロファイルではなく認証情報ファイルからの認証情報など、使用する想定とは異なる認証情報を使用しようとすることがあります。これは、SSM Agent がデフォルトの資格情報プロバイダーチェーンに規定された順序で資格情報を検索するためです。

注記

Linux と macOS では、SSM Agent はルートユーザーとして実行されます。したがって、このプロセスで SSM Agent が検索する環境変数と認証情報ファイルは、ルートユーザーのみのものです (/root/.aws/credentials)。SSM Agent は、認証情報の検索中に、インスタンス上の他のユーザーの環境変数や認証情報ファイルを参照しません。

デフォルトのプロバイダーチェーンは、次の順序で認証情報を検索します。

  1. 環境変数 (設定されている場合) (AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY)。

  2. ハイブリッド環境のアクティベーションや AWS CLI のインストールなどによって提供されるアクセス許可を持つ共有認証情報ファイル (Linux と macOS の場合は $HOME/.aws/credentials、Windows Server の場合は %USERPROFILE%\.aws\credentials)。

  3. Amazon Elastic Container Service AWS Identity and Access Management (Amazon ECS) タスク定義または RunTask API オペレーションを使用するアプリケーションが存在する場合のタスクの (IAM) ロール。

  4. Amazon EC2 インスタンスにアタッチされたインスタンスプロファイル。

  5. デフォルトのホスト管理構成用に選択された IAM ロール。

関連情報については、次のトピックを参照してください。

ローカル ssm-user アカウントについて

SSM Agent バージョン 2.3.50.0 以降では、エージェントは ssm-user という名前のローカルユーザーアカウントを作成し、/etc/sudoers.d ディレクトリ (Linux と macOS) または、管理者グループ (Windows Server) に追加します。2.3.612.0 より前のエージェントバージョンでは、アカウントはインストール後に SSM Agent が最初に起動または再起動するときに作成されます。バージョン 2.3.612.0 以降では、ssm-user アカウントは、インスタンスでセッションが最初に開始されたときに作成されます。これは、 Session Managerの一機能である でセッションが開始されたときのデフォルトの OS ユーザーssm-userです AWS Systems Manager。ssm-user を特権の少ないグループに移動するか、sudoers ファイルを変更することで、アクセス許可を変更できます。SSM Agent がアンインストールされるときに、ssm-user アカウントはシステムから削除されません。

Windows Server では、SSM Agent は各セッションの開始時に ssm-user アカウントの新しいパスワードの設定を処理します。Linux マネージドインスタンスで ssm-user にはパスワードは設定されていません。

SSM Agent 2.3.612.0 バージョンから、ssm-user アカウントは、ドメインコントローラーとして使用されている Windows Server マシンに自動的には作成されません。Session Manager ドメインコントローラーで Windows Server を使用するには、ssm-user アカウントが存在しない場合は手動でアカウントを作成し、ドメイン管理者のアクセス許可をユーザーに割り当てます。

重要

ssm-user アカウントを作成するには、インスタンスに添付されたインスタンスプロファイルによって、必要なアクセス許可が付与される必要があります。詳細については、「ステップ 2: Session Managerのインスタンスのアクセス権限の確認または追加」を参照してください。

SSM Agentと Instance Metadata Service (IMDS)

Systems Manager の正常な機能は、EC2 インスタンスメタデータに左右されます。Systems Manager は、Instance Metadata Service (IMDSv1 および IMDSv2) のバージョン 1 またはバージョン 2 を使用して、インスタンスメタデータにアクセスできます。インスタンスはインスタンスメタデータサービスの IPv4 アドレスにアクセスできる必要があります: 169.254.169.254。詳細については、「Amazon EC2 User Guide for Linux Instances」(Linux インスタンス用 Amazon EC2 ユーザーガイド) の「Instance metadata and user data」(インスタンスメタデータとユーザーデータ) を参照してください。

保持 SSM Agent up-to-date

新しい機能が Systems Manager に追加されるか、既存の機能が更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「SSM Agent への更新の自動化」を参照してください。のSSM AgentリリースノートページにサブスクライブGitHubして、SSM Agent更新に関する通知を受け取ります。

注記

新しい機能が Systems Manager に追加されるか、既存の機能が更新されると必ず、更新されたバージョンの SSM Agent がリリースされます。最新バージョンのエージェントを使用しないと、マネージドノードが Systems Manager の各種機能を使用できなくなる可能性があります。このため、マシン上で SSM Agent を最新状態に維持するプロセスを自動化することをお勧めします。詳細については、「SSM Agent への更新の自動化」を参照してください。のSSM AgentリリースノートページにサブスクライブGitHubして、SSM Agent更新に関する通知を受け取ります。

デフォルトで SSM Agentが含まれている Amazon Machine Images (AMIs) は、最新バージョンの SSM Agentで更新されるまでに最大 2 週間かかります。SSM Agent に対するさらに頻繁な自動更新を設定することをお勧めします。

SSM Agent インストールディレクトリが変更、移動、削除されていないことの確認

SSM Agent は /var/lib/amazon/ssm/ (Linux と macOS) および %PROGRAMFILES%\Amazon\SSM\ (Windows Server) にインストールされます。これらのインストールディレクトリには、認証情報ファイル、プロセス間通信 (IPC) 用リソース、オーケストレーションフォルダなど、SSM Agent が使用する重要なファイルやフォルダが含まれています。インストールディレクトリ内のものは変更、移動、削除しないでください。そうでないと、SSM Agent が正しく機能しなくなる可能性があります。

SSM Agent による ローリング更新 AWS リージョン

SSM Agent 更新がGitHubリポジトリで利用可能になってから、更新されたバージョンがすべての に異なる時間にロールアウトされるまで、最大 2 AWS リージョン 週間かかる場合があります。このため、SSM Agentリージョンに の新しいバージョンをデプロイしようとすると、「現在のプラットフォームでサポートされていない」または「古いバージョン amazon-ssm-agent への更新」エラーが表示される場合があります。

使用可能な SSM Agent のバージョンを確認するには、curl コマンドを実行します。

グローバルダウンロードバケットで利用できるエージェントのバージョンを表示するには、次のコマンドを実行します。

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

特定のリージョンで使用可能なエージェントのバージョンを表示するには、次のコマンドを実行します。region を(米国東部 (オハイオ) リージョンでは us-east-2 などの作業しているリージョンに置き換えます。

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

VERSION コマンドなしでブラウザで curl ファイルを直接開くこともできます。

VM とオンプレミスインスタンスでの SSM Agent のインストール

ハイブリッドおよびマルチクラウド環境用の非 EC2 マシンへの SSM Agent のインストールの詳細については、「ハイブリッド環境用の SSM Agent のインストール (Linux)」および「ハイブリッド環境用の SSM Agent のインストール (Windows)」を参照してください。

ハードウェアフィンガープリントを使用したハイブリッドアクティベーションマシンの検証

ハイブリッドおよびマルチクラウド環境で非 EC2 を実行する場合、SSM Agent は多数のシステム属性 (ハードウェアハッシュと呼ばれます) を収集し、これらの属性を使用してフィンガープリントを計算します。フィンガープリントは、エージェントが特定の Systems Manager API に渡す不透明な文字列です。この固有のフィンガープリントは、発信者を特定のハイブリッドアクティベーションマネージドノードに関連付けます。エージェントは、フィンガープリントとハードウェアハッシュをローカルディスク上の Vault と呼ばれる場所に保存します。

エージェントは、マシンが Systems Manager で使用するために登録されると、ハードウェアハッシュとフィンガープリントを計算します。エージェントが RegisterManagedInstance コマンドを送信すると、フィンガープリントが Systems Manager サービスに戻されます。

その後、RequestManagedInstanceRoleToken コマンドを送信するときに、エージェントは Vault 内のフィンガープリントとハードウェアハッシュをチェックして、現在のマシン属性が保存されているハードウェアハッシュと一致することを確認します。現在のマシン属性が Vault に保存されているハードウェアハッシュと一致する場合、エージェントはフィンガープリントを Vault から RegisterManagedInstance に渡し、呼び出しが成功します。

現在のマシン属性が保存されているハードウェアハッシュと一致しない場合、SSM Agent は新しいフィンガープリントを計算し、新しいハードウェアハッシュとフィンガープリントを Vault に保存し、新しいフィンガープリントを RequestManagedInstanceRoleToken に渡します。これにより RequestManagedInstanceRoleToken が失敗し、エージェントは Systems Manager サービスに接続するためのロールトークンを取得できません。

この障害は設計上のものであり、複数のマネージドノードが同じマネージドノードとして Systems Manager サービスと通信することを防ぐための検証手順として使用されます。

現在のマシン属性を Vault に保存されているハードウェアハッシュと比較すると、エージェントは次のロジックを使用して、古いハッシュと新しいハッシュが一致するかどうかを判断します。

  • SID (システム/マシン ID) が異なる場合は、一致しません。

  • 同じ場合は、IP アドレスが同じであれば一致します。

  • それ以外の場合は、一致するマシン属性の割合が計算され、ユーザー設定の類似度しきい値と比較され、一致があるかどうかが判断されます。

類似度のしきい値は、ハードウェアハッシュの一部として Vault に保存されます。

類似度のしきい値は、インスタンスの登録後に次のようなコマンドを使用して設定できます。

Linux マシンの場合:

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

を使用するWindows Serverマシンの場合 PowerShell：

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1
重要

フィンガープリントの計算に使用されるコンポーネントの 1 つが変更されると、エージェントが休止状態になる可能性があります。この休止状態を回避するには、類似度のしきい値を低い値 (1 など) に設定します。

SSM AgentGitHub での

のソースコードSSM Agentは で利用できるGitHubため、ニーズに合わせてエージェントを調整できます。含めることを希望する変更について、プルリクエストを送信することをお勧めします。ただし、Amazon Web Services はこのソフトウェアの変更されたコピーの実行をサポートしていません。