@amsy810's Blog

~Kubernetes / Cloud Native / Docker / etc~

OpenClarity プロジェクトの KubeClarity で始めるお手軽 SBOM/脆弱性管理

OpenClarity プロジェクトと KubeClarity を用いた SBOM 管理

この記事は Kubernetes Advent Calendar 2022 の 2 日目の記事です。

こんにちは。 サイバーエージェント CIU(CyberAgent group Infrastructure Unit)で KaaS 基盤のプロダクトオーナーを務めている青山です。 採用もしているので、ご興味のある方はぜひ Twitter DM などいただければと思います。

今回の Advent Calendar は、去年の KubeCon で印象に残っていた APIClarity の兄弟プロダクトである、KubeClarity について紹介しようと思います。 (2020/2021 に引き続きおうちKubernetesでCSIガチネタしたかったのですが、時間が取れず…)

APIClarity との出会い

APIClarity は API リクエストをキャプチャ・分析し、OpenAPI Schema の再生成・Zombie API の検知・Shadow API の検知などを行うプロダクトです。これにより、潜在的なリスクを特定したり、Observability の手助けをすることができます。

去年参加した KubeCon + CloudNativeCon NA 2021で知り、アーキテクチャが面白かったので記憶に残っていました。

APIClarityでは、Istio で構成されたサービスメッシュ上の各 Envoy Proxy 内で、Proxy-WASM を利用して実装された WASM のプログラムを動作させ、APIリクエストを収集します。

APIClarity について興味がある方は、詳細について下記を参照してみてください。

ebpfとWASMに思いを馳せる2022 / techfeed-conference-2022-ebpf-wasm-amsy810 - Speaker Deck

OpenClarity プロジェクト

OpenClarity は、セキュリティや Observability のための OSS ツール群を開発するプロジェクトです。 APIClarity も OpenClarity プロジェクトが公開するプロダクトの一つです。 Cisco がリードしています。

今年の KubeCon + CloudNativeCon NA 2022 では、(おそらくスポンサーの)Keynote で OpenClarity について紹介されていました。

現段階では下記の 3 種類のプロダクトが公開されています。

  • APIClarity
  • KubeClarity
  • FunctionClarity

KubeClarity

今回紹介する KubeClarity は下記の 3 つのことを実施することができます。 また、現状内部で利用されているスキャナー類は Syft/Grype/Dockle ですが、別のプロダクトの利用も視野に入れているようです。

  • SBOM(Software Bill Of Materials)の生成
    • Content Analyzer: Syft
  • 脆弱性スキャン
  • CSI Docker Benchmark のテスト
    • Banchmarker: Dockle

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

コンテナイメージのスキャン・解析はクラスタ上で実行されているイメージ単位で Job リソースが作成されて実施されます。 Job リソースが作成されると、内部では下記の2つの Scanner が動作します。 Syft/Grype/Dockle はそれぞれ Go の SDK が提供されているため、それを用いてスキャン・解析を行っています。

現状デプロイされるJobは実際にコンテナイメージを持っているノードに明示的にスケジューリングし、そのノード上のイメージを利用するなどは行っていません。 クラスタ上にデプロイされているイメージを再利用したスキャンの仕組みを実装することは以前から考えていたので、そのあたりの機能がKubeClarityにも入ると良さそうだなと考えています。

Syft と Grype による脆弱性スキャンの高速化

Syft はコンテナイメージ単位でインストールされたパッケージ類のリストである SBOM を生成します。 Grype は Syft が生成した SBOM を用いて脆弱性の有無を検査することができるため、再度コンテナイメージをスキャンするのと比較して、高速に脆弱性スキャンを実施することが可能です。

実際に runtime_k8s_scanner の実行部分を確認すると、SBOM DB からデータの取得を試み、結果を利用しています。

KubeClarity におけるデータ

KubeClarity では、データを 4 つに分類して管理しています。

  • Application: 実行されているPod(実際にはDeploymentなどの粒度)
  • Application Resource: コンテナイメージ
  • Package: 利用しているパッケージ(rpmdeb などの OS 系 / npm や gomod などの言語系)
  • Vulnerability: 脆弱性情報

WebUI

Web UI は使いやすく作られており、脆弱性対応のはじめの一歩や簡易的に実現する手段としても重宝できそうです。

UI からは Pod・コンテナイメージ・パッケージ・脆弱性情報(CVE)それぞれの情報で検索をかけることが可能になっています。 運用を考えた際生じる、下記のようなオペレーションが可能です。

  • 特定の CVE に紐づくコンテナイメージの一覧を取得
  • 特定のバージョン以下のパッケージを利用しているコンテナイメージ一覧を取得
  • 特定の CVE に紐づく Pod 一覧(現在クラスタで起動しているもの)を取得
  • 特定のパッケージを利用している Pod 一覧(現在クラスタで起動しているもの)を取得

KubeClarityの導入は非常に簡単かつ環境に影響を与えないため、一度クラスタにデプロイしてスキャンを実施し、

などを行って、定期的に単発で対応するといったことにも可能です。

また、特定の脆弱性が出たタイミングで導入してスキャンし、一覧を習得した上で、特定の脆弱性を持ってしまっているDeploymentを洗い出すといったことにも利用可能です。

もちろん CVE に関する情報も確認することができます。

SBOM の情報と紐付けて、それらのパッケージがどの程度実行しているPodから使われているか、コンテナイメージに含んでいるかなどを確認することもできます。

Dockle も有効にしてスキャンしている場合には、Dockerfile で修正したほうが良い箇所も確認できます。

他にも、様々な形で情報を表示することが可能です。

まとめ

今回は比較的用意に SBOM や脆弱性管理を行うことができる KubeClarity について紹介しました。 OpenClarity Project では、あったら嬉しいプロダクト開発がされている印象なので、今後もウォッチしていきたいですね。

ちなみに 3-shake さんのイベントでこのあたりをデモ付きで紹介する予定なので、よければご参加ください :)

3-shake.connpass.com