"Grafeas"メタデータAPIと"Kritis"デプロイオーソライゼーションによるソフトウェアサプライチェーン管理

コンテナのセキュリティをテーマとした先日のGoogle Cloud Platform(GCP)ブログのシリーズの中で、GCPチームが、既存および提案中のオープンソースのソフトウェアサプライチェーンプロジェクトに関する詳細を発表した。そのひとつであるGrafeasは、ビルドの詳細やテストステータス、既知のセキュリティ問題といった、ソフトウェアコンポーネントに関わるメタデータの格納、クエリ、取得を目的とする共通APIと言語である。もうひとつのKritisは現在提案中で、Grafeasに格納されたメタデータを使用して、Kubernetes上のリアルタイムなデプロイメントポリシを構築および実施することにより、既知の問題を含んだコンテナイメージのデプロイを防止するソフトウェアサプライチェーン管理フレームワークである。

GCPブログの記事の説明によると、コンテナ技術によって、コンテナイメージにパッケージされたアプリケーションを手軽に作成、修正、共有できるようになった。しかしながら、このようにデプロイが短時間で行えるようになったことが、コンテナ化されたアプリケーションが品質保証をパスしているか、セキュリティ上の脆弱性を含んでいないか、といった検証の必要性などの安全性と引き換えになっている可能性がある。このような疑問に答えるひとつの方法は、作成者、機能テストおよび非機能テストの実行結果、既知の脆弱性の有無といった、コンテナに関するメタデータをトラッキングすることだ。

昨年10月、コンテナイメージの構造化メタデータAPIを提供するオープンソースプロジェクトのGrafeasが、Googleと数社のパートナから発表された。Grafeasは、パッケージの脆弱性検査結果などのセキュリティ上の懸念を含むメタデータの操作を簡易化して、この情報をトラッキングする。

• “Build”メタデータは、そのコンテナイメージが、チェックインされたソースコードから、信頼できるビルダを使用して、ビルドポリシに従って構築されたことを証明するために使用される。
• “Package Vulnerability”メタデータには、脆弱性スキャンサービスによる情報が格納されており、脆弱性のあるコンテナのデプロイに関するポリシの作成を可能にする。
• “Image Basis”メタデータには、コンテナの派生元となったベースイメージと、コンテナイメージ構築に使用された追加レイヤの情報が含まれている。
• “Package Manager”メタデータは、コンテナイメージにインストールされたパッケージが何であるかを示している。
• “Deployment History”メタデータは、どのリソースがいつデプロイされたかを追跡可能にする。

Grafeasでは、ノート(note)とオカレンス(occurrence)という２つのAPIコンセプトを使用する。この２つを分割したことにより、サードパーティのメタデータ提供者が、多くのユーザに代わってメタデータの作成や管理を行うことが可能になる、と資料には説明されている。

• ノートは、分析によって検出されるアイテムないし条件で、プロセス内で何度も使用されるものだ。Linuxパッケージの脆弱性分析の結果としてのCVE(共通脆弱性識別子)がその例である。ビルドプロセスでは、ビルダに関する情報がノートに格納される。
• オカレンスはノートをインスタンス化したものと考えられ、特定のクラウドリソースないしプロジェクト(ロケーションや特定の修復手順など)に存在するノート、特定のノートの結果(ビルドを行った結果のコンテナイメージなど)などを記述したものである。例えば、コンテナイメージのあるパッケージにOpenSSLのHeartbleedバグが(ノートとして)あることを報告し、顧客のパッケージに基づいたHeartbleedバグの修正方法を含むオカレンスが考えられる。

Grafeasに格納されたメタデータを適切に集約するため、格納された情報の各種類には厳密なスキーマがある。これらスキーマによって複数の提供者からのデータの正規化が可能になり、各コンポーネントから有意義な洞察を得ることができるようになる。現時点でサポートされているスキーマは、下図のようなものだ。

新たなメタデータタイプのサポートが必要になれば、その独自のスキーマを持った新しい種類が追加される。

Grafeasのメタデータをトラッキングすることで、チームの環境内に格納されているコンテナが何かを理解できるだけでなく、デプロイするコンテナを制限することも可能になる。エンジニアはGrafeasのメタデータを参照して、デプロイ前にポリシへの準拠性を確認することができる。事実の確認ないし認証として追加されたメタデータの“Attestation”が、この目的で使用される(ビジネスにおけるアテステーション(attestation、監査証明)とは、会計士や監査人が、企業や公的機関、その他の組織に関する財務などの公開情報に対して、独立的な意見を提供するものである)。Grafeasから取得したメタデータが組織のポリシに一致すれば、そのイメージがデプロイメント要件に準拠していることを証明するアテステーションの記述が可能になる。下図はGrafeasを紹介するGCPの記事から引用したもので、このツールを一般的な継続的デリバリパイプラインに適用する方法をまとめている。

先日のホワイトペーパで、GCPチームは、Kubernetes用のデプロイメント認証フレームワークの“Kritis”を発表した。Kritisフレームワークの中核となるKubernetes Admission Controllerは、必要なアテステーションをチェックし、存在しなければそのデプロイをブロックするために使用される。ホワイトペーパによると、Kritisは基本的な受入管理に加えて、“ワークフローの実施、複数権限の署名、Break Glassデプロイメントなど”もサポートしている。公開されているKritisのアルファ実装はBinary Authorization(BinAuthz)と呼ばれ、Google Container Engine (GKE)上で動作可能なもので、近々オープンソースとしてリリースされる予定である。

BinAuthzの中心となる概念は“アテステーションオーソリティ(Attestation Authority)”と“ポリシ(Policy)”で、RESTリソースとして実現され、REST APIを通じて管理される。Attestation Authorityは、アテステーションを生成する権限を持った名前付きエンティティで、RESTリソースとして、アテステーションのロケーション(どこに格納され、どこから取得されるか)と、検証基準(アテステーションを有効にするのは何か)をカプセル化する。ポリシは、アーティファクトをターゲットにデプロイするために必要なアテステーションを生成するアテステーションオーソリティである。アテステーションオーソリティは、このオーソリティのアテステーションのアンカ(anchor)として使用される(“ATTESTAION”という種類の)Grafeas Noteを指名し、アテステーションに署名が必要な場合は公開鍵をオプション指定する。このオーソリティによるアテステーションは、そのオーソリティのノートにアタッチされたオカレンス(Occurence)として表現される。

Spotifyは先日、同社が1日当たり6,000以上のコンテナと、コンテナレジストリにある330,000のイメージのコンテナメタデータを集中管理する真のソースとして、同社内でのGrafeasとKnitisを運用している方法について論じた。これによってセキュリティチームは、ユーザに提供するソフトウェアの適切な監査およびライフサイクル戦略を実装することが可能になる。継続的インテグレーション中には、コンテナに対して数多くの監査(自社製のツールセキュリティ監査ツールであるkubeauditを含む)が実施され、アテステーションが生成され、PGPを使って暗号化された署名が行なわれる。これによって同社のビルダと、その他のアテステーションオーソリティを識別している。これらのアテステーションがポリシを構成し、それがKubernetes上のKritisで実行される。

Grafeasに関するさらなる情報は、プロジェクト資料やGitHubリポジトリで確認できる。Grafeasはさまざまなセキュリティポリシの実施に使用することができる。Kelsey Hightower氏が、Grafeasを使って特定の秘密鍵で署名されたコンテナイメージのみを実行可能とする方法について、チュートリアルを提供している。