2.8. ビルドプロセスのセキュリティー保護
コンテナー環境では、ソフトウェアのビルドプロセスはライフサイクルのステージであり、ここでは、アプリケーションコードが必要なランタイムライブラリーと統合されます。このビルドプロセスの管理は、ソフトウェアのスタックのセキュリティーを保護する上で鍵となります。
2.8.1. 1 回のビルドでどこにでもデプロイが可能
OpenShift Container Platform をコンテナービルドの標準プラットフォームとして使用することで、ビルド環境のセキュリティーを確保できます。「1 回のビルドでどこにでもデプロイが可能」という理念を背景に、ビルドプロセスの製品がそのままの状態で実稼働にデプロイされるようにすることができます。
コンテナーのイミュータブルな状態を維持することも重要です。実行中のコンテナーにパッチを当てることはできません。 その代わりに再ビルドおよび再デプロイを実行します。
ソフトウェアがビルド、テスト、および実稼働環境の複数ステージを通過する際に、ソフトウェアのサプライチェーンを設定するツールが信頼できるかどうかは重要です。以下の図は、コンテナー化されたソフトウェアの信頼できるソフトウェアサプライチェーンに組み込むことができるプロセスおよびツールを示しています。
OpenShift Container Platform は、セキュアなコードを作成し、管理できるように、信頼できるコードリポジトリー (GitHub など) および開発プラットフォーム (Che など) と統合できます。単体テストは、Cucumber および JUnit に依存する必要がある場合があります。コンテナーの脆弱性の有無や、Anchore または Twistlock などのコンプライアンス関連の問題の有無を検査し、AtomicScan または Clair などのイメージスキャンツールを使用できます。Sysdig などのツールは、コンテナー化されたアプリケーションの継続的なモニタリングを提供できます。
2.8.2. ビルドの管理
Source-to-Image (S2I) を使用して、ソースコードとベースイメージを組み合わせることができます。ビルダーイメージ は S2I を利用し、開発および運用チームの再現可能なビルド環境での協業を可能にします。Red Hat S2I イメージが Universal Base Image (UBI) イメージとして利用可能な場合、実際の RHEL RPM パッケージからビルドされたベースイメージでソフトウェアを自由に再配布できます。Red Hat は、これを可能にするためにサブスクリプションの制限を削除しました。
開発者がビルドイメージを使用して、アプリケーション用に Git でコードをコミットする場合、OpenShift Container Platform は以下の機能を実行できます。
- コードリポジトリーの Webhook または他の自動化された継続的インテグレーション (CI) プロセスのいずれかで、利用可能なアーティファクト、S2I ビルダーイメージ、および新たにコミットされたコードを使用して新規イメージの自動アセンブルをトリガーします。
- 新規にビルドしたイメージを自動的にデプロイし、テストします。
- テスト済みのイメージを実稼働にプロモートします。 ここでは CI プロセスを使用して自動的にデプロイされます。
統合された OpenShift Container レジストリーを使用して、最終イメージへのアクセスを管理できます。S2I イメージおよびネイティブビルドイメージの両方は OpenShift Container レジストリーに自動的にプッシュされます。
CI の組み込まれた Jenkins のほかに、独自のビルドおよび CI 環境を RESTful API および API 準拠のイメージレジストリーを使用して OpenShift Container Platform に統合することもできます。
2.8.3. ビルド時の入力のセキュリティー保護
シナリオによっては、ビルド操作において、依存するリソースにアクセスするために認証情報が必要になる場合がありますが、この認証情報をビルドで生成される最終的なアプリケーションイメージで利用可能にすることは適切ではありません。このため、入力シークレットを定義することができます。
たとえば、Node.js アプリケーションのビルド時に、Node.js モジュールのプライベートミラーを設定できます。プライベートミラーからモジュールをダウンロードするには、URL、ユーザー名、パスワードを含む、ビルド用のカスタム .npmrc ファイルを指定する必要があります。セキュリティー上の理由により、認証情報はアプリケーションイメージで公開しないでください。
この例で示したシナリオを使用して、入力シークレットを新規の BuildConfig オブジェクトに追加できます。
シークレットがない場合は作成します。
$ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc
これにより、
secret-npmrcという名前の新規シークレットが作成されます。 これには、~/.npmrcファイルの base64 でエンコードされたコンテンツが含まれます。シークレットを既存の
BuildConfigオブジェクトのsourceセクションに追加します。source: git: uri: https://github.com/sclorg/nodejs-ex.git secrets: - destinationDir: . secret: name: secret-npmrcシークレットを新規の
BuildConfigオブジェクトに追加するには、以下のコマンドを実行します。$ oc new-build \ openshift/nodejs-010-centos7~https://github.com/sclorg/nodejs-ex.git \ --build-secret secret-npmrc
2.8.4. ビルドプロセスの設計
コンテナーの層を使用できるようにコンテナーイメージ管理およびビルドプロセスを設計して、制御を分離可能にすることができます。
たとえば、運用チームはベースイメージを管理します。一方で、アーキテクトはミドルウェア、ランタイム、データベース、その他のソリューションを管理します。これにより、開発者はアプリケーション層のみを使用し、コードの作成に集中することができます。
新しい脆弱性情報は常に更新されるので、コンテナーのコンテンツを継続的かつプロアクティブに確認する必要があります。これを実行するには、自動化されたセキュリティーテストをビルドまたは CI プロセスに統合する必要があります。以下に例を示します。
- SAST / DAST – 静的および動的なセキュリティーテストツール
- 既知の脆弱性をリアルタイムにチェックするためのスキャナー。このようなツールは、コンテナー内のオープンソースパッケージをカタログ化し、既知の脆弱性を通知し、スキャン済みのパッケージに新たな脆弱性が検出されるとその更新情報を送信します。
CI プロセスには、セキュリティースキャンで発見される問題を担当チームが適切に対処できるように、これらの問題のフラグをビルドに付けるポリシーを含める必要があります。カスタマイズしたコンテナーに署名することで、ビルドとデプロイメント間に改ざんが発生しないようにします。
GitOps の方法を使用すると、同じ CI/CD メカニズムを使用してアプリケーションの設定だけでなく、OpenShift Container Platform インフラストラクチャーも管理できます。
2.8.5. Knative サーバーレスアプリケーションのビルド
Kubernetes と Kourier を利用すると、OpenShift Container Platform で OpenShift Serverless を使用して、サーバーレスアプリケーションを構築、デプロイ、管理できます。
他のビルドと同様に、S2I イメージを使用してコンテナーをビルドしてから、Knative サービスを使用してそれらを提供できます。OpenShift Container Platform Web コンソールの Topology ビューを使用して Knative アプリケーションのビルドを表示します。
