「OpenClarity」によるk8sワークロードの脆弱性スキャン

はじめに

3-shakeのSreake事業部に所属する齋藤(@kiyo_12_07)です。第12回目の今回は、Kubernetesなどのプラットフォームで稼働し、ワークロードのセキュリティリスクを検出するOSSツール「OpenClarity」を紹介します。

コンテナイメージのリスク

Kubernetesはコンテナ化したアプリケーションをデプロイするシステムです。Kubernetes独自のセキュリティだけではなく、他のコンテナオーケストレーション同様、コンテナ自体のセキュリティについても考慮が必要となります。

セキュリティ対策を考えるときに「どのような攻撃方法があるか」ということから考えるアプローチがあります。下図はコンテナに対する主な攻撃経路をまとめた図です。

【出典】「コンテナセキュリティ」p.23「図1-1 コンテナの攻撃経路」より著者が再編集(Liz Rice著 水元恭平・生賀一輝・戸澤涼・元内柊也訳 2023年インプレス刊)

上記のうち、今回紹介するOpenClarityが対象とする「コンテナイメージ」に関する攻撃経路は下記の4つです。

OpenClarityの概要

OpenClarityとは

冒頭で、OpenClarityについて「Kubernetesなどのプラットフォームで稼働するワークロードのセキュリティリスクを検出するOSSツール」と記載しましたが、分解して説明します。

Kubernetesなどのプラットフォームで稼働するワークロードに関して、具体的には下記のプラットフォームおよびサービスに対応しています。

セキュリティリスクを検出に関して、具体的には下記の機能を有しています。

OpenClarityの特徴として、上記の機能を外部ツールで実装している点があります。上記の機能のうち、SBOM生成と脆弱性検出で使用しているツールを記載します。

1. SBOM生成
   • syft
   • trivy
   • cyclonedx-gomod
2. 脆弱性検出
   • grype
   • trivy

この他の機能については、こちらのページを参照してください。

アーキテクチャー

OpenClarityは複数のコンポーネントにより構成されています。下図は、ドキュメントに記載されたアーキテクチャー図です。

【出典】「OpenClarity Stack」(2024/08/16)

本記事では主要なコンポーネントを簡単に説明します。

• UI Backend および UI Webserver
  • Web UIでOpenClarityを使用する際のバックエンドサーバー
• API
  • OpenClarity内のすべてのオブジェクトを管理するコンポーネント
  • OpenClarityの管理におけるフロントエンドとなり、DBへのアクセスを行う唯一のコンポーネント
• Scan Orchestrator
  • スキャン設定やスキャン済みのアセット、スキャンのライフサイクルを管理するコンポーネント
• Database
  • スキャン履歴や検出したアセット一覧、脆弱性一覧などのデータを保存するデータベース
  • SQLiteおよびPostgreSQLをサポートする
• スキャナーヘルパーサーバー(exploitDB-server、trivy-server、grype-server、freshclam-mirrorなど)
  • OpenClarityの各機能が依存する外部ツール
  • 例: exploitDB-server, trivy-server, grype-server, freshclam-mirror など

詳細が気になる方は、ぜひ公式ドキュメントをご参照ください。

KubeClarityとの関係

読者の中には「KubeClarity」をご存じの方がいるかもしれません。KubeClarityのGitHub Organizationはopenclarityですが、どのような関係があるのでしょうか。

OpenClarityは元々別のツールだったVMClarity、KubeClarity、APIClarityの3つを2024年10月に統合したツールです。現在、統合元の各ツールはアーカイブされ、OpenClarityは正式に後継ツールとして位置付けられています。

OpenClarityを試してみる

それでは、実際にOpenClarityを動かして試してみましょう。本記事ではKubernetes上にOpenClarityをデプロイし、同一クラスターで稼働するワークロードのSBOMの生成と脆弱性の検出を行います。

OpenClarityのデプロイ

OpenClarityは複数のコンポーネントをデプロイする必要がありますが、開発元が公開しているHelm Chartを使うことで簡単にデプロイできます。基本的には公式ドキュメントの手順に従ってデプロイしますが、下記の2つのポイントがあります。

1. データベース用にPVCが必要となる
2. OpenClarityのプロバイダーをKubernetesに指定する

公式helm chartでは、デフォルトでデータベースとしてPostgreSQLをKubernetes上に構築してデータをPVに永続化します。そのため、事前にCSI DriverのインストールおよびStorage Classの設定が必要となります。

使用するStorage Classをデフォルトにしている場合、helm chartを変更することなくデプロイできます(下記はAmazon EKSを使用している場合の例)。

$ kubectl get storageclass                              
NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-gp3 (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d22h
gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  4d23h

OpenClarityのプロバイダーとは何でしょうか。本記事の冒頭でOpenClarityの概要に触れた際、Kubernetes以外にも様々なプラットフォームに対応していることを説明しました。OpenClarityではプロバイダーというプラグインを介して各プラットフォームの対応を行います。公式helm chartではデフォルトでAWSをプロバイダーとして選択しているため、Kubernetesを指定する必要があります。

下記に、values.yamlの例を記載します。

orchestrator:
  provider: kubernetes

上記の準備を行った上でhelm installすることでOpenClarityをデプロイできます。

SBOMの生成と脆弱性の検出

OpenClarityのデプロイが完了したら、早速スキャンしていきましょう。公式helm chartを使用してデプロイした場合、ingress等は含まれないため外部からの疎通性がありません。今回は検証のためポートフォワードによりアクセスします。

$ kubectl -n clarity port-forward svc/openclarity-gateway 8080:80

ポートフォワードしたあとで http://localhost:8080 にアクセスすると、下記のような画面が表示されるはずです。

OpenClarityにおけるスキャンの流れは下記の通りです。

1. スキャン設定を行う
2. スキャンを実行する
3. スキャン結果を確認する

スキャンの設定を行う
左ペインのScansからConfigurationsに遷移し、New scan configurationで設定を作成します。ここでは、どの項目をスキャンするかやスケジュールなどを指定できます。

スキャンを実行する
設定が完了したらスキャンを実行します。スキャン設定のStart scanを実行することでスキャンが開始します。

スキャン結果を確認する
スキャン完了後、スキャン詳細からスキャン結果のサマリを確認できます。

上記の画面からは各項目をクリックすると詳細を閲覧できるように見えますが、まだその機能は実装されていません。FindingsからVulnerabilitiesを選択すると、検出した脆弱性の一覧を見ることができます。

一覧から脆弱性を選択すると、脆弱性の説明や修正されたバージョン、攻撃のしやすさ、影響の大きさなどの詳細を確認できます。

今回はWeb UIからスキャンの実行と結果の確認を行いましたが、APIやCLIツールが用意されています。CI/CDと組み合わせたいケースや、他システムとの連携を行う場合に利用することができます。

おわりに

今回は脆弱性スキャンを中心にOpenClarityについて紹介しました。

DevSecOpsにおいて「シフトレフト」という考え方があります。ソフトウェア開発ライフサイクルのより早い段階でセキュリティ対策を行うことで早期に脆弱性を発見し、スケジュール遅延や改修コストの増加を防ごうという考え方です。例えば、今回見てきたようなコンテナイメージに含まれる脆弱性の場合、DockerfileがGitリポジトリでマージされる前にCIによりスキャンを行い、マージをブロックするイメージです。

OpenClarityは実際にKubernetesにデプロイされたワークロードをスキャンするため、シフトレフトの考え方に反しているように見えます。確かにシフトレフトを実現するツールではありませんが、OpenClarityのように実際にデプロイされたワークロードをスキャンする方法は開発時にCIによりスキャンする方法に比べて下記のメリットがあります。

1. 実際に稼働しているリビジョンのイメージをスキャンできる
2. 新しく発見された脆弱性を検知できる
3. 自組織で管理していないイメージをスキャンできる

もちろん、CIによるスキャンにもメリットがあります。OpenClarityではデプロイするまでスキャンできないため、コード変更からスキャンまでリードタイムが必要となってしまい、スキャン結果に伴う修正のコストが大きくなってしまいます。そのため、適材適所で様々な方法を組み合わせて、トータルでリスクを軽減することが重要になります。

なお、コンテナセキュリティに関しては、弊社メンバーが翻訳した書籍「コンテナセキュリティ」(Liz Rice著、水元恭平・生賀一輝・戸澤涼・元内柊也訳 インプレス刊)をご参照ください。今回の内容は、本書のChapter 7「イメージに含まれるソフトウェアの脆弱性」に詳細が記載されています。

今回の記事が、皆さまのお役に立つとうれしいです。