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

AWS IoT Greengrass V2 コアデバイスを非ルートに移行する

デフォルトでは、 は Linux デバイスでルートユーザーとして AWS IoT Greengrass 実行されます。 AWS IoT Greengrass コアデバイスを移行して、 が AWS IoT Greengrass 必要とする Linux 機能のみを持つ非ルートユーザーとして実行することで、デバイスのセキュリティ体制を改善できます。単一のデバイスを移行することも、フリート間で移行をスケールすることもできます。

考慮事項

非ルートに移行する前に、次の点を考慮してください。

単一のデバイスを移行する

この移行手順は、「」で説明されているアプローチに従います解決策 3: コンポーネントユーザーを分離して非ルート AWS IoT Greengrass V2 として設定する。開始する前に、そのトピックの前提条件を完了します。これには、非ルートユーザーがコンポーネントを個別のユーザーとして実行できるようにする sudoers 設定が含まれます。

フリートを移行する前に、この手順を使用して単一のデバイスを移行します。

ステップ 1: ルート以外のユーザーとグループを作成する

デバイスに接続し、 として AWS IoT Greengrass 実行されるシステムユーザーとグループを作成します。user-name と group-name を、使用する名前に置き換えます。

sudo groupadd --system group-name
sudo useradd --system --create-home --shell /sbin/nologin -g group-name user-name

ステップ 2: ファイルの所有権をバックアップする

現在のファイル所有権構造を停止 AWS IoT Greengrass して保存し、ロールバックする必要がある場合に復元できるようにします。

sudo systemctl stop greengrass.service
sudo mkdir -p /opt/greengrass-backup
sudo find /greengrass/v2 -exec stat -c 'chown %U:%G "%n"' {} \; | sudo tee /opt/greengrass-backup/restore_ownership.sh > /dev/null
sudo chmod 700 /opt/greengrass-backup/restore_ownership.sh

ステップ 3: ファイルの所有権を変更する

AWS IoT Greengrass ディレクトリの所有権を非ルートユーザーに転送します。

sudo chown -R user-name:group-name /greengrass/v2

ステップ 4: systemd ドロップインオーバーライドを作成する

必要な Linux 機能を持つ非ルートユーザー AWS IoT Greengrass として を実行するように systemd に指示するドロップインディレクトリと設定ファイルを作成します。

sudo mkdir -p /etc/systemd/system/greengrass.service.d

移行では、 で systemd ドロップインオーバーライドファイルを使用します/etc/systemd/system/greengrass.service.d/10-nonroot.conf。ドロップインオーバーライドは、ベースサービスファイルの設定を直接変更せずに置き換えます。このオーバーライドは、Linux 機能のセットが制限された非ルートユーザーとして AWS IoT Greengrass サービスを実行するように systemd を設定します。ドロップインディレクトリを削除すると、systemd は元の設定で root として実行されるベースgreengrass.serviceファイルに戻ります。

次の内容/etc/systemd/system/greengrass.service.d/10-nonroot.confで ファイルを作成します。

[Service]
User=user-name
AmbientCapabilities=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_AUDIT_WRITE
CapabilityBoundingSet=CAP_CHOWN CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_SETUID CAP_SETGID CAP_SYS_RESOURCE CAP_AUDIT_WRITE
ProtectSystem=strict
ReadWritePaths=/greengrass/v2 /tmp

これらの systemd ディレクティブと必要な機能の詳細については、「」を参照してください解決策 3: コンポーネントユーザーを分離して非ルート AWS IoT Greengrass V2 として設定する。

ステップ 5: systemd を再ロードして起動する AWS IoT Greengrass

次のコマンドを実行して systemd デーモンを再ロードし、起動します AWS IoT Greengrass。

sudo systemctl daemon-reload
sudo systemctl start greengrass.service

ステップ 6: 移行を検証する

AWS IoT Greengrass が非ルートユーザーとして実行されていることを確認します。

sudo systemctl status greengrass.service
ps -ef | grep greengrass

出力には、 ではなく、非ルートユーザーがプロセス所有者として表示されますroot。

次に、デプロイされたすべてのコンポーネントが実行されていることを確認します。このコマンドを実行するには、デバイスに aws.greengrass.Cli コンポーネントをデプロイする必要があります。

sudo /greengrass/v2/bin/greengrass-cli component list

各コンポーネントは、 RUNNINGまたは Stateをレポートする必要がありますFINISHED。 FINISHEDは、 の予想される終了状態ですaws.greengrass.Nucleus。移行が完了したとみなす前に、 BROKENまたは ERRORED状態のコンポーネントを調べます。

単一のデバイスをロールバックする

ルートとして実行 AWS IoT Greengrass するために復元する必要がある場合は、ドロップインオーバーライドを削除し、ファイルの所有権を復元して再起動します AWS IoT Greengrass。

sudo systemctl stop greengrass.service
sudo rm -rf /etc/systemd/system/greengrass.service.d
sudo bash /opt/greengrass-backup/restore_ownership.sh
sudo systemctl daemon-reload
sudo systemctl start greengrass.service

からステップ 6: 移行を検証する再度検証コマンドを実行して、 AWS IoT Greengrass がルートとして実行されていることを確認します。このプロセスは所有者rootとして表示されます。

ロールバックが成功したことを確認したら、オプションで移行アーティファクトをクリーンアップできます。

デバイスのフリートを移行する

単一のデバイスで移行を確認したら、フリート全体で移行をスケールできます。次のいずれかの方法を選択してください。

カスタム AWS IoT Greengrass ブートストラップコンポーネントを使用する

フリート全体の単一デバイス移行ステップを自動化するカスタム AWS IoT Greengrass コンポーネントを作成できます。このアプローチは自己完結型で、 AWS IoT Greengrass デプロイのみを使用します。Systems Manager などの外部ツールは必要ありません。

コンポーネントは、 を RequiresPrivilegeに設定してブートストラップライフサイクルを使用します。これはtrue、デプロイ中にコンポーネントをルートとして実行します。ブートストラップスクリプトは、単一デバイスプロシージャと同じ特権オペレーションを実行します。

すでにデバイスを移行している場合に再デプロイが失敗しないように、コンポーネントをべき等にします。

移行デプロイが完了したら、デバイスが非ルートユーザーとして実行されていることを確認します。詳細については、「ステップ 6: 移行を検証する」を参照してください。実行中のユーザーをチェックして結果をレポートする検証コンポーネントをデプロイすることも、 AWS IoT Greengrass コンソールでデプロイステータスをモニタリングすることもできます。

ロールバックメカニズムを設定する

フリート間でルート設定をリモートで復元するには、移行コンポーネントがロールバックメカニズムを設定する必要があります。1 つのアプローチは、systemd を使用してトリガーファイルをモニタリングすることです。このアプローチには、次の systemd リソースが必要です。

このメカニズムを使用すると、トリガーファイルを作成するシンプルな AWS IoT Greengrass コンポーネントをデプロイすることで、デバイスをロールバックできます。systemd パスユニットはファイルを検出し、ロールバックサービスをルートとして実行し、元のルート設定 AWS IoT Greengrass に復元します。

を使用する AWS Systems Manager

Systems Manager を使用してデバイスを管理する場合は、単一デバイスの移行ステップを自動化する SSM ドキュメントを作成できます。SSM は とは独立して実行されるため AWS IoT Greengrass、デバイスを再起動せずに AWS IoT Greengrass サービスを直接停止および再起動できます。

SSM ドキュメントは、次の要件を満たしている必要があります。

フリート間で移行を実行するには、Systems Manager Run Command を使用して、タグまたはリソースグループを使用してデバイスに対して SSM ドキュメントを実行します。Systems Manager コンソールでコマンド実行ステータスをモニタリングできます。このコンソールには、エラーを含む各ターゲットデバイスの結果が表示されます。

ロールバックするには、停止し AWS IoT Greengrass、ドロップインオーバーライドを削除し、元のファイルの所有権を復元し、systemd デーモンを再ロードして、ルート AWS IoT Greengrass として再起動する別の SSM ドキュメントを作成します。ロールバックする必要があるデバイスに対してこのドキュメントを実行します。

マネージドノードでコマンドを実行する方法の詳細については、「Systems Manager Run Command を使用したコマンドの実行」を参照してください。