第20回『デジタルサービス・プラットフォーム（DSP）におけるDevSecOpsの価値』

記事をシェアする:

こんにちは。日本IBMでアプリケーション・アーキテクトをしている土井です。
今回は、OpenShiftを使ってアプリケーションのためのプラットフォームを作るとはどういうことか？とOpenShiftプラットフォーム機能の一つとして整備されるCI/CDを利用してDevSecOpsを実現することの価値についてお話ししたいと思います。

OpenShiftは単なる基盤製品ではない

Kubernetesはよく「プラットフォームを作るためのプラットフォーム」、と表現されることがあるのをご存知でしょうか？昨今Kubernetesは非常に人気のプロダクトとして各企業で導入が進められている状況ではありますが、単に導入しただけで効果を発揮するわけではありません。Kubernetesを使って何を成すか？ということをその上で動作するアプリケーションにフォーカスして検討する必要があるのです。

アプリとインフラがあればプロダクション運用できるわけではない

一般的に、アプリケーションを開発してこれを公開するとなった時、アプリケーションを実行する基盤を用意してその上でアプリケーションを動作させることを計画することが多いでしょう。Kubernetesを利用した場合もこれは同様になります。インフラチームがKubernetesをサーバーにインストールし（最近ではManagedサービスを使うことが多いのでそれも不要な場合があります）、アプリチームにどうぞご自由に使ってください、と言うわけです。アプリチームはアプリケーションを作り、インフラチームはそのインフラを作るという従来の役割分担からすれば当然の成り行きでしょう。しかしながら、Kubernetesをそのまま渡されたアプリチームが単独でプロダクション運用を可能とするまでにこれを使いこなせることは非常に稀です。また、Kubernetesはその基盤上で複数の異なる組織のアプリケーションを動作させることが可能であるため、これを志向する企業も多いですが、各組織で好き勝手に使って効果を出すことも当然ながら至難の技です。

生産性と管理・統制を両立させる仕組み・プロセスが必要

以下の図を見てください。アプリチームとインフラチームの間にプロダクション運用のために考えなければならない複数のタスクを一例としてあげています。これらのタスクは皆さんの現場ではアプリ、インフラどちらが担っているでしょうか？

実際問題としてはこれらのタスク毎に、それを出来る能力のあるメンバーがいるチームがそれぞれをなんとなく担当する、といった場当たり的な対応をすることが多いのではないかと思います。しかしながら、一つのシステム・サービスであればそれでも成り立つかもしれませんが、複数の組織が複数のアプリケーションを開発、運用していくことを考えるとこれは非効率と言わざるを得ません。理想的には、これらのタスクが整理されて標準化された状態でアプリケーション開発を行うべきで、これによって生産性と管理・統制を両立させることが可能になるのではないでしょうか。このような複数の利用者（この場合、Kubernetesクラスタを利用してアプリケーションを開発、運用するチームを指します）に対して生産性と管理・統制を両立させる仕組みやプロセスが整備されたクラスタをここではアプリケーション・プラットフォームと呼称します。

アプリケーション・プラットフォームのイメージ図は以下の通りです。

イメージ図が示すように、アプリケーションが直接自由にKubernetesのようなコンテナ・オーケストレーション層を使うのではなく、プラットフォームとして整備された標準と機能を活用することで複数のアプリケーションを迅速に展開できるようになります。

IBM デジタルサービス・プラットフォーム

Kubernetesの企業での導入においてアプリケーションプラットフォーム整備の重要性をお話ししてきましたが、これはKubernetesに限らず、それをベースとして作られているRed Hat OpenShiftの導入においても同様です。IBMではこれらアプリケーションプラットフォームを提供するサービスとして「デジタルサービス・プラットフォーム」（https://www.ibm.com/resources/consulting/jp-ja/digital-service-platform/）というサービスを展開しています。これはOpenShiftをベースとして、迅速にセキュアなOpenShiftクラスタの自動構築や、DevSecOpsを推進するツールや活用ガイドの提供、AIを活用したIT運用サービスによる運用自動化の実現といった前述のアプリケーション・プラットフォームの実現に必要なベース機能をご提供するサービスです。

今回は、このデジタルサービス・プラットフォームでご提供するいくつかの機能の中でDevSecOpsを掘り下げてご説明します。

デジタルサービス・プラットフォームが提供するDevSecOps

デジタルサービス・プラットフォームの一部であるDevSecOps機能（以降Pipeline Builderと呼称します）は特定クラウド環境に依存しないセキュアなCI/CD環境を提供するサービスです。DevSecOpsは厳密にはDevOpsにセキュリティ要素を加えた造語となっており、CI/CDだけの話ではないのですがDevSecOpsのツール面、テクノロジー面を支えるサービスとしての位置付けとなっています（DevOpsの詳細説明はここでは割愛します）。具体的には、OpenShift Pipelines（Tekton）やJenkinsを活用して簡単にCI/CDパイプライン構築し、セキュアなアプリケーションを迅速に配備することが可能です。ここでは実際にどんな手順でCI/CDパイプラインの構築が可能なのか見てみましょう。

CI/CDパイプライン全体像

Pipeline Builderは以下のようなCI/CDパイプラインの標準パターンを提供しています。CI/CDパイプラインは構築したいけど始めはどう設計すれば良いかわからない、といったお客様向けの「テンプレート」の位置付けです。ある程度この「テンプレート」から始め、慣れてきたら自身のアプリケーションごとにカスタマイズしていく、という活用の仕方を想定しています。

OpenShift管理コンソールとの統合

上記標準パターンのCI/CDパイプラインの構築は非常に簡単です。OpenShift管理コンソールに統合されており、GUIベースでgitリポジトリのURLと、アプリケーションランタイム（JavaであればJBossやWebSphere Liberty等）を指定するだけで完成します。

具体的に見ていきましょう。パイプライン構築の基本は以下の３ステップで完結します。

1. デプロイするアプリケーションのコードが格納されたgitリポジトリのパスを入力する
   CI/CDパイプラインを使ってアプリケーションをデプロイするには当然アプリケーションコードがなければなりません。ですので、以下のようにアプリケーションコードの格納されたgitリポジトリを管理コンソールで指定します。
   
   なお、gitリポジトリで認証が必要な場合も認証情報をここで渡すことができます。
2. アプリケーションランタイムを選択する
   前項でアプリケーションコードを指定したので、この指定したアプリケーションコードをビルドして最終的にどのアプリケーションランタイムで稼働させるかを指定します。
   
   利用可能なアプリケーションランタイムの一覧が表示されるので自身のアプリケーションに適切なランタイムを選択します。ここではWebSphere Libertyを選択します。
3. 構築するパイプラインを選択する
   前項で選択したアプリケーションランタイム毎にそれに紐づいたパイプラインが登録されています。今回はアプリケーションランタイムとしてWebSphere Libertyを選択しましたのでそれに紐づいたパイプラインが表示されました。
   
   なお、一つのアプリケーションランタイムに複数のパイプラインを紐づけて、CI/CDのユースケースによってここで選択をしてパイプラインを作り分けるといったことも可能です。

以上1〜3のステップでOpenShift管理コンソールを使って必要情報を入力し、作成ボタンを押すことで、自動的にCI/CDパイプラインを構築、実行、デプロイを実施します。結果としては以下のような形で自身の領域にパイプラインとそれを使ってビルドされたアプリケーションがデプロイされます。

• 作成、実行されたパイプライン
  
• デプロイされたアプリケーション
  

アプリケーションコードの変更が入った場合、この出来上がったパイプラインを実行するだけで変更後のコードが取り込まれたアプリケーションが数分で再度デプロイされることになり、アプリケーションを繰り返し、迅速に公開することができるようになります。
KubernetesでTekton等のCI/CDツールを使い、出来上がったアプリケーションをデプロイした経験のある方はお分かりかと思いますが、これを行うためには非常に沢山のyaml設定を書く必要があり、手間で時間のかかる作業と感じることが多かったのではないでしょうか。そしてこの手間のかかる作業は学習コストが高く、CI/CDの構築、ひいてはDevSecOpsを推進していきたい組織にとって障壁となっていたことでしょう。しかしながら、これらのご紹介した仕組みを使うことで学習コストを下げて利用できるようにすることでCI/CDに対する最初のハードルを下げ、導入しやすくすることができるわけです。

アプリケーションセキュリティ担保の仕組み

DevOpsではなくDev「Sec」Ops機能とわざわざご紹介しているのは当然ながら理由があります。DevSecOps Pipeline Builderにはそれぞれ以下のアプリケーションセキュリティチェックのための仕組みがパイプライン標準として整備されています。

1. 静的コードスキャン
   SonarQubeを活用してコード品質を担保しつつコード脆弱性を検知します。パイプライン上でアプリケーションコードビルドの際にこれらは実行され、一定以上のコード品質を担保しないと以降のパイプラインをブロックする、といったことも可能です。（Pipeline Builderデフォルトではチェックのみ行い、ブロックは実行しません）
2. Webアプリ脆弱性診断
   上記静的コードスキャンは、ソースコードレベルでの静的スキャンであるため、実際のアプリケーション実行時のセキュリティ担保まで行うことができません。このため、アプリケーション実行時の脆弱性診断の仕組みとしてOWASP ZAPを使用したWebアプリケーション脆弱性診断をパイプライン上で実行します。
3. コンテナ脆弱性診断
   アプリケーションの脆弱性診断に加えて、そのランタイムが含まれるコンテナの脆弱性診断も非常に重要です。各ベンダーの提供するコンテナイメージであればその安全性がある程度保証されますが、例えばDocker Hub等で一般公開されているコンテナイメージは全てが安全であるとは限りではありません。また自身で作成したコンテナイメージについても脆弱性を含んだモジュールを利用している可能性もあります。このため、パイプライン上で作成したコンテナはコンテナ脆弱性診断を行うようになっています。

このように、各企業でDevSecOpsを実現するためにはまずはその導入障壁を下げてなるべく簡単にできるように、かつセキュリティもしっかりと担保していくことが重要です。勿論、DevSecOpsはツールやテクノロジーだけで達成できるものではありませんが、まずは導入して何ができるのかを知り、そこから各企業のDevSecOpsを模索していくのも有効な一手なのではないかと私は考えています。

最後に

Kubernetes隆盛の昨今、各企業はこぞって導入を進めていますが、単に導入しただけで何かが良くなるわけではありません。これまでお話させていただいたように、それを使って何を成すか？を整理した上で、アプリケーションの生産性と管理・統制を両立できるように整備していくことが非常に重要となってきています。IBMでは、これをデジタルサービス・プラットフォームとしてツールだけではなく仕組みや知見もまとめて提供できるように整備しており、これは今現在でも継続的に進化を続けています。今回はその中心となるアプリケーション・プラットフォームとしての重要性とその中の一部、DevSecOpsを推進するサービスを説明させていただきました。
単純にKubernetes/OpenShiftを導入してそこでアプリケーションを稼働させるのではなく、アプリケーションによりフォーカスして整備することで迅速に市場の求めるサービスを送り出していける、そんなアプリケーション・プラットフォームの構築を考えてみてはいかがでしょうか？

【参考資料】

• IBMデジタルサービス・プラットフォーム
• SonarQube
• OWASAP ZAP: