この記事では Tanzu Application Platform (TAP) のセキュリティ機能である Scan, Sign, Store について解説します。いままでにない、セキュリティの考え方になっており、新たな発見を得られる内容かもしれません。
TAP セキュリティの合言葉：Scan、Sign、 Store
TAP のセキュリティですが、「Shift Left」の発想を取り入りています。
「セキュリティ = アンチウィルスソフト」のように、エージェントをインストールするようなイメージをもっている方も多いと思います。しかし、このアプローチですが、「いじめの問題を学校中に監視カメラを配置する」という解決策に似ています。以下のような問題が発生します。
- 監視カメラの目が届かない場所がうまれるかもしれない
- セキュリティツールが万能でない可能性がある
- 監視カメラが学校生活を息苦しい場所にして転校が多くなるかもしれない
- 開発者がセキュリティ設定が緩やかな環境に逃げていく可能性がある
- 本質的ないじめ問題を解決していない
- 本質的なセキュリティ問題を解決していない
このような背景から、セキュリティの問題を根本的に発生しにくくし、監視カメラもしくはエージェントすらいらないレベルまでセキュリティが当たり前に設定されている手法が重要になってきます。その上で開発生産性を落とさないアプローチとして、「 Shift Left 」のアプローチが注目されています。TAP では、セキュリティを開発の流れ、すなわち TAP の Supply Chain に組み込んだ形で提供しています。
この Supply Chain の過程ですが、主に、3つの機能で表現することができます。
- Scan : TAP では、二段階のスキャンが実施されます。ソースコードそのもののスキャン、作成されたコンテナのスキャンの二段階で実施されます。二段階のスキャンにより、脆弱なコードが環境にデプロイされることを防ぎます。
- Sign : イメージの署名を行います。厳格な環境の場合、署名を受けたイメージ以外のデプロイを防ぐといったことを実施します。
- Store： Scan のフェーズでそのスキャニングの結果をデータベースに保管をして、高速な検索を実現します。
ここから、この機能について紐解いていこうと思います。なお、順番は Scan > Store > Sign の順に紹介します。
デプロイのセキュリティの徹底：Scan 機能
TAP のセキュリティの基本機能であり、ソースコードおよびイメージのスキャンを実施します。この機能を提供するために、特記するべきがAnchore Grype がつかわれている点です。後ほど Store の際に触れますが、知名度はまだ高くないもの SBoM (Software Bills of Materials)の考えを導入した数少ない OSS です。
まずは、手取り早く試してみたいと思います。この機能を使うには TAP の Full Profile インストールが必要です。インストールが完了したら、以下のようにシンプルなアプリケーションをデプロイしてみたいと思います。ここでは TAP の公式サンプルコードを使ってデプロイします。
tanzu apps workload create tanzu-java-web-app \
–git-repo https://github.com/sample-accelerators/tanzu-java-web-app \
–git-branch main \
–type web \
–label apps.tanzu.vmware.com/has-tests=true \
–yes
このパッケージですが、特に問題がないので、正常に設定されていれば、そのままデプロイが成功するはずです。kubectl 経由で sourcescans と imagescans にスキャンの結果が保存されます。この脆弱性スキャンの際に さきほど紹介された OSS である Grype が使われています。
では、次に以下のコマンドを実行したいと思います。ここは、Apache のサイトに公開されている2005年に公開されているサンプルアプリケーションを使いたいと思います。すでに20年近く経っており、脆弱性が含まれる可能性が高いです。
まずは、以下のようにソースコードをダウンロードします。
wget https://archive.apache.org/dist/struts/struts-1.2.7/struts-1.2.7.zip
unzip struts-1.2.7.zip
cd struts-1.2.7/webapps
そして、この状態で Tanzu のワークロードを作成します。
tanzu apps workload create old-struts \
–local-path ./struts-examples.war \
–source-image harbor.lespaulstudioplus.info/library/old-struts \
–type web \
–label apps.tanzu.vmware.com/has-tests=true \
–yes
しばらくすると、以下のように sourcescans の結果が Error になっているはずです。これは期待通り、セキュリティ検査によって脆弱なコードが環境にデプロイされるのを阻止しています。これが、Scan 機能の概要です。
SBoMの活用：Store 機能
Scan 機能で脆弱性の検査が行われますが、その検索結果は SBoM (Software Bills of Materials)の形で metastore とよばれるデータベースに保管されます。SBoM とは、パッケージの情報やバージョンをまとめたメタ情報です。通常の脆弱性検査に比べて、メタ情報のみの検索を行うため非常に高速に脆弱性検査ができることがメリットです。この「高速」は環境が小さい時こそ、恩恵は感じにくいですが、環境が大きくなっていくにつれて、脆弱検査のスピードが重要になっていきます。
TAP では専用の CLI である insight コマンドもしくは API を直接使い metastore に保管された SBoM の検索が行えます。ここでの SBoM は先ほど紹介された Grype によって生成されています。以下 TAP によって作成されたイメージの検索結果ですが、そのイメージに含まれるパッケージ、バージョン、それにともなった脆弱性の照合までを瞬時で結果として得られます。
metastore を「脆弱性が報告された時に該当するイメージを瞬時にリストをしていく」などの機能ができるようになり、すばやく対応につなげていくことができます。
信頼されていないイメージのデプロイを防ぐ：Sign 機能
最後の機能が、Sign 機能です。Kubernetes では当たり前ですが、コンテナのフォーマットに従っていれば、なんでも起動ができてしまいます。ところが、セキュリティを考えた場合、 TAP の SupplyChain のプロセス以外で作成されるイメージを許可しないなどの制限を設ける必要性がでてきます。この「 TAP の SupplyChain のプロセス以外で作成されるイメージ」の判別の方法として使われるのが、イメージの署名、Sign 機能です。TAP では、 OSS である cosign を使った署名機能を使います。
cosign 自体は基本的な機能は以下の Gif で紹介されていますが、秘密鍵によるイメージの署名、そして公開鍵によるイメージの認証をおこなうというシンプルなものです。
TAP 1.0 では、単一クラスタのみに構成をサポートしていないため、現段階では恩恵が受けにくいですが、今後サポートされるマルチクラスタ構成の場合、以下のような構成がとれるようになっていきます。
- TAP をビルドクラスタ、Staging クラスタ、Production クラスタといった形でコンポーネントを分散させる
- ビルドクラスタの役目は TAP を使いセキュアなイメージをつくること
- ビルドクラスタに秘密鍵を登録して、イメージの署名
- 実際のワークロードは Staging クラスタ、Production クラスタにて稼働
- Staging クラスタ、Production クラスタには公開鍵を登録して、認証以外のイメージを許容しないようにする
このようにTAPでは配布方法に関してもセキュアな手段を提供していきます。
まとめ
以上 TAP のセキュリティ機能の Scan, Sign, Store を紹介しました。新しい考え方でいろいろなヒントにつながったと思います。VMware ブログでは引き続き TAP の様々な機能を掘り下げて紹介させていただきます。
