2024.03.18

ThreatMapperを使って実利用中コンテナの脆弱性を検出してみた

h-kanno Kubernetes

はじめに

Kubernetesがインフラの選択肢に入るようになってからそれなりに経ち、Kubernetesで利用するコンテナイメージの脆弱性スキャンをCI時に実施したりしているかと思います。

しかし、新たに脆弱性が発見されると安全と言われるバージョンが変わっていくので、CI過程でのスキャンだけだと長期利用するコンテナの脆弱性に気がつけない局面もあるかもしれません。

そんな課題を緩和するDeepfence社のOSS、ThreatMapperをご紹介します。

https://github.com/deepfence/ThreatMapper

(かなり多機能なので今回はコンテナスキャンに的を絞ります)

この記事は「これさえ入れておけば全部大丈夫！」といった事は意図しておらず、「セキュリティのスタートラインに立つ」であったり「コンテナの脆弱性スキャン何もやってなければこの辺りからやってみよう」といった意図になります。

本記事での準拠バージョン

本記事では下記を利用します。

HelmChart

deepfence-console-2.1.1
deepfence-router-2.1.0

主要コンテナイメージ

docker.io/deepfenceio/deepfence_server_ce:2.1.1
docker.io/deepfenceio/deepfence_router_ce:2.1.1

ThreatMapperをざっくり紹介

ThreatMapperは米国の企業、Deepfence社がApache-2.0 licenseで公開しているOSSでCloud-Native Application Protection Platform (以下CNAPP)の実装のひとつです。

1文で紹介するならば、「クラウド、オンプレ、ベアメタル、VM、コンテナ、コンテナイメージ、Kubernetesの脆弱性、コンプライアンス、シークレット、マルウェアのスキャン・可視化を行ってくれるOSS」になります。

CI中のスキャンやコンテナイメージのスキャンだけでなく、利用中のコンテナやベアメタル/VMサーバを定期的にスキャンする機能もあります。

発見された事項をPagerDuty、Slack、Teamsなどへ連携する設定もできます。

Kubernetesもしくはdocker-composeで動作します。

ホームページ： https://github.com/deepfence/ThreatMapper

GitHubリポジトリ： https://github.com/deepfence/ThreatMapper

公式ドキュメント： https://community.deepfence.io/threatmapper/docs/

https://github.com/deepfence/threatmapper

エンタープライズ版について

ThreatMapperには機能強化/追加を施し、サポートも付いたThreatStrykerという製品があります。

Deepfence社のホストするSaaS版の他、AWS Marketplaceからもご利用可能です。

詳細や機能の比較などはDeepfence社の公式ページを参照してください。

詳細: https://www.deepfence.io/threatstryker

機能比較: https://www.deepfence.io/compare

ThreatMapperで緩和する問題

脆弱性の監視体制が整っていない
クラウドのコンプライアンスがちょっと心配
シークレットを平文で格納してしまっている
マルウェアスキャンを行っていない
SBOMが無くてOSS監査に手間取っている

といった問題を緩和することができます。

本記事では実利用中のコンテナに対し定期的に脆弱性スキャンを実行し、ある程度の脆弱性監視体制を整えるまでを実践してみます。

ThreatMapperの構成

基本的にはスキャン対象にエージェントを導入し、ThreatMapper Management Consoleに情報を連携する構成を取っています。

参考画像に表現されていませんが、クラウドのコンプライアンススキャンなどにはエージェントは利用されず、クラウドのAPIを利用するようです。

詳しくは公式のドキュメントを参照してください。https://community.deepfence.io/threatmapper/docs/architecture/

https://github.com/deepfence/threatmapper

ThreatMapper Management Consoleの構築

ここからは構築手順の紹介になります。

consoleの見た目や具体的にどのようなデータが取れるのか確認したいだけであれば公式のdemo環境にログインするのがオススメです。https://community.deepfence.io/threatmapper/docs/demo

システム要件

v2.1現在の要件は画像の通りになります。

最新情報は公式ドキュメントを参照してください。https://community.deepfence.io/threatmapper/docs/console/requirements

お試しにピッタリ、docker-composeでの構築

公式GitHubからdocker-compose.yamlを取得し、docker-composeコマンドより構築します。

wget https://github.com/deepfence/ThreatMapper/raw/release-2.1/deployment-scripts/docker-compose.yml
docker-compose up -d

常設にピッタリ、Helmを使ってKubernetes上に構築

前提

今回はThreatMapper Management Console用と監視対象用の2クラスタを手元のPCにkindを利用して構築、検証しました。

オンプレの場合はStorageClassを準備する必要があります。ThreatMapperの公式ドキュメントではOpenEBSを用いていたので、それに倣いOpenEBSを導入しました。

Ingressリソースは細かくカスタマイズしたかったので、Helm Chartで構築せずに自前で用意する手順を取りました。

また、PostgreSQLだけ上手く稼動しない可能性があるので、その場合は別途bitnami/postgresql Helm Chartで自前構築するかマネージドサービスなどをご利用ください(本記事でも自前で構築しています)。

各種パラメータはThreatMapperの公式ドキュメントを参照してください。 https://community.deepfence.io/threatmapper/docs/console/managed-database

参考までにbitnami/postgresqlチャートでの構築に利用したvalues.yamlを掲載しておきます。

global:
  postgresql:
    auth:
      postgresPassword: "===CHANGE TO YOUR postgres USER PASSWORD==="
      username: "deepfence"
      password: "===CHANGE TO YOUR deepfence USER PASSWORD==="
      database: "deepfence"

手順

Helm Chartを入手する

helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper
helm repo update

valuesのテンプレートを入手する

helm show values deepfence/deepfence-console --version 2.1.1 > deepfence_console_values.yamlhelm show values deepfence/deepfence-router --version 2.1.0 > deepfence_router_values.yaml

valuesのテンプレートを編集し、環境に合わせた値を入れる
- 長いので差分のみの記載とします。

deepfence_console_values.yaml

global:
  imageTag: 2.1.1
  storageClass: "openebs-hostpath" # AWSの場合はgp3, GCPの場合はstandard
kafka:
  config:
    # kafka-storage.sh random-uuidコマンドなどで生成する
    STORAGE_UUID: "===CHANGE TO YOUR UUID==="
postgres:
  create: false # このHelm ChartでPostgreSQLも構築する場合はtrue
  secretName: "secrets-postgres"
fileserver:
  secrets: # 各シークレットはランダム生成するなりしておく
    MINIO_ROOT_USER: "===CHANGE TO YOUR MINIO USER==="
    MINIO_ROOT_PASSWORD: "===CHANGE TO YOUR MINIO PASSWORD==="
neo4j:
  secrets:
    # set the below to change the default credentials
    # format should be username/password
    NEO4J_AUTH: "neo4j/===CHANGE TO YOUR NEO4J PASSWORD==="

deepfence_router_values.yaml

service:
  type: ClusterIP # LoadBalancer/NodePort/Ingress/ClusterIPから選択

作成したvaluesを用いてThreatMapper Management Consoleを構築する

helm install -f deepfence_console_values.yaml deepfence-console deepfence/deepfence-console \
    --namespace deepfence-console \
    --create-namespace \
    --version 2.1.1

helm install -f deepfence_router_values.yaml deepfence-router deepfence/deepfence-router \
    --namespace deepfence-console \
    --create-namespace \
    --version 2.1.0

ThreatMapper Management ConsoleがPostgreSQLに接続するために利用するシークレットを作成しておく

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: secrets-postgres
  namespace: deepfence-console
stringData:
  DEEPFENCE_POSTGRES_USER_DB_PORT: "5432"
  DEEPFENCE_POSTGRES_USER_DB_HOST: “===CHANGE TO YOUR POSTGRESQL HOST===”
  DEEPFENCE_POSTGRES_USER_DB_SSLMODE: disable
  DEEPFENCE_POSTGRES_USER_DB_USER: deepfence
  DEEPFENCE_POSTGRES_USER_DB_PASSWORD: "===CHANGE TO YOUR deepfence USER PASSWORD==="
  DEEPFENCE_POSTGRES_USER_DB_NAME: deepfence

ユーザ、監視対象のクラスタがThreatMapper Management Consoleに接続するためのIngressを作成する

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: 200m
  name: deepfence-router-ingress
  namespace: deepfence-console
spec:
  ingressClassName: nginx
  rules:
    - host: “===CHANGE TO YOUR FQDN===”
      http:
        paths:
          - backend:
              service:
                name: deepfence-console-router
                port:
                  number: 443
            path: /
            pathType: Prefix
  tls:
    - hosts:
        - “===CHANGE TO YOUR FQDN===”
      secretName: router-tls

Helmで構築したpodが正常動作し、Ingressで指定したFQDNにwebブラウザから接続してログイン画面が表示されれば正常に構築が完了しています

使い方

スケジュール機能検証のためにKubernetesホストの時間をずらして検証しているので、一部深夜や未来の時間が表示されたりしていますが、気にしないでください。

ユーザセットアップ

webブラウザからThreatMapper Management Consoleに接続する
- docker-composeで構築した場合は構築マシンのIPアドレス、もしくはFQDNにwebブラウザから接続する。
- Kubernetesで構築した場合はIngressで指定したFQDNにwebブラウザから接続する。