Starboard～セキュリティを統一するKubernetesネイティブツール～ #AquaSecurity #コンテナ #セキュリティ #OSS #Kubernetes #Starboard

本ブログは「Aqua Security」社の技術ブログで2020年6月1日に公開された「 Starboard: The Kubernetes-Native Toolkit for Unifying Security 」の日本語翻訳です。

Starboard～セキュリティを統一するKubernetesネイティブツール～

---

クラウドネイティブの世界には、Kubernetes 環境のセキュリティ問題を特定してユーザに知らせるためのセキュリティツールが、Aqua によって作成されたものを含め多くあります。しかしそれらがどんなに強力で有用なものであっても、新しい製品に変わるたび操作方法が変わるため、セキュリティ情報を見つけるために別々のコマンドやツールのセットを学ぶ必要があります。そこで Aqua Security オープンソースチームでは、Kubernetes ネイティブで統合されたセキュリティエクスペリエンスがどのようなものになるかを考えてきました。そして本日、Apache 2.0 ライセンスで公開する、Kubernetes のワークロードや環境のリスクを見つけるためのツールキット Starboard をリリースすることになりました。

Starboard は、Aqua だけでなくサードパーティのプロジェクトからの既存の Kubernetes ツールを Kubernetes エクスペリエンスに統合します。以下のビデオでは、Starboard がどのように脆弱性スキャナー・ワークロード監査・構成ベンチマークテストの結果を Kubernetes CRD(Custom Resource Definitions)に組み込み、そこから Kubernetes API を介してアクセスできるようにしているかを紹介しています。kubectl や Octant のようなダッシュボードツールに慣れているユーザは、簡単にセキュリティリスク情報を見つけることができます。

VMwareのシニアスタッフエンジニアであるBryan Liles氏は以下のように述べています。

"Starboard プロジェクトは、Kubernetes ネイティブのセキュリティレポートをリードしています。このアプローチを使用することで Octant ユーザはセキュリティリスクの詳細を、適用されている Kubernetes リソースと一緒にそれぞれが属する場所に正確に表示できます。"

この Starboard の最初のリリースでは、kubectl プラグイン・Custom Security Resources Definitions のセット・Goモジュール・Octant プラグインを提供し、さまざまなユースケースを可能にしています。Getting Started ガイドに従うことで、Kubernetes API を通じて以下のタイプのセキュリティ情報にアクセスできます。

• 実行中のワークロードの脆弱性情報を Trivy でスキャン
• Fairwinds の Polaris が提供するワークロード監査ログ
• kube-bench が提供するノードごとの CIS ベンチマーク結果
• kube-hunter から提供されたペネトレーションテストの結果

Fairwinds のオープンソース担当ディレクターである Robert Brennan 氏は以下のように述べています。

"複数の Kubernetes セキュリティツールを実行し、管理することは大きな課題です。Starboard プロジェクトの一環として、セキュリティチームや DevOps チームが設定を検証することを Fairwinds Polaris が支援する機会を頂けて私たちは興奮しています。"

Aqua のお客様には Aqua の脆弱性スキャン結果を Starboard に統合する Webhook のPoC も提供しています。

Giant Swarm のデベロッパー・アドボケイト兼プロダクト・オーナーである Puja Abbassi 氏は、このアプローチを支持しています。

"私たちは、Kubernetes ネイティブインターフェースがコミュニティの未来であると強く信じています。私は Starboard にとても興奮しています。それは、Kubernetes のセキュリティ面でまさにそれを実現し、独自のシステムを学習して統合する必要がなくなるからです。"

この最初のリリースは、Starboard のアプローチに取り入れることができる成果の幅広さを説明するためのものです。ロードマップを語る前に、このプロジェクト始動の背景について紹介します。

背景：Kubernetes のセキュリティツール事情

既存の Kubernetes セキュリティツールを見ていると、すぐに2つのことに気づくことができます。1つは、機能・データモデル・アウトプット・ライセンス・成熟度・信頼性などが異なることです。もう1つは、これらのツールが同様あるいは非常に似たような機能・操作手法を持っていることです。

1. Kubernetes API を介して、または YAML ファイルを解析して Kubernetes オブジェクトを発見
2. これらのオブジェクトに対して何らかのリスク評価を呼び出す (例えば、コンテナイメージの脆弱性を見つけるために Trivy バイナリ実行ファイルを実行したり、Go 関数を呼び出して特定の Pod の SecurityContext をチェックしたり、Rego ルールを使って Pod の仕様を評価したりなど)
3. リスクアセスメントレポートを、通常は標準出力またはファイルに出力

これらの異なる、独立した Kubernetes セキュリティツールの結果に対処するのは容易ではありません。これらすべての異種データモデルでは、複数の異なるツールからの結果を組み合わせることはおろか、与えられたツールが提供するすべての機能を活用することは非常に困難です。

すべての Kubernetes セキュリティツールが、誰もが知っていて理解できる同じ言語を話していたらどうでしょうか。標準化されたよく知られた Pod の仕様と同じように、脆弱性、リスク評価チェック、ブラックリストやホワイトリストの脆弱性、あるいはスキャナの設定のためのスキーマを考え出すことができます。さまざまなツールの結果を組み合わせて、現在のセキュリティ状況をわかりやすく把握できるとしたらどうでしょうか。これにより、セキュリティベンダーは自分たちの得意なことに集中でき、他のベンダーは同種のフォーマットでデータを利用できるようになります。

Starboard では、異なるセキュリティツールからの出力をどのように保存し、Kubernetes のネイティブアプローチを使用して組み合わせることができるかを説明しています。

• Kubernetes API を使用してクエリ可能な Kubernetes CRD に結果を格納
• クラスタ内の異なるリソースのセキュリティ評価を効率的に管理するための Kubernetes Operators の利用
• Kubernetes のロールベースアクセス制御(RBAC)を活用して、異なるセキュリティレポートへのアクセス権を持つ人を簡単に管理
• 柔軟なポリシーを用いて、結果を Kubernetes ネイティブの CRD に集約するための Kubernetes Operators の利用

Starboard が役立つ具体的なシナリオを探ってみましょう。

Starboard ユースケース

開発チームのためのセキュリティの実装

Starboard の背景にあるコンセプトの1つは、開発チームが安全でコンプライアンスに準拠したアプリケーションを最初から提供できるようにすることです。下の図のように、Dave Loper は kubectl を使ってアプリケーションのデプロイとテストを行っています。kubectl starboard プラグインのインターフェースを使って、アプリケーションのコンテナイメージをスキャンして、潜在的に危険で悪用可能な脆弱性を見つけることができるようになりました。また、デプロイメントの安定性・信頼性・スケーラビリティに影響を与える可能性のある設定の問題を探すこともできます。これは「シフトシフト」のセキュリティ原則を効果的に実装し、Dave Loper がアプリケーションのセキュリティを向上させるために使用できる情報を提供します。

Dave は、Kubernetes のイントロスペクション、オブジェクト管理プラットフォームである Octant を使用しています。Starboard Octant プラグインを使って、私たちは Octant を拡張し、ユーザーフレンドリーな方法で脆弱性と設定の監査を提示するようにしています。同様のアプローチを使用してカスタムダッシュボードを構築したり、OpenShift Web Console のようなプラグイン可能なサードパーティ製 UI を拡張したりすることもできます。

CRD を使用することで管理者は Kubernetes RBAC を活用でき、Dave のアクセス制限を行うことで彼が関与しているプロジェクトのセキュリティレポートのみ照会できるようにします。

エンタープライズ級の DevOps のためのセキュリティの実装

コマンドラインを使った手動スキャンは便利ですが、限界があります。エンタープライズ級のように膨大な数の Kubernetes ワークロードやマルチテナントクラスタでは、うまくスケールできません。

私たちは Starboard Security Operator を使用して、デプロイメントなどの Kubernetes-native リソースを常に監視し、基礎となるデプロイメントに対して適切なスキャナを実行することで、これらのシナリオに適したオプションを提供しています。スキャンレポートは、ワークロードを実行している Kubernetes クラスタが使用しているインスタンスまたはクラスタの外部にある etcd インスタンスへ、カスタムリソースとして保存できます。

これらは Kubernetes API 経由でアクセスできるため、脆弱性レポートやその他のセキュリティ監査を利用して、 SRE やセキュリティチームに合わせたダッシュボードを構築・統合できます。

同じデータを Starboard Admission Webhook で使用して、過去コンテナイメージで発見された重要な脆弱性の数などのセキュリティポリシーに基づいて、新しいデプロイを承認・拒否できます。 このポリシーの実施は、Starboard に統合されたサードパーティ製のセキュリティツールの結果に基づくこともあります。

セキュリティ製品開発のための実装

Starboard は、追加のセキュリティツールをフレームワークに統合するための Go モジュールを提供しています。

多くのツールでは、ツールの結果に既存の CRD を再利用できる場合があります。例えば、すべてのイメージスキャナはパッケージの脆弱性について同様の情報を報告しています。精度に差はありますが、結果の出力内容はどのスキャナを使用しても似ています。私たちのビジョンは、可能な限り CRD を再利用し、再利用とプラグインの容易性を高めることです。

近々カスタムリソース定義の詳細な仕様を公開する予定です。これにより、既存のセットがニーズを満たしていない場合に、サードパーティが Starboard に準拠した CRD を追加できるようになります。

ロードマップ

このリリースにより Starboard の可能性を感じていただけたと思いますが、将来的にこれを拡張したり改善するための多くのアイデアがあります。皆様からのフィードバックをお待ちしております。

私たちの計画には柔軟でプラグイン可能な Starboard Security Operator の作成が含まれており、各ネームスペースとクラスタ全体のセキュリティリスク情報の「ロールアップ」を可能にします。これによりユーザは容易に高いリスクを特定できるようにします。また、Enterprise DevOps のシナリオで説明したように、Starboard 対応の任意の CRD からセキュリティ情報に基づいてポリシーを決定できる Starboard Admission Webhook も計画しています。

しかし、最も重要なことは、ユーザーからのフィードバックに基づいて計画を進化させていくことです。ぜひ Starboard を利用してあなたの意見を聞かせてください。