サードパーティコンテンツを安全に利用する

KubernetesのAppSec戦略構築に関する全4回シリーズの最終回です。

前回までの記事はこちらです。

• SDLC全体におけるコンテナセキュリティ

• セキュリティのシフトレフトに必要なのは、ツールだけでなく文化の変革

• イメージセキュリティからワークロードセキュリティへ

Kubernetesのアプリケーションセキュリティについての議論で、まだ触れていないテーマがあります。それは、ファーストパーティアプリケーションとサードパーティアプリケーションの違いです。

本番システムの観点から見ると、この2つに大きな違いはありません。アプリケーションを自社で開発したか、他社が開発したかにかかわらず、多くの共通点があります。いずれの場合も、アプリは本番データに何らかの形でアクセスし、アプリケーションの脆弱性によって、そのデータや関連システムがある程度侵害される可能性があります。従来の運用の観点では、ファーストパーティアプリとサードパーティアプリを同じように扱うのは簡単です。しかし、運用責任の一部を開発チームに移す場合はどうでしょうか。

アプリケーションのパッケージ化

Kubernetesでは、Helmのようなツールを使ってサードパーティアプリケーションをインストールするのが一般的です。Helm Chartsリポジトリには、aerospikeからzetcdまで何百ものアプリケーションの設定が含まれており、大幅な時間短縮につながります。ソフトウェアを利用者に提供するベンダーも、Helmを使ってアプリケーションをパッケージ化するケースが増えています。Helm chartにはアプリケーションのインストールに必要な設定が含まれており、通常は一連のサードパーティイメージを参照します。最近では、同様のパターンに従うCloud Native Application Bundles（CNAB）の取り組みも見られます。

LinkerdのHelm chartを例に、簡単に見てみましょう。

$ tree
.
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── config.yaml
│ ├── daemonset.yaml
│ ├── ingress.yaml
│ └── service.yaml
└── values.yaml

1 directory, 9 files.

このchartの内容のうち、セキュリティに影響する可能性があるものは何でしょうか。Values.yamlファイルには、脆弱性を含む可能性のあるコンテナイメージがいくつか記載されています。

image: buoyantio/linkerd:1.1.2
image: buoyantio/kubectl:v1.6.2

valuesファイルでは、適切なリソース上限も設定しています

resources:
limits:
cpu: 500m
memory: 512M

テンプレート、特にdaemonsetにはコンテナ仕様が含まれており、さまざまなセキュリティプロパティを設定できます。たとえば、コンテナをrootで実行するか、読み取り専用ファイルシステムを使うか、必要な権限のみを要求するか、Podセキュリティポリシーを設定するかなどです。

SDLC全体におけるサードパーティアプリケーション

こうしたパッケージ化の考慮事項は、SDLCのどこに当てはまり、ライフサイクル全体でセキュリティをどのように徹底すればよいのでしょうか。

• ローカル：サードパーティのchartを使っている場合、開発チームがローカル環境でその作業をしていない可能性があります。

• CI/CD：chartのインストール方法によっては、HelmfileやTerraformなどの設定ファイルで参照しているかもしれません。しかし、そこでテストを実施していることはほとんどなく、あってもスモークテスト程度でしょう。

• レジストリ：Helm chartは通常、パブリックリポジトリのイメージを参照します。一般に、参照先を社内イメージに置き換えることはできますが、社内に保管したイメージを最新の状態に保つプロセスが必要です。

単体で動作するアプリケーションの場合、現在、脆弱性を確認できる最も早い段階が本番環境へのデプロイ時ということも十分にあり得ます。つまり、サードパーティコンテンツに関する判断を開発者に委ねるという現実と、そうしたサードパーティアプリケーションを安全に利用できるかどうかについて、ツールが迅速にフィードバックを提供する能力との間に隔たりがあるのです。

サードパーティアプリケーションの種類

大まかに分類すると、サードパーティアプリケーションは次の2種類に分けられます。

• WordPressやJenkinsのように、特定の独立した価値を提供する単体アプリケーション。

• RedisやPostgreSQLなど、ファーストパーティアプリケーションの直接依存関係。

サードパーティアプリケーションが環境に導入される方法を見ると、この区別が役立つ理由が分かります。単体アプリケーションは、多くの場合、運用チームやプラットフォームチームにとってより大きな懸念事項です。中央チームがインストールと管理を行い、ほかの開発チームにサービスとして提供します。一方、直接依存関係は、個々の開発チームが管理することが多いものです。サードパーティのサプライチェーンセキュリティに取り組むには、両方の視点を考慮する必要があります。

まとめ

この問題にどう対処すればよいのでしょうか。自動化を進め、パイプラインの早い段階でサードパーティコンテンツを簡単に検証・テストできるように設計することが重要です。このパイプラインは、既存のパイプラインがない可能性のある単体アプリケーションにも、既存アプリケーションの依存関係のテストにも対応できる必要があります。

この問題を解決するには、ソフトウェアサプライチェーン全体を考える必要があります。Helm Chart、Operator、あるいは設定とイメージ参照をまとめた同様のバンドルを簡単にチェックできるローカルツールが必要です。サードパーティコンテンツが変更された際に、その変更が利用上のリスクにどう影響するかを把握できるよう、必要に応じてすぐに立ち上げられるCI/CDパイプラインも必要です。外部イメージを信頼できる環境に取り込むための、効率化されたパイプラインも求められます。信頼できる脆弱性データを共有するための標準が生まれることも期待されます。

開発者へ責任を急速に移している環境でも、サードパーティアプリケーションを安全に利用することは可能です。そのためには、利用プロセスを十分に検討し、そのプロセスを可能な限りSecure SDLCに組み込む必要があります。