2.8. ビルドプロセスのセキュリティー保護

OpenShift Container Platform をコンテナービルドの標準プラットフォームとして使用することで、ビルド環境のセキュリティーを確保できます。「1 回のビルドでどこにでもデプロイが可能」という理念を背景に、ビルドプロセスの製品がそのままの状態で実稼働にデプロイされるようにすることができます。

コンテナーのイミュータブルな状態を維持することも重要です。実行中のコンテナーにパッチを当てることはできません。その代わりに再ビルドおよび再デプロイを実行します。

ソフトウェアがビルド、テスト、および実稼働環境の複数ステージを通過する際に、ソフトウェアのサプライチェーンを設定するツールが信頼できるかどうかは重要です。以下の図は、コンテナー化されたソフトウェアの信頼できるソフトウェアサプライチェーンに組み込むことができるプロセスおよびツールを示しています。

OpenShift Container Platform は、セキュアなコードを作成し、管理できるように、信頼できるコードリポジトリー (GitHub など) および開発プラットフォーム (Che など) と統合できます。単体テストは、Cucumber および JUnit に依存する必要がある場合があります。

Red Hat Advanced Cluster Security for Kubernetes でビルド、デプロイ、または実行時にコンテナーの脆弱性および設定の問題を確認できます。Quay に保存されているイメージについては、Clair スキャナー を使用して保存中にイメージを検査できます。さらに、Red Hat エコシステムカタログでは、認定された脆弱性スキャナー を利用できます。

Sysdig などのツールは、コンテナー化されたアプリケーションの継続的なモニタリングを提供できます。

Source-to-Image (S2I) を使用して、ソースコードとベースイメージを組み合わせることができます。ビルダーイメージ は S2I を利用し、開発および運用チームの再現可能なビルド環境での協業を可能にします。Red Hat S2I イメージが Universal Base Image (UBI) イメージとして利用可能な場合、実際の RHEL RPM パッケージからビルドされたベースイメージでソフトウェアを自由に再配布できます。Red Hat は、これを可能にするためにサブスクリプションの制限を削除しました。

開発者がビルドイメージを使用して、アプリケーション用に Git でコードをコミットする場合、OpenShift Container Platform は以下の機能を実行できます。

統合された OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。

CI の組み込まれた Jenkins のほかに、独自のビルドおよび CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。

シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。

たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc ファイルを指定する必要があります。セキュリティー上の理由により、認証情報はアプリケーションイメージで公開しないでください。

この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig オブジェクトに追加できます。

コンテナーの層を使用できるようにコンテナーイメージ管理およびビルドプロセスを設計して、制御を分離可能にすることができます。

たとえば、運用チームはベースイメージを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。これにより、開発者はアプリケーション層のみを使用し、コードの作成に集中することができます。

新しい脆弱性情報は常に更新されるので、コンテナーのコンテンツを継続的かつプロアクティブに確認する必要があります。これを実行するには、自動化されたセキュリティーテストをビルドまたは CI プロセスに統合する必要があります。以下に例を示します。

CI プロセスには、セキュリティースキャンで発見される問題を担当チームが適切に対処できるように、これらの問題のフラグをビルドに付けるポリシーを含める必要があります。カスタマイズしたコンテナーに署名することで、ビルドとデプロイメント間に改ざんが発生しないようにします。

GitOps の方法を使用すると、同じ CI/CD メカニズムを使用してアプリケーションの設定だけでなく、OpenShift Container Platform インフラストラクチャーも管理できます。

Kubernetes と Kourier を利用すると、OpenShift Container Platform で OpenShift Serverless を使用して、サーバーレスアプリケーションを構築、デプロイ、管理できます。

他のビルドと同様に、S2I イメージを使用してコンテナーをビルドしてから、Knative サービスを使用してそれらを提供できます。OpenShift Container Platform Web コンソールの Topology ビューを使用して Knative アプリケーションのビルドを表示します。