目次

はじめに

ここではAzure IoT Edgeコンテナを利用してiPRO Camera SDKアプリのビルドし、動作確認する手順を説明します。また、このチュートリアルではSDKのインストールディレクトリを${SDK_DIR}として記載します。

動作確認手順

Visual Studio Code上で新規のIoT Edge Solutionを作成する

以下は参考にするサンプルアプリがC版はskeleton_sample_app、Python版はadditional_info_sample_app、作成するEdge Solutionがtest_appの場合について説明します。注意点としてEdge Solutionの名称はすべて小文字である必要があります。詳細は下記を参照ください。
https://docs.docker.jp/engine/reference/commandline/tag.html

C版/Python版アプリの説明

[SDKフォルダ]直下でVisual Studio Codeを立ち上げます。

${SDK_DIR}/src/adamapp/skeleton_sample_app フォルダを同じフォルダ内にコピーします。

Open

コピーしたフォルダをtest_appにリネームします。

[コピーしたフォルダ]/container/modules の「skeleton_sample_app」フォルダもtest_appにリネームします。

Visual Studio CodeのEXPLORERからコピーしたフォルダ(test_app)を右クリックし、「Find in Folder…」を選択し、SEARCHウィンドウを表示します。

Open

検索で「skeleton_sample_app」を検索しすべて「test_app」に置き換えます。対象は以下となります。

• ${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json

• ${SDK_DIR}\src\adamapp\test_app\container\modules\test_app\module.json

作成したイメージをプッシュするコンテナレジストリの情報を入力します。

開発環境構築において、i-PRO が運営するコンテナレジストリを利用される場合、以下の説明にある各項目は下表の値をご利用ください。 ご自身でコンテナレジストリを用意する場合は、使用するコンテナレジストリのドキュメントを参照し値を取得してください。

取得した情報をもとに、以下を入力します。

• ${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json
  内の “registryCredentials” を以下のように入力します。

  "registryCredentials": { "[コンテナレジストリ名]": { "username": "$CONTAINER_REGISTRY_USERNAME_[コンテナレジストリ名]", "password": "$CONTAINER_REGISTRY_PASSWORD_[コンテナレジストリ名]", "address": "[ログインサーバー]" } }

  例えば i-PRO が運営するコンテナレジストリの場合は以下のようになります。 

• ${SDK_DIR}\src\adamapp\test_app\container\modules\test_app\module.json
  内の “repository” を以下のように入力します。

  "repository": "[ログインサーバー]/[リポジトリ名]/test_app"

  例えばコンテナレジストリログインサーバーが iprocamsdk.azurecr.io、リポジトリ名が dev/company-aの場合は以下のようになります。

• ${SDK_DIR}\src\adamapp\test_app\container
  ディレクトリ内に.envファイルを作成し、コンテナレジストリのユーザー名、パスワードを記載して保存します。

  例を以下に示します。

アプリのコーディング

このままVisual Studio Code上で任意にコーディングを行います。

skeleton_sample_appなどをコピーした場合、ソースファイル名がコピー前 (skeleton_sample_appの場合はskeletonSampleApp.cpp) になっているので必要に応じてリネームしてください。下記は一例です。

Makefile内のSRC_FILESも必要に応じて修正してください。下記は一例です。

Makefile内のPROG_NAME、configuration.txt内のAPPLICATION、deployment.template.json内のAPPLICATION_NAMEも必要に応じて修正してください。下記は一例です。

アプリのビルド

ビルドを行う際はAzure IoT拡張機能の組込み機能を使用します。Visual Studio Codeのエクスプローラで
${SDK_DIR}\src\adamapp\test_app\container\deployment.template.jsonを右クリックするとビルドメニューが表示されます。

「Build IoT Edge Solution」を選択します。この操作ではビルドのみ実施されます。

SDKで提供しているDockerfile では、i-PRO コンテナレジストリ上からイメージを取得してイメージのビルドを行いますので、初回のビルドの場合は、コンテナレジストリへのログインが要求されます。 以下はエラーメッセージの例です。

この時はVisual Studio Codeの端末上で下記コマンドを入力します。

続いて表示されるUsernameおよび Passwordを入力します。コンテナレジストリのIDとパスワードを入力します。i-PROのコンテナレジストリを利用する場合は、通知されたユーザー名・パスワードでログインしてください。

独自のコンテナレジストリを利用する場合は、以下を入力してください。

Login Succeeded と表示されたらログイン成功です。

次に${SDK_DIR}\src\adamapp\test_app\container\deployment.template.jsonを右クリックして、
「Build and Push IoT Edge Solution」を選択します。この操作ではビルドとコンテナレジストリへのプッシュを行います。

ビルドは、${SDK_DIR}\src\adamapp\test_app\ 以下にある Dockerfile.azureIoT ファイルに記載の通りにDocker buildx buildが実行されることで行われます。Dockerfile.の後の環境名(arm64v8)は上記の手順で選択されたアーキテクチャが選択されています。(Visual Studio Codeの下部に現在のアーキテクチャが表示されます）

ビルドしたイメージの確認

ビルドが成功すれば、そのイメージは docker images で存在が確認できます。下記は一例です。

カメラへのデプロイ

左下の「AZURE IOT HUB」以下からデプロイしたいデバイスを選択し、右クリックして「1つのIoT Edgeに配置」を選択することで、カメラへデプロイされます。デプロイする内容は
${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json に従います。

Visual Studio Codeの上部にプルダウンが表示されるので下記を選択します。
${SDK_DIR}\src\adamapp\test_app\container\config\deployment.arm64v8.json

Deployment Succeeded と表示されたらデプロイ成功です。

Azure上でランタイム状態の確認

Azure Portal にログインして、IoT Hub - IoT Edge画面で追加したIoT Edgeデバイスを選択します。

画面下部に表示されているデプロイしたアプリのランタイムの状態を確認します。「running」になっていればエラーが発生していない状態です。「エラー」と表示されている場合は選択するとエラーメッセージが表示されるので、デバッグしてください。

アプリの動作確認

カメラと接続可能なPCで下記URLにアクセスします。

カメラの応答が表示されます。下記は一例です。

"installId": "124B569A",と表示されている情報を使います。

下記のURLにアクセスします。

カメラのIPアドレスが192.168.100.33、"installId": "124B569A",の場合は下記になります。

下記のようにアプリ動作を確認できます。下記はskeleton_sample_appを動作させた例です。

Azure IoT Explorerを用いたContainer版Adamappの制御

マイクロソフトが公開している、Azure IoT Explorerを使って、Container版Adamappの制御や確認が可能です。以下では、Azure IoT Exporlorのインストールと初期設定について記載します。

インストール

Azure IoT エクスプローラーをインストールして使用する - Azure IoT に従い、PCにAzure IoT Explorerをインストールします。

初期設定

Azure IoT Explorerを起動すると、以下のような初期画面が出るので、「Connect via IoT Hub connection string」を選択します。

「Add connection」を選択します。

ホーム - Microsoft Azure にアクセスして、接続したいIoT Hubを選択します。以下の例では CV5xIoTHub2を選択しています。

左側メニューの 「セキュリティ設定」 → 「共有アクセス ポリシー」を選択します。

「共有アクセス ポリシーの管理」のリストから「iothubowner」をクリックします。

プライマリ接続文字列 の右側のコピーボタンを押して文字列をクリップボードにコピーします。

 Azure IoT ExplorerのConnection string 枠内に貼り付け、Saveボタンを押します。

IoT Hubの情報が読み込まれ、デバイス一覧が表示されます。

表示されたデバイス (カメラ) リストから、確認したいデバイスを選択します。

ModuleTwinによる設定値の確認

アプリの設定値 (AppPrefs.json) に記載した設定値は、Azure IoTのModuleTwinという仕組みを使用してクラウドから確認できます。

モジュールツインについては、Azure IoT Hub モジュール ツインについて | Microsoft Learn をご参照下さい。

Azure IoT Explorerで確認したいデバイス (カメラ) を選択します。

左側のメニューから「Module identities」 を選択します。

現在カメラで動作しているコンテナ (Module) 一覧が表示されます。設定値を確認したいコンテナ名をクリックします。

対象のコンテナのページが表示されます。再び左のメニューから 「Module twin」を選択します。

対象のコンテナの情報がjson形式で表示されます。appPrefs.jsonに記載した情報は、”properties”.”reported”.”aplField”.”preference” 内に表示されます。

動作スケジュールの設定

アプリケーションを動作する時間帯を ModuleTwinを使用して設定します。

「ModuleTwinによる設定値の確認」章と同様、対象のコンテナのModule Twin情報を表示します。

“properties”.”desired”.“scheduleField” に以下フォーマットに従ってスケジュールを設定します。

フォーマットは以下です。 三つのフィールドで一つの設定を表します。

各項目の仕様は以下となります。

設定例を以下に示します。

この場合、 日曜日～木曜日、土曜日は08:00:00 ~ 20:00:59 の間、金曜日は 03:00 ~ 23:59:59 の間動作する設定となります。

• 入力後は画面上部の「Save」を押すことでカメラに設定が反映されます。

• 最大8個まで設定可能です。

• 設定されたいずれかの時間内である場合、Container AdamApp for Azure IoT Edgeが動作します。

• 推論終了時間が推論開始時間よりも後の場合、推論終了時間は次の日を表します。

• scheduleFieldが空の場合は常時動作となります。

• 記載内容が不正の場合、アプリケーションは起動しません。

• 停止・開始の判断は15秒間隔で実施されます。したがって、開始・停止時刻は最大15秒の遅延が発生します。

デバイスからクラウド通信によるテレメトリデータの送信

テレメトリデータの送信

• Container AdamApp for Azure IoT Edgeのみ有効な ADAM_SendTelemetry() 関数を呼び出すことでデバイスtoクラウド通信によるテレメトリデータを送信することができます。

• このAPIの引数にはJSON形式で値を指定してください。詳細はAPI仕様書をご覧ください。

• デバイスtoクラウド通信はAzure IoT Hubの設定により通信回数に制限があります。詳細は、Azure IoT Hub クォータと調整について | Microsoft Learn をご確認ください。

• 通信を制御するために、デフォルトでは送信をOFFに設定しています。クラウドに送信するためにはまず送信機能をONにする必要があります。

• 送信機能をONにする方法は Module direct method 及び Module twin desired property の二つの方法があります。以下をご参照ください。

Module direct methodでONにする方法

Azure IoT Explorerで対象の Container Adamapp for Azure IoT Edgeを選択します。

左側メニューから「Module direct method」を選択します。以下の画面でダイレクトメソッドが送信できます。

 
Method name欄にメソッド名”setTelemetry” を入力します。
Payload欄に送信データをJSON形式で以下のように入力します。

「Invoke method」を押下すると、カメラに対してダイレクトメソッドが実行されます。

結果はポップアップ表示される。statusが200になっていれば成功です。

Module twin desired propertyで設定する方法

Azure IoT Explorerで対象のContainer Adamapp for Azure IoT EdgeのModule twinを表示します。

“properties”.”desired”.”aplFileld” 内に以下のように設定します。

画面上部の　「Save」を押下すると反映されます。

設定値を確認する方法

設定値は、Module twinで確認できます。”properties”.”reported”.”aplField”.”azureSettings”.”telemetry” の値を確認してください。

受信したテレメトリデータの確認

Azure IoT Explorerで対象のContainer Adamapp for Azure IoT Edgeを選択します。

左側のメニューから「Telemetry」を選択します。

「Start」ボタンを押下します。テレメトリデータの受信待ち状態となります。

アプリのADAM_SendTelemetry()で送信されたテレメトリを受信すると、ウィンドウ内に表示されます。ADAM_SendTelemetryに設定した文字列は、payloadキーの値として設定されます。

ログの確認方法

アプリのログ

アプリ内でADAM_DEBUG_PRINT()によって出力されるメッセージや、アプリからリンクしているライブラリが出力するログを見ることができます。エラーとなった場合も確認が可能です。

• ホーム - Microsoft Azure にアクセスします。

• 対象のIoT Hubを選択します。

• 左側の「デバイス管理」「IoT Edge」から対象のカメラを選択します。

• 下のモジュールのリストからログを見たいアプリ名の「ランタイムの状態」のリンクをクリックします。

カメラのpflog

カメラ内のログを確認することで、Container Adamapp for Azure IoT Edgeが正しく動作していない場合の動作解析を行うこともできます。ログ取得方法は下記の実行ボタンより取得可能です。

複数あるログファイルのうち、Container Adamapp for Azure IoT Edgeに関連の高いログファイルを紹介します。

• cadam (ファイル名が pf_cadam, pf_cadamCgi から始まるファイル)
  cadamはContainer Adamapp for Azure IoT Edgeの管理をするプロセスとなります。

• Azure IoT Edgeランタイム (ファイル名が pf_aziot-certd, pf_aziot-edged, pf_aziot-identityd, pf_aziot-keyd から始まるファイル)
  Azure IoT EdgeランタイムはAzure IoT Hubとの通信を行います。

• Docker (ファイル名が pf_docker, pf_containerd, pf_opa から始まるファイル)
  Dockerの動作に関するログとなります。opaはセキュリティチェックのために使用しており、作成した配置マニフェストに、カメラのセキュリティポリシーに違反する内容が記載されていた場合、このファイルにログが出力されます。

コンテナのセキュリティ強化

ここではコンテナアプリケーションの開発において、コンテナのセキュリティを強化するための手法について記載します。

コンテナのセキュリティを強化することは、エンドユーザーをはじめとした全ての関係者および社会の信頼を獲得するために重要です。セキュリティの脅威に対処することはそれら関係者および自身のデータとプライバシーを保護し、ビジネス上の信頼を築くために必要不可欠です。セキュリティが脆弱なコンテナイメージを使用することは、関連リスクを増大させ、関係者や社会の信頼を失う可能性があります。また、セキュリティ問題が発生した場合にその対応が求められ、莫大な損失が発生する可能性もあります。

下表はコンテナアプリの開発時に必要とされるセキュリティ対策の一例です。全部またはどれか一つを実施すればよいというものではなく、セキュリティリスクやコストなどのトレードオフを勘案しながら、何をどの程度組み合わせて対策するかを検討する必要があります。本書ではこれら対策のうち一部のみを説明しますが、詳細やその他の対策事項については各位にてベストプラクティスの調査や実際の対応のご検討をお願い致します。

コンテナイメージに対して脆弱性チェッカーを実行する

コンテナのセキュリティを強化する方法の一つとして、コンテナイメージ内の脆弱性をツールを用いて抽出し、それら脆弱性を可能な限り取り除いたり修正したりする方法があります。

以下では、コンテナイメージの脆弱性を検知するOSSのツールのうちTrivyとDockleを使用してコンテナイメージの脆弱性を抽出し、セキュリティ強化を図る例を説明します。

コンテナアプリの開発フローと、その中に脆弱性の抽出および対処を組込んだ例を下図に示します。脆弱性の抽出および対処は、早い段階から開発フローの中に組込み、実施することが推奨されます。最低限、イメージが製品リリースされる前の、実際の本番環境にデプロイされる前に必ず実施されるべきです。

本作業は、セキュリティに関するトレードオフの問題でもあります。抽出および対処にかかる時間や費用、頻度を考慮しなければなりません。しかし、セキュリティ上のリスクを最小限に抑えるために、脆弱性の抽出および対処は定期的に実施することが推奨されます。

本図の開発フローの例では、

• コンテナイメージのビルド “Build Container Image” の工程の直後に、

• ツールによる脆弱性の抽出と設計者による対応判定 “Check & Judge Vulnerability” を実施し、

• 次にその判定で対応必要としたものに対し実際に処置をする “Modify Vulnerability” を実施する、

という例を示しています。

脆弱性抽出ツールはTrivyとDockleの2つ両方を使用する例を示しています。これら両方を使用する理由は、各ツールの抽出できる脆弱性の範囲が相異なるためです。Trivyは主にパッケージの脆弱性を抽出し、Dockleは例えば不要なファイルの検出や設定の不備の検出など、主にシステム関連の脆弱性を抽出します。両方のツールを使用することで、より包括的なコンテナイメージのセキュリティチェックを実施できます。これら2つのツールの使用方法の概略については以降の節で記述します。

また、本図では脆弱性チェックの対象として、自身の開発プロダクトであるアプリコンテナイメージだけでなく、その開発途中でマルチビルド等の目的でベースとして使用するコンテナイメージ(例： Debian の公式イメージなど) についても対象としています。その理由は使用するパッケージに対しての脆弱性を漏れなく調べるためなのですが、詳細は改めてTrivyの説明の節において記述します。

Trivy: 包括的な脆弱性スキャナー

Trivyは、コンテナイメージやファイルシステムに存在する脆弱性を検出するオープンソースのスキャナです。主にOSパッケージやプログラミング言語のライブラリに関連する脆弱性を対象にしています。TrivyはAqua Security社によって開発・メンテナンスされており、コンテナ開発者にとって信頼性の高いツールの一つです。

Trivy の使い方の基本例を以下に示します。

(1)  Install Trivy:

まず、Trivy をインストールします。Trivyのリリースページから最新版のバイナリをダウンロードできます。下記リンクからTrivyのリリースページにアクセスしてください。

https://github.com/aquasecurity/trivy/releases

リリースページには、Linux、macOS、Windowsなどの各プラットフォーム向けのバイナリが用意されています。自分の環境に合ったバイナリを選択し、ダウンロードしてください。また、Trivyの公式ドキュメントには、各プラットフォームでのインストール方法が詳細に記載されていますので、そちらも参考にしてください。

Trivy は定期的に更新されていますので、最新版をインストールして使用するようにしてください。

(2)  Run Trivy:

インストールが完了したら、コマンドラインからTrivyを実行して、対象となるコンテナイメージの脆弱性をスキャンします。以下のコマンドは、your-image というコンテナイメージをスキャンする例です。

絞り込みを行う際は必要に応じて、Trivy のオプションを使用してスキャン対象や表示内容をカスタマイズできます。例えば、特定の重要度 (後述) 以上の脆弱性のみを表示する場合は、以下のようなコマンドを使用できます。

(3)  Check the result and determine how to deal with:

スキャンが完了すると、Trivy は検出された脆弱性の一覧を表示します。脆弱性の詳細や重要度（CRITICAL、HIGH、MEDIUM、LOW、UNKNOWN）が示され、修正が必要な箇所を特定しやすくなります。この結果をもとに、影響度などを加味しながらどれをどう対処していくのかを決定していきます。

参考で、以下に公式の ubuntu のイメージに対し trivy を実行した例 (オプション指定無し) の抜粋を示します。(実行例は Trivy は 0.38.3 を使用しています。)

(4)  Note for use:

ここで、Trivyにかけるイメージについて一つ注意点があります。Trivy はパッケージの脆弱性をスキャンする際にパッケージ情報を参照しています。しかし、コンテナイメージのビルドプロセスによっては、パッケージ情報が最終プロダクトであるコンテナイメージに含まれないことがあります。この場合、Trivy がパッケージ脆弱性の検出に関連する情報を取得できず、その機能を利用できない可能性があります。

コンテナ開発者としては、Trivy を適切に活用するために、コンテナイメージにパッケージ情報を含めるか、あるいは Trivy のスキャン対象となるよう別の方法でパッケージ情報を提供することが重要です。例えば、Dockerfile の RUN コマンドでパッケージのインストールとクリーンアップを同時に行っている場合、パッケージ情報がコンテナイメージに含まれないことがあります。このような状況では、Trivy の利用に制限が生じるため、必要に応じてビルドプロセスを調整することが望ましいです。

一手段として、ベースとして使用したコンテナイメージにはパッケージ情報を残したままにしておき、そのイメージに対して Trivy を実行する方法があります。最終プロダクトのコンテナに取り込む対象物は開発者が把握しているはずですので、その対象物に対応するパッケージの脆弱性情報のみを Trivy の実行結果から抽出すればよいわけです。

以上、Trivy のようなツールを利用してコンテナイメージに含まれる脆弱性を定期的にチェックし、セキュリティリスクを低減させることが重要です。また、CI/CDパイプラインにTrivyを組み込むことで、自動化された脆弱性検出を実現し、開発プロセス全体のセキュリティを向上させることができます。

Dockle: コンテナイメージセキュリティリンター

Dockle は、コンテナイメージのセキュリティベストプラクティスに基づいて、潜在的な問題を特定するオープンソースのツールです。Dockleは、Dockerfile やイメージ設定など、主にシステム関連の脆弱性を検出します。GoodwithTech 社によって開発・メンテナンスされており、Trivy と同様にコンテナ開発者にとって有益なツールの一つです。

Dockle の使い方の基本例を以下に示します。

(1)  Install Dockle:

まず、Dockle をインストールします。Dockle のリリースページから最新版のバイナリをダウンロードできます。下記リンクから Dockle のリリースページにアクセスしてください。

https://github.com/goodwithtech/dockle/releases

リリースページには、Linux、macOS、Windowsなどの各プラットフォーム向けのバイナリが用意されています。自分の環境に合ったバイナリを選択し、ダウンロードしてください。また、Dockle の公式ドキュメントには、各プラットフォームでのインストール方法が詳細に記載されていますので、そちらも参考にしてください。

(2)  Run Dockle:

インストールが完了したら、コマンドラインから Dockle を実行して、対象となるコンテナイメージのセキュリティベストプラクティスをチェックします。以下のコマンドは、your-image というコンテナイメージをチェックする例です。

絞り込みを行う際は必要に応じて、Dockle のオプションを使用してチェック対象や表示内容をカスタマイズできます。例えば、特定のチェック ID (後述) を無視する場合は、以下のように実行します。

(3)  Check the result and determine how to deal with:

チェックが完了すると、Dockle は検出された問題の一覧を表示します。各問題には、CIS（Center for Internet Security）ベンチマークに基づいたチェック ID が付与されており、対処すべき箇所を特定しやすくなります。この結果をもとに、影響度などを加味しながらどれをどう対処していくのかを決定していきます。

参考で、以下に Azure IoT Edge のサンプルアプリケーションのイメージに対し Dockle を実行した例 (オプション指定無し) の抜粋を示します。

以上、Trivy と同様に Dockle のようなツールを利用してコンテナイメージに含まれるシステム関連の問題を定期的にチェックし、セキュリティリスクを低減させることが重要です。また、CI/CD パイプラインに Dockle を組み込むことで、自動化されたセキュリティベストプラクティスのチェックを実現し、開発プロセス全体のセキュリティを向上させることができます。

ホストリソースへのアクセスを強制的に制限する

セキュリティ上の理由から、i-PROカメラ上で動作するコンテナはアクセス可能なi-PROカメラのホスト側の権限やリソースが強制的に制限されています。Docker API に対し、i-PROに許可されていない権限やリソースの場所、範囲外の値のオプションを指定したコンテナを起動しようとした場合、ホスト側のチェック機構がそれら要求を拒否する仕組みが搭載されています (下記の図を参照)。

上記の制約下において、i-PROが許可しているオプション一式が事前設定されているテンプレートを SDK のビルド環境にて提供しています。このテンプレートにはコンテナアプリケーションが起動許可されるために必要かつ十分な設定となっており、上記のような権限やリソースに関する設定は変更せずにそのまま使用可能となっています (コンテナ名などの個別対応が必要なものを除く)。開発されるコンテナアプリケーションからアクセスが必要な権限やリソースに対して、上記テンプレートに事前設定されていない場合や、ご自身で追加、変更した設定がi-PROカメラのホスト側から拒否される場合には、設計、設定の見直しをお願いします。

WSL環境でうまくいかない場合のチェックポイント

WSL環境でうまくいかない場合は以下をチェックしてください。

• Visual Studio Codeの「LOCAL」の拡張機能で以下が有効になっていること

  • Dev Containers

  • Remote - SSH, Remote - SSH: Editing Configuration FIles, Remote - Tunnels, Remote Development, Remote Explorer

  • WSL

• Visual Studio Codeの「WSL: UBUNTU-20.04 」の拡張機能で以下が有効になっていること

  • Azure Account

  • Azure IoT Edge

  • Azure IoT Hub

• Visual Studio Codeの画面左下が「WSL: Ubuntu-20.04」と表示されていること

• Build IoT Edge Solutionでpermission denied と表示される場合、対象のディレクトリに現在のユーザーのアクセス権があるかどうか確認する。

  を実行して所有者を変更。

商標について

サイトで使用している商標について掲載します。

・Docker and the Docker logo are trademarks or registered trademarks of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein