Table of contents

Overview

Here we will explain the steps to build the iPRO Camera SDK app using the Azure IoT Edge container and check its operation. Also, in this tutorial, the SDK installation directory is described as ${SDK_DIR}.

Operation confirmation procedure

Create a new IoT Edge Solution on Visual Studio Code

The following describes the case where the sample app to be referenced is skeleton_sample_app for the C version, additional_info_sample_app for the Python version, and test_app for the Edge Solution to be created. Please note that the Edge Solution name must be in all lowercase letters. Please see below for details.
https://docs.docker.com/reference/cli/docker/image/tag/

Description of C version/Python version application

Launch Visual Studio Code directly under [SDK folder].

cd ${SDK_DIR}
code .

Copy the ”${SDK_DIR}/src/adamapp/skeleton_sample_app” folder into the same folder.

Rename the copied folder to test_app.

Rename the "skeleton_sample_app" folder in [copied folder]/container/modules to test_app.

Right-click the folder (test_app) copied from Visual Studio Code's EXPLORER and select "Find in Folder..." to display the SEARCH window.

Search for "skeleton_sample_app" and replace everything with "test_app". The targets are as follows.

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

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

Enter the information for the container registry to which you want to push the created image.

Log in to Azure portal(Cloud Computing Services | Microsoft Azure) and select the container registry you want to target. The screen below is an example.

Display "Settings" - "Access Keys" from the left menu.

Based on the information displayed, enter the following:

• ${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json
  Enter “registryCredentials” in the above file as follows. "Container Registry Name" is the "Registry Name" of Azure Portal in lower case (same as the string before .azurecr.io in "Login Server").

  "registryCredentials": {
    "[container registry name]": {
      "username": "$CONTAINER_REGISTRY_USERNAME_[container registry name]",
      "password": "$CONTAINER_REGISTRY_PASSWORD_[container registry name]",
      "address": "[login server]"
    }
  }

  For example, if the container registry name is “iprocv5xcontainerregistry” and the container registry login server is “iprocv5xcontainerregistry.azurecr.io”, it will be as follows.

  

   

• ${SDK_DIR}\src\adamapp\test_app\container\modules\test_app\module.json
  Enter “repository” in the above file as follows.

  "repository": "[login server]/test_app"

  If the container registry login server is "iprocv5xcontainerregistry.azurecr.io", it will be as follows.

  

• ${SDK_DIR}\src\adamapp\test_app\container
  Create an .env file in the directory, write the container registry user name and password, and save it.

  CONTAINER_REGISTRY_USERNAME_[container registry name]=[user name]
  CONTAINER_REGISTRY_PASSWORD_[container registry name]=[password]

  An example is shown below.
  

  

Coding the app

Now code as you like on Visual Studio Code. If you copy skeleton_sample_app etc., the source file name will be the one before copying (skeletonSampleApp.cpp for skeleton_sample_app), so please rename it if necessary. Below is an example.

Before
${SDK_DIR}\src\adamapp\test_app\skeletonSampleApp.cpp
After
${SDK_DIR}\src\adamapp\test_app\testApp.cpp

Please also modify SRC_FILES in Makefile as necessary. Below is an example.

${SDK_DIR}\src\adamapp\test_app\Makefile
Before
SRC_FILES=	skeletonSampleApp.cpp
After
SRC_FILES=	testApp.cpp

Please also modify PROG_NAME in Makefile, APPLICATION in configuration.txt, and APPLICATION_NAME in deployment.template.json as necessary. Below is an example.

${SDK_DIR}\src\adamapp\test_app\Makefile
Before
PROG_NAME= SkeletonSampleApp
After
PROG_NAME= TestApp

${SDK_DIR}\src\adamapp\test_app\configuration.txt
Before
APPLICATION	SkeletonSampleApp
After
APPLICATION	TestApp

${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json
Before
"APPLICATION_NAME=SkeletonSampleApp"
After
"APPLICATION_NAME=TestApp"

Build the app

When building, use the built-in functionality of the Azure IoT extension. In Visual Studio Code's Explorer Right-click on "${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json" to display the build menu.

Select “Build IoT Edge Solution”. This operation only performs a build.

For your first build, you will be asked to log in to your container registry. The following is an example when the container registry is "iprocv5xcontainerregistry.azurecr.io".

ERROR: failed to solve: iprocv5xcontainerregistry.azurecr.io/cadamappbase:0.0.2: failed to authorize: failed to fetch anonymous token: unexpected status: 401 Unauthorized

At this time, enter the following command on the Visual Studio Code terminal.

docker login iprocv5xcontainerregistry.azurecr.io

Then enter the Username and Password that are displayed. Enter the container registry user name and password.

Username: [user name]
Password: [password]

Login Succeeded is displayed, the login is successful.

Next, right-click "${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json" and Select “Build and Push IoT Edge Solution”. This operation builds and pushes to the container registry.

The build is done by running Docker buildx build as described in the Dockerfile.azureIoT file located under “${SDK_DIR}\src\adamapp\test_app\”. The environment name (arm64v8) after Dockerfile. is the architecture selected in the above step. (You can see the current architecture at the bottom of Visual Studio Code)

Check the built image

If the build is successful, you can check the existence of the image with docker images. Below is an example.

$ docker images
REPOSITORY                                                             TAG             IMAGE ID       CREATED          SIZE
iprocv5xcontainerregistry.azurecr.io/azureiot/test_app  0.0.5-arm64v8   f1772ccfed77   35 minutes ago   91.4MB

Deploy to camera

Select the device you want to deploy from under "AZURE IOT HUB" in the bottom left, right-click and select "Deploy to one IoT Edge" to deploy it to the camera. What to deploy Follows "${SDK_DIR}\src\adamapp\test_app\container\deployment.template.json".

A dropdown will appear at the top of Visual Studio Code, so select the following:
${SDK_DIR}\src\adamapp\test_app\container\config\deployment.arm64v8.json

Deployment Succeeded is displayed, the deployment is successful.

Check runtime status on Azure

Log in to the Azure portal(Cloud Computing Services | Microsoft Azure) and select the IoT Edge device you added on the IoT Hub - IoT Edge screen.

Check the runtime status of the deployed app shown at the bottom of the screen. If it is "running", no error has occurred. If "Error" is displayed, an error message will be displayed when you select it, so please debug it.

Check the operation of the app

Access the URL below with a PC that can connect to the camera.

http://[Camera local IP address]/cgi-bin/cadam.cgi?methodName=getApplicationList

The camera response will be displayed. Below is an example.

{
    "appCount": "1",
    "limitationMode": "Shared",
    "maxAppCount": "9",
    "appList": [
        {
            "appType": "0",
            "funcId": "0000FF01",
            "appInfo": {
                "installId": "124B569A",
                （中略）
}

Use the information marked "installId": "124B569A",.

Access the URL below.

http://[Camera local IP address]/cgi-bin/cadam.cgi?Language=1&methodName=sendDataToAdamApplication&installId=[installId]&s_appDataType=0&s_appData=e3tMYW5ndWFnZToxfX0%3D

If the camera's IP address is 192.168.100.33, "installId": "124B569A",, it will be as follows.

http://192.168.100.33/cgi-bin/cadam.cgi?Language=1&methodName=sendDataToAdamApplication&installId=124B569A&s_appDataType=0&s_appData=e3tMYW5ndWFnZToxfX0%3D

You can check the app operation as below. Below is an example of running skeleton_sample_app.

Controlling Container version Adamapp using Azure IoT Explorer

It is possible to control and check the Container version of Adamapp using Azure IoT Explorer published by Microsoft. The following describes the installation and initial settings of Azure IoT Exporlor.

Install

Follow Install and use Azure IoT explorer - Azure IoT | Microsoft Learn and install Azure IoT Explorer on your PC.

Initial setting

When you start Azure IoT Explorer, the following initial screen will appear, so select "Connect via IoT Hub connection string".

Select “Add connection”.

Visit “Cloud Computing Services | Microsoft Azure” and select the IoT Hub you want to connect to. In the example below, CV5xIoTHub2 is selected.

Select Security Settings - Shared Access Policies from the left menu.

Click “iothubowner” from the Manage “Shared Access Policies” list.

Press the copy button to the right of Primary Connection String to copy the string to your clipboard.

Paste it into the Connection string frame of Azure IoT Explorer and press the Save button.

The IoT Hub information will be loaded and a device list will be displayed.

Select the device you want to check from the displayed device (camera) list.

Checking the setting values with ModuleTwin

The settings values listed in the app settings (AppPrefs.json) can be checked from the cloud using Azure IoT's ModuleTwin mechanism.

Please refer to Understand Azure IoT Hub module twins | Microsoft Learn for ModuleTwin.

Select the device (camera) you want to check in Azure IoT Explorer. Select “Module identities” from the left menu.

A list of containers (Modules) currently running on the camera is displayed. Click the container name whose settings you want to check.

The page for the target container will be displayed. Select “Module twin” from the left menu again.

Information about the target container is displayed in json format. The information written in appPrefs.json will be displayed in “properties”.”reported”.”aplField”.”preference”.

Setting the operation schedule

Use ModuleTwin to set the time zone in which the application will run.

Similar to the "Checking settings using ModuleTwin" chapter, the Module Twin information for the target container is displayed.
Set the schedule in “properties”.”desired”.“scheduleField” according to the following format.
The format is below. Three fields represent one setting.

Day of the week setting 1, Inference start time 1, Inference end time 1, Day of the week setting 2, Inference start time 2, Inference end time 2,...

The specifications of each item are as follows.

A setting example is shown below.

In this case, it will be set to operate from Sunday to Thursday, from 08:00:00 to 20:00:59 on Saturday, and from 03:00 to 23:59:59 on Friday.

• After entering the settings, press "Save" at the top of the screen to apply the settings to the camera.

• Up to 8 can be set.

• If it is within any of the configured times, Container AdamApp will work.

• If the inference end time is later than the inference start time, the inference end time represents the next day.

• If scheduleField is empty, it will always operate.

• If the information is incorrect, the application will not start.

• Stop/start decisions are made at 15 second intervals. Therefore, the start and stop times will be delayed by up to 15 seconds.

Sending telemetry data from the device via cloud communication

Sending telemetry data

• Telemetry data can be sent from the device via cloud communication by calling the ADAM_SendTelemetry() function, which is valid only for Container AdamApp.

• Please specify values in JSON format for the arguments of this API. Please see the API specification for details.

• Device-to-cloud communication has a limit on the number of times it can communicate depending on the Azure IoT Hub settings. Please check here for more details.

• To control communication, sending is set to OFF by default. In order to send to the cloud, you must first turn on the sending function.

• There are two ways to turn on the transmission function: Module direct method and Module twin desired property. Please see below.

How to turn on using module direct method

Select the target Container Adamapp in Azure IoT Explorer.

Select "Module direct method" from the left menu. You can send a direct method on the screen below.

 
Enter the method name “setTelemetry” in the Method name field.
Enter the transmission data in JSON format in the Payload field as follows.

{"telemetry": true}

When you press "Invoke method", a direct method will be executed for the camera.

The results will be displayed in a pop-up. If the status is 200, it is successful.

How to set with Module twin desired property

Display the Module twin of the target Container Adamapp in Azure IoT Explorer.
Set as follows in “properties”.”desired”.”aplField”.

"aplField": {
  "telemetry": true
}

Click “Save” at the top of the screen to apply the changes.

How to check the settings

Setting values can be checked with Module twin.
Check the value of “properties”.”reported”.”aplField”.”azureSettings”.”telemetry”.

Checking received telemetry data

Select the target Container Adamapp in Azure IoT Explorer.

Select "Telemetry" from the left menu.

Press the "Start" button. The device will be waiting to receive telemetry data.

When the app receives telemetry sent with ADAM_SendTelemetry(), it will be displayed in the window.

The string set in ADAM_SendTelemetry will be set as the value of the payload key.

How to check the log

App log

You can check messages output by ADAM_DEBUG_PRINT() within the app and logs output by libraries linked from the app. You can also check if there is an error.

• Log in to Azure portal(Cloud Computing Services | Microsoft Azure).

• Select the target IoT Hub.

• Select the target camera from "Device Management" and "IoT Edge" on the left.

• From the list of modules below, click the "Runtime Status" link for the app name you want to view logs for.

camera pflog

By checking the log in the camera, you can also analyze the behavior when Container Adamapp is not working properly. Logs can be obtained by clicking the execution button below.

Among the multiple log files, we will introduce the log files that are most related to Container Adamapp.

• cadam (files with file names starting with pf_cadam, pf_cadamCgi) cadam is a process that manages Container Adamapp.

• Azure IoT Edge runtime (files whose names start with pf_aziot-certd, pf_aziot-edged, pf_aziot-identityd, pf_aziot-keyd)Azure IoT Edge runtime communicates with Azure IoT Hub.

• Docker (files with file names starting with pf_docker, pf_containerd, pf_opa) Logs related to Docker operations. opa is used for security checks, and if the created deployment manifest contains content that violates the camera's security policy, a log will be output to this file.

Enhance Security Level of your Container

This article describes techniques for strengthening container security when developing container applications.

Enhancing the security of containers is important to gain the trust of all stakeholders, including end users, and society. Addressing security threats is essential to protecting the data and privacy of those stakeholders and yourself, and building business trust. Using container images with weak security increases the associated risks and can lead to a loss of trust among stakeholders and society. Additionally, if a security issue occurs, you will be required to take action, which could result in huge losses.

The table below is an example of security measures required when developing container apps. It is not a matter of implementing all or just one of the measures; instead, it is necessary to consider what measures to take in combination and to what degree, taking into account trade-offs such as security risks and costs. This document explains only some of these measures, but for details and other measures, we ask that you investigate best practices and consider actual responses.

Examples of Security Measures in Container Apps Development

Run Vulnerability Checker against your Image

One way to strengthen container security is to use tools to extract vulnerabilities in container images and remove or fix them as much as possible.

Below, we will explain an example of using Trivy and Dockle, two OSS tools for detecting vulnerabilities in container images, to extract vulnerabilities in container images and strengthen security.

The diagram below shows the development flow of a container app and an example of incorporating vulnerability extraction and countermeasures into it. It is recommended that vulnerability extraction and countermeasures be incorporated into the development flow from an early stage. At a minimum, this should be done before the image is released into production and deployed to an actual production environment.

This work is also a matter of security trade-offs. The time, cost, and frequency of extraction and treatment must be considered. However, to minimize security risks, it is recommended that vulnerabilities be identified and addressed on a regular basis.

In the example development flow shown in this diagram, an example is shown.

• Immediately after the “Build Container Image” step,

• By extracting vulnerabilities using tools and conducting “Check & Judge Vulnerability” by designers,

• Next, carry out “Modify Vulnerability” to actually take action on what needs to be addressed based on the judgment.

This example uses both Trivy and Dockle as vulnerability extraction tools. The reason for using both of these is that each tool extracts a different range of vulnerabilities. Trivy mainly extracts vulnerabilities in packages. Dockle mainly extracts system-related vulnerabilities, such as detecting unnecessary files or misconfigurations. By using both tools, you can perform more comprehensive security checks on your container images. The following sections outline how to use these two tools.

In addition, in this figure, vulnerability checks are not limited to application container images that are self-developed products, but also container images that are used as a base for multi-build purposes during development (e.g., Debian official images, etc.) It also covers. The reason for this is to thoroughly check for vulnerabilities in the packages you use. The details will be described in the Trivy explanation section.

Trivy: Comprehensive Vulnerability Scanner

Trivy is an open source scanner that detects vulnerabilities in container images and file systems. It mainly targets vulnerabilities related to OS packages and programming language libraries. Trivy is developed and maintained by Aqua Security and is one of the most reliable tools for container developers.

Below is a basic example of how to use Trivy.

(1)  Install Trivy:

First, install Trivy. You can download the latest version of the binaries from the Trivy release page. Please access the Trivy release page from the link below.

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

The release page provides binaries for each platform, including Linux, macOS, and Windows. Select the binary that suits your environment and download it. Also, please refer to Trivy's official documentation, which has detailed instructions on how to install it on each platform.

Trivy is updated regularly, so be sure to install and use the latest version.

(2)  Run Trivy:

Once installed, run Trivy from the command line to scan the target container image for vulnerabilities. The following command is an example of scanning a container image called your-image.

buildhost$ trivy image your-image

When filtering, you can use Trivy's options to customize what is scanned and what is displayed, if necessary. For example, if you want to display only vulnerabilities of a certain severity level (described below), you can use a command like the following:

buildhost$ trivy image --severity CRITICAL,HIGH your-image

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

Once the scan is complete, Trivy displays a list of detected vulnerabilities. Vulnerability details and severity (CRITICAL, HIGH, MEDIUM, LOW, UNKNOWN) are shown, making it easier to identify areas that need fixing. Based on these results, we will decide which ones to deal with and how to deal with them, taking into consideration factors such as the degree of impact. For reference, below is an excerpt of an example of running trivy on an official ubuntu image (without specifying options). (The execution example uses Trivy 0.38.3.)

Example execution of trivy: target image = ubuntu

(4)  Note for use:

Here, there is one thing to note about the image you give to Trivy. Trivy references package information when scanning packages for vulnerabilities. However, depending on the container image build process, package information may not be included in the final product, the container image. In this case, Trivy may not be able to retrieve information related to package vulnerability detection and may not be able to take advantage of that functionality.

As a container developer, it is important to include package information in your container images or otherwise provide package information for Trivy to scan in order to properly utilize Trivy. For example, if your Dockerfile's RUN command installs and cleans up packages at the same time, the package information may not be included in the container image. In these situations, there are limitations to the use of Trivy, so it is best to adjust the build process as necessary.

One option is to leave the package information in the container image you used as a base and run Trivy against that image. The developer knows what to include in the container of the final product. He only needs to extract vulnerability information for the package corresponding to the target from the Trivy execution results.

As mentioned above, it is important to regularly check for vulnerabilities in container images using tools like Trivy to reduce security risks. Additionally, by incorporating Trivy into your CI/CD pipeline, you can achieve automated vulnerability detection and improve security throughout your development process.

Dockle: Container Image Security Linter

Dockle is an open source tool that identifies potential issues based on container image security best practices. Dockle primarily detects system-related vulnerabilities, such as Dockerfiles and image configurations. It is developed and maintained by GoodwithTech and, like Trivy, is one of the most useful tools for container developers.

Below is a basic example of how to use Dockle.

(1)  Install Dockle:

First, install Dockle. You can download the latest version of the binaries from the Dockle release page. Please access Dockle's release page from the link below.

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

The release page provides binaries for each platform, including Linux, macOS, and Windows. Select the binary that suits your environment and download it. Also, please refer to Dockle's official documentation, which provides detailed instructions on how to install it on each platform.

(2)  Run Dockle:

Once installed, run Dockle from the command line to check the security best practices for your container image. The following command is an example of checking a container image called your-image.

buildhost$ dockle your-image

When filtering, you can use Dockle's options to customize what to check and what to display if necessary. For example, if you want to ignore a particular check ID (described below), run:

buildhost$ dockle --ignore CIS-DI-0001 your-image

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

Once the check is complete, Dockle displays a list of detected issues. Each issue has a check ID based on Center for Internet Security (CIS) benchmarks to help you identify areas to address. Based on these results, you will decide which ones to deal with and how to deal with them, taking into consideration factors such as the degree of impact. For reference, below is an excerpt of an example of running Dockle on an Azure IoT Edge sample application image (no options specified).

Example execution of Dockle: target image = azureiotedge example application

As mentioned above, it is important to use tools like Dockle to regularly check for system-related issues in container images and reduce security risks, just like Trivy. You can also incorporate Dockle into your CI/CD pipeline to provide automated security best practice checks and improve security throughout your development process.

Force-Limit on Access to Host Resources

For security reasons, the permissions and resources of the i-PRO camera host that can be accessed by containers running on the i-PRO camera are forcibly restricted. If an attempt is made to start a container that specifies permissions, resource locations, or out-of-range options for Docker API that are not allowed by i-PRO, a check mechanism on the host side will reject the request. (see diagram below).

Under the above constraints, we provide a template in the SDK build environment that is preconfigured with a set of options allowed by i-PRO. This template has the necessary and sufficient settings for the container application to be allowed to start, and can be used as is without changing settings related to permissions and resources such as the above (individual settings such as container name etc. (excluding those that require action).
If the permissions and resources that need to be accessed from the container application being developed are not pre-configured in the above template, or if the settings you have added and/or changed yourself are rejected by the i-PRO camera host. Please review the design and/or settings.

Checkpoints if things don't work in the WSL environment

If it does not work in WSL environment, please check the following.

• The following must be enabled in the Visual Studio Code "LOCAL" extension

  • Dev Containers

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

  • WSL

• The following must be enabled in Visual Studio Code's "WSL: UBUNTU-20.04" extension:

  • Azure Account

  • Azure IoT Edge

  • Azure IoT Hub

• "WSL: Ubuntu-20.04" is displayed at the bottom left of the Visual Studio Code screen.

  

• If permission denied is displayed in Build IoT Edge Solution, check whether the current user has access rights to the target directory.

  sudo chown -r ipro:ipro [development directory]
  ※ipro:ipro is an example, so please set it according to each environment.

  Run the above to change the owner.

About trademarks

We will post about the trademarks used on the site.

・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