IBM Cloud Code Engine: 継続してセキュリティーを保護しコンテナを実行する

もうCVEは気にしないで、本来の開発に戻れるようになります

企業がクラウドに移行する企業が増えるにつれ、コンテナの使用が急速に増加しています(参照:英文ブログ)。そして、より多くの重要なワークロードがコンテナ化される中で、セキュリティーが最大の課題の一つであることに変わりはありません。コンテナは優れていますが、それ自体にもセキュリティー上の問題があります。特に、コンテナ・イメージに脆弱性が含まれていないことを確認することは難しい問題であり、見落とされがちな問題です。

開発者はコードを書くのは好きでも、本当に安全なコンテナイメージを作成することになると、複雑で時間がかかることから、あまり興味がなかったりすることがよくあります。この記事では、この問題を解決するために、IBMの最新のサーバーレス・コンテナ・プラットフォーム IBM Cloud Code Engineを使用する方法を説明します。

IBM Cloud Code Engine

IBM Cloud Code Engineは、あらゆるクラウド・ネイティブ・ワークロードをホストできる、フル・マネージドのサーバーレス・プラットフォームです。ユーザーエクスペリエンスなどは開発者中心に設計されているので、開発者は、基礎となるインフラストラクチャーやそのセキュリティーに対処する代わりに、コードを書くことに集中できるようになります。

IBM Code Engine でアプリケーションを実行するためのオプションを見てみましょう。

1. コンテナ・レジストリ（IBM Cloud Container Registry や dockerhub など）に構築済みのイメージがあり、それをデプロイしたい場合。
2. リポジトリ（GitHub など）にソース・コードがあり、ビルド手順を含む Dockerfile がある場合。
3. リポジトリ（GitHubなど）にソースコードがあり、それ以外には何もない場合。

上の表で概説したように、これらのオプションはそれぞれセキュリティーとメンテナンスのトレードオフの方法が異なります。オプション 1 と 2 は、デプロイできる内容においては柔軟性は最大ですが、コストがかかります。コンテナ・イメージを生成するためのビルド・システムが必要であり、その内容のすべて(例: アプリケーションフレームワーク、依存関係、ベース OS イメージ・レイヤーなど)に責任を持つ必要があります。いくつかのコンテナ・レジストリ（例: IBM Cloud Container Registry ）は、イメージをスキャンして潜在的な脆弱性について警告するのに役立ちますが、これらのセキュリティー問題に継続的に対応する責任は、利用者自身にあります。

これとは対照的に、上の表のオプション 3 を例に Java アプリケーションを考えてみましょう。ソース・コードとその直接の依存関係を提供し、あとはCode Engineに任せます。基礎となるすべてのレイヤー（オペレーティング・システム、JREなど）は、IBMによって提供され、保護されます。これにより、メンテナンスのコストが大幅に削減され、セキュリティー体制が強化されます。ご自身で用意するレイヤーが少なくなればなるほど、それだけ責任も少なくなります。

現在、IBM Code Engineは2つのビルド戦略をサポートしており、上記のオプション2と3に対応しています:

• “Dockerfile Build(英語)” (Keniko ビルダー・ツールを使用)
• “Cloud Native Buildpack(英語)” (Paketo ビルダー・ツールを使用)

“Dockerfile build”を使用するには、アプリケーションのソースコードとDockerfileをビルド指示とともに提供します。オプション1と比較すると、これはセキュリティー上の管理をIBMにまかせることができます(ビルドはルートレスでDockerデーモンレスなアプローチで実行されます)。しかし、アプリケーション・フレームワーク、依存関係、ベースOSイメージに対する責任はまだ利用者自身にあり、新たな脆弱性がないか継続的に監視し、効果的かつ迅速に修正する必要があります。

“Cloud Native Buildpacks”オプションを選択した場合、提供する必要があるのはソース・コードだけです。Cloud Native Buildpack は、アプリケーション言語を検出し、特定のビルダーを選択し、ベース OS 上にイメージを構築します。IBM はソース・コードの下にあるすべてのレイヤーを提供しているため、そのセキュリティーを維持する責任を負います（例えば、脆弱性がある場合には更新された JRE を提供するなど）。

その結果、イメージはコンテナ・レジストリに保存され、新たな脆弱性が発生した場合にはフラグが立てられます。必要なのは”リビルド” をクリックして、更新された安全なイメージ上にコードを再度デプロイすることだけです (これは将来的には新しいオプションで完全に自動化されるかもしれません)。

まとめ

IBM Cloud Code Engine は、コンテナ化されたワークロードを実行するための 3 つの選択肢を提供します。すでにレジストリにイメージがある場合は、Code Engine で”そのまま”実行してください。しかし、ビルド・オプションを使用して、Code Engine がコンテナ・イメージのビルドを実行することをお勧めします。これにより、コンテナイメージの脆弱性の問題を継続的に見つけて修正する責任から解放されます。

これで開発者は本来の仕事に戻り、コードを書くことに集中することができます。今後のブログ記事では、IBM Cloud Code Engine が実際にどのようにビルドを実行しているのか、詳細を見ていきたいと思います。

この機会にぜひIBM Code Engineをお試しください

IBM Code Engineは、Shipwright-io/build, Tekton, Kaniko, Paketoなどのオープン・ソース・テクノロジーで構築されています。IBM Code Engineについてさらに詳しいことは、ブログ”IBM Cloud Code Engine: クラウドをもう一度ご活用ください” もご参照ください。” IBM Cloud Code Engineの紹介“もお役立ていただけますと幸いです。

この機会にぜひ、 IBM Code Engineでコンテナ・イメージを作成してみてはいかがでしょうか。