コンテナ、Kubernetesの脆弱性スキャン、3つの重点ポイント：セキュリティ、エンジニアは後回しにすることが多いが、CIOは最優先

コンテナ化とKubernetesの初心者向けに、コンテナイメージのスキャン、コンテナファイルのスキャン、Kubernetesマニフェストのスキャンについて開発チームが知っておくべきことを説明する。

[Michael Levan，TechTarget]

　組織が新しいテクノロジーを導入する際は、概念実証の作業と検証を優先し、セキュリティの考慮を後回しにすることが多いということを、ソフトウェアエンジニアは知っている。しかし、シフトレフトへの動きが進むとともに、最高情報責任者（CIO）や最高技術責任者（CTO）がセキュリティを最優先するようになっているため、エンジニアは開発の初期段階からセキュリティを考慮する必要がある。

　開発にコンテナが関係する場合、開発者とテスト担当者は次の3つの主要な脆弱（ぜいじゃく）性スキャンに重点を置く必要がある。

1. コンテナイメージのスキャン
2. コンテナファイルのスキャン
3. Kubernetesマニフェストのスキャン

　これらのスキャンを正しく実装すれば、アプリケーションレベルでセキュリティのリスクを軽減できる。

　コンテナは仮想化されたOSだ。そのため、フットプリントは極めて小さく、数秒で作成できる。エンジニアは、Dockerの「Docker Hub」にアクセスして、「Ubuntu」や「Nginx」などの公式リポジトリからコンテナイメージを取り込むだけだ。Kubernetesを使用してコンテナイメージのオーケストレーションを行い、Kubernetesマニフェストを使ってデプロイする。

　このプロセスを進める中で、次のような重要な疑問を幾つか問い掛ける必要がある。

• セキュリティのベストプラクティスを使用したか
• コンテナイメージに脆弱性はあるか
• コンテナイメージをスキャンする場合、どのデータベースを使用しているか。米国のNational Vulnerability Database（NVD）のデータベースなのか、そしてThe President's National Infrastructure Advisory Council（NIAC）の共通脆弱性評価システム（CVSS）を利用しているのか
• Kubernetesマニフェストは、セキュリティチームがPolicy-as-Codeの観点から想定する方法でフォーマットおよび構築されているか

1.コンテナイメージのスキャン

　継続的インテグレーション（CI）の最中に脆弱性が明らかになることがある。全てのセキュリティポイントが考慮されていることを確認するには、コンテナイメージの構築後にスキャンする。スキャンには、「Checkov」「Snyk」といったツールを使用できる。

　Dockerの「docker scan」コマンドを使用すると、バックエンドでSnykが使用され、コンテナイメージがスキャンされる。スキャン後に、Secure Hash Algorithm-256（SHA-256）暗号化チェックサムの値をコンテナイメージレジストリと照合し、使用するコンテナイメージが正しいかどうかを確認できる。

　検討しておきたいツールのもう1つがJFrogの「JFrog Xray」だ。これは、NVDに基づいてコンテナイメージを自動的にスキャンし、エンジニアがCVSSスコアを選択できるようにする。コンテナのセキュリティを確保するには、1日に複数回コンテナをスキャンするように設定する。

　コンテナイメージのスキャンでは、Open Policy Agent（OPA）のメリットを生かすこともできる。OPAとは、個人が選択したポリシーを適用できる汎用（はんよう）のポリシーエンジンだ。Policy-as-Codeツールの多くは、ルールを適用する際の一般標準としてOPAを使用する。例えば、Red Hatの「OpenShift Container Platform」はクラスタセキュリティを高度化するためにOPAのポリシーを使用している。

2.「Dockerfile」を利用するコンテナファイルのスキャン

　エンジニアは、セキュリティプロセスの一環として、コンテナファイルをスキャンする必要がある。エンジニアはDockerの「Dockerfile」を使用して、コンテナイメージを構築できる。こうして構築したコンテナイメージは下記の要素で構成されるのが一般的だ。

• ベースコンテナイメージ
• コンテナイメージ内に組み込むアプリケーション
• アプリケーションの実行に必要な特定のポートとファイル
• コンテナイメージ内で実行されるアプリケーションの起動コマンド

　Dockerfileで問題が発生する可能性がある。Dockerfileを適切に機能させるには、ベースイメージのセキュリティは確保されているか、コンテナイメージ内部で使用されるアプリケーションは何らかの方法で侵害される可能性があるか、NVDに関連する欠陥が存在するかどうかといったことを検討する必要がある。

　コンテナイメージを構築するCIプロセス中にDockerfileをスキャンする場合、CheckovやSnykなどのツールが役に立つ。CIプロセス中にファイルをスキャンすれば、既知の脆弱性がある場合にCIプロセスが失敗し、そのコンテナイメージがコンテナ化アプリケーションをデプロイする継続的デプロイメント（CD）段階に進むのを避けることができる。

3.Kubernetesマニフェストのスキャン

　アプリケーションをコンテナ化したら、オーケストレーションを行う。コンテナイメージは、Kubernetesマニフェストを通じて使用するのが一般的だ。だが、そのKubernetesマニフェストも、Policy-as-Code、静的コード分析、lintの点から見れば、脆弱性が含まれる可能性がある。

　lintツール「Kubeval」は、Kubernetesマニフェストの1つ以上の構成を検証する。ローカル開発またはCIフェーズの一環として使われることが多い。Kubevalは「Helm」チャートでも作業可能だ。

　また、「Kube-score」はKubernetesマニフェストに対して静的コード分析を実行する。Kube-scoreは数多くのチェックを実行する。特に、以下の点に役立つ。

• コンテナ制限の設定
• コンテナイメージがlatestタグを誤用している場所の検索
• Readiness ProbeとLiveness Probeが同一ではないことの確認
• DeploymentsとStatefulSetがPodDisruptionPolicyを備えていることのチェック