...

• 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

...

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

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

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

コンテナアプリ開発におけるセキュリティ対策例

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

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

以下では、コンテナイメージの脆弱性を検知する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 というコンテナイメージをスキャンする例です。

buildhost$ trivy image your-image

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

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

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

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

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

trivy の実行例: ターゲットイメージ = ubuntu

(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 というコンテナイメージをチェックする例です。

buildhost$ dockle your-image

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

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

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

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

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

Dockle の実行例: ターゲット イメージ = azureiotedge サンプル アプリケーション

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

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

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

...

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

Checkpoints if things don't work in the WSL environment

...