• アフターレポート
  • コンテナ
  • DX
  • 仮想化基盤

実案件から見たリアル!
プロジェクト経験者が語る「Kubernetesの壁」とセキュリティ対策


                                                                        kubernetes_seminar2_article.jpg

レッドハット社の国内最大級イベント「Red Hat Summit:Connect|Japan 2022」が2022年10月27日(木)に3年ぶりに対面で開催されました。さまざまな最新情報やトピックに関心が集まるなか、SCSKは「Red Hat OpenShift(以下、OpenShift)」やコンテナなどの領域に、果たしてベストプラクティスはあるのか!?という視点で、「プロジェクト経験者が語る『Kubernetesの壁』とセキュリティ対策」と題した特別対談を行いました。

なぜ日本ヒューレット・パッカード社(以下、HPE社)は、OpenShiftと、そのモニタリング/セキュリティ確保のためのツールとして、「Sysdig」を提案したのか? Sysdigの導入を支援したSCSKが、そのプロジェクトと実体験の真相から、コンテナに最適なミドルウェアの選択にまで切り込みました。これからコンテナ基盤の運用を引き受けられる方、また既に運用にお悩みの方、必見です。

司会
◆SCSK株式会社 奥 浩史
Red Hat製品主管部署のマネージャとして、2008年のJBoss取り扱い立ち上げ当初から10年以上、Javaを中心としたミドルウェア製品のセールスに従事。ここ数年はOpenShift及びSysdigを中心に、コンテナ関連ビジネスに深く関与。

経験豊富なパネリストたち
◆日本ヒューレット・パッカード合同会社 平山 宗一郎
エンタープライズ向けのインターネット系システムのセキュリティ対策に従事し、J-SOX対応やPCI DSS対応案件も実施。合併と分社化により転職せずとも3社の経験をもつラーメン大好きのシニアコンサルタント。
◆日本ヒューレット・パッカード合同会社 平山 宗一郎 氏
◆SCSK株式会社 石川 愛彦 氏
Sysdig製品の技術担当。OpenShiftをはじめ様々なコンテナプラットフォームに携わるクラウドエンジニア。特にコンテナモニタリング、セキュリティが主戦場。
◆SCSK株式会社 石川 愛彦 氏
◆レッドハット株式会社 土田 隆文
インフラSIサービスに長きに渡り従事。現在はOpenShiftやミドルウェアをエンタープライズ企業向けに提案するセールスマネージャ。
◆レッドハット株式会社 土田 隆文

コロナ禍開けの対面イベントだからこそ知りたかった「経験者が語ったリアル」

奥:まず初めに、今回のイベントでどのようなテーマが良いかと考えた時に、やはりOpenShiftやコンテナの領域にはベストプラクティスがなかなか無くて、みなさんきっと本当のところはどうなのかを知りたいんじゃないかと思ったんです。その中で、セキュリティは特に考えていく必要がある領域だと思いました。そこで、まずはSysdigという製品を顧客に提案し、実際のプロジェクトを進めてられていた平山さんにお話しを伺っていきたいと思います。

エンタープライズ企業が、「OpenShift」である理由

平山氏:はい。私が携わったプロジェクトはオンプレミス上にKubernetesのインフラを作るというものでした。エンタープライズのお客様なのでRed Hat OpenShift Container Platform(以下OCP)一択で決まっていました。それと要件としてはPCI DSS(Payment Card Industry Data Security Standard)準拠がマストでした。ウイルス対策や改ざん検知、脆弱性チェックといった対応が必要ですし、Kubernetesということでオブザーバビリティ、つまり運用モニタリングもやっていかないといけない。そこでSysdigを導入したという案件です。

奥:なるほど、ありがとうございます。エンタープライズ企業向けだったのでOpenShiftというお話でしたが、さまざまな選択肢がある中で、なぜOpenShiftだったのでしょう。この辺を土田さんはどう思われますか?

土田氏:そうですね。OpenShiftがエンタープライズグレードというキーワードで選択いただくケースはすごく増えてきているのですが、理由としてひとつ挙げるとすれば、運用部分の違いだと思っています。こういったコンテナアプリケーションをKubernetesでホストしていくのは運用が本当に大変ですし、運用全体がややこしくなってしまいます。得たかったメリットが結局得られないという話も聞きます。OpenShiftは、コンテナアプリケーションをホストするための基盤コンポーネントに必要となる運用、これを限りなくOpenShiftにオフロードすることができます。最近は実際にそういう理由で選択していただいているケースもあるので、そこがエンタープライズグレードと言われる部分のひとつだと思っています。

奥:ありがとうございます。レッドハットさんがOpenShiftを語ると、どうしてもCMっぽくなってしまいますね(笑)、平山さんは実際どうだったのですか?

平山氏:まさに土田さんにおっしゃっていただいた通りで、違和感なくという感じです。

コンテナ運用におけるデファクトスタンダード

奥:今回のプロジェクトではセキュリティ要件を満たすためにSysdigを採用されていますが、 レッドハットさんにはRed Hat Advanced Cluster Security for Kubernetes (以下、ACS)というOpenShiftのなかでコンテナ向けセキュリティ製品もお持ちかと思います…土田さんその辺はどうでしょうか?

土田氏:はい。おっしゃるとおり実は、OpenShiftはセキュリティコンポーネントを持っています。もちろんセキュリティに限らず、CI/CDも含めて必要なコンポーネントを揃えていますし、それをそのままOpenShift上で活用いただくメリットは確実にあると考えています。しかし、どの基盤コンポーネントを選ぶ必要があるかは、実際の運用耐性や、どのようなワークロードをホストしていくかなどによって変わってきます。なので、OpenShiftが提供してるコンポーネントだけが最適解とは正直考えておりません。ベストオブリードと言いましょうか、OpenShiftはサードパーティ製品も含めてきちんとホストできますし、このプロジェクトにおいてSysdigはセキュリティコンポーネントとしてベストチョイスだったと思っています。

図1 スライド「案件概要」

図1 スライド「案件概要」

奥:なるほど。そういえば、そもそもSysdigをご存じない方もいらっしゃると思います。石川さん、簡単にご紹介いただけますか?

石川:はい、そうですね。SysdigはLinuxホストのシステムコールを収集して、その情報をもとにモニタリングセキュリティ機能を提供している製品です。今や必須とも言えるコンテナの脆弱性スキャニングができます。その他にもSysdigならではの機能としては、コンテナの中で動いているパッケージや、使われているパッケージを特定することができます。これは何が嬉しいかというと、たくさんある脆弱性を優先順位付けすることで、いち早く必要な対応ができます。また、OpenShift環境であれば、デーモンセットでデプロイすることによって、コンテナとセキュリティ機能の両方を使うことができるので、運用にも非常に優しい機能です。ちょっと宣伝みたいになってしまいました。

奥:(笑) それほどお伝えしたい機能が揃っているということですね。平山さん、でも実際、このプロジェクトでのチョイスという意味で、決め手は何かあったのでしょうか?

数百個のコンテナをどうやって可視化する!?

平山氏:決め手は二つありました。
そもそも最初は、エンタープライズ企業向けのプロジェクトでよく見られる、エージェントを導入して、マネージャで管理するといったアーキテクチャを使ったシステムを考えていました。しかし、OCP上でそのアプローチをとることができなかったのです。エージェントが軒並みコアOSに対応していないとかコンテナ対応していないとか…。それでOCPや Kubernetesに対応している製品を探し始めて、Sysdigにたどり着いたというのが一つ。二つめは、私は今回初めてOCPを経験しましたが、普通に動かすだけでコンテナが数百個ですよ。それをSysdigのようなツールを使わないで、どうやって把握する?どうやって可視化するんだという事でした。やはりこの手のツールはKubernetes環境で必須だなと思います。

「新規コンテナが起動できなくなりました」という問い合わせ…

奥:ありがとうございます。ではこういった背景がある中で、今日のテーマ「壁」なのですが、色々ぶつかるよねという共通の悩みの中で、実際に苦労されたことをお聞かせください。平山さんどうでしょうか?

平山氏:はい。あるとき、アプリケーションチームがテストをやっていました。そして二~三週間ほど経った頃に、コンテナが起動しなくなったと言われたのです。幸いHPEでは別プロジェクトでも似たような事象に遭遇したことがあり、原因を究明するノウハウが蓄積されていたので色々と分析をしました。すると、どうもコントロールプレーンとCRI-O(クライオ)の不整合が発生しているようだということがログから分かりました。プロジェクト環境以外でもこの問題を再現でき、再現性のある汎用的な問題であることが確認できたことから、チケットをオープンしてもらい、Red Hat Bugzilla(※)に掲載されました。
さらに色々調査していると、過去にもグローバルで同様の事象が報告されていて、CRI-Oに修正版が入っている最新版のOCPで試しほしいとの依頼を受け対応しました。一見それで解決したように見えたのですが、長時間の連続試験の結果また再発したのです。レッドハット社による解析の結果、CRI-OとSysdigの双方が「.lock」ファイルをロックしているのが原因という事が判明しました。

※Red Hat Bugzilla・・・

Bugzillaはオープンソースのバグ管理サービスのことで、Red Hat Bugzillaはレッドハット社の製品で利用されるBugzillaのこと

奥:なるほど。原因の判明までさらっとお話いただきましたが、ここにたどり着くまでに、すごく苦労があったのではないかなと思います。石川さん、CRI-Oというキーワードがでてきましたが?

真相(深層)解明までの苦労

図2 スライド「OpenShift Atchtecture概要」

図2 スライド「OpenShift Atchtecture概要」

石川:そうですね。図1は今回の事象が発生した際に平山さんたちから伺った内容を整理したものです。下から二つ目の層、コンテナが動く下のコンテナランタイムとしてOpenShiftからCRI-Oが提供されています。根本的にはこのCRI-Oが関係しているわけですが、どうやらSysdigの何かが影響してるようだと。でもこれ結構深い層なので、どうしてもコンテナを意識してしまいがちです。その下で動いている層というのは各ホストになってしまうので、なかなか目にしないし、その動きについても余り意識しないので、これは只事ではないと感じました。

奥:CRI-Oを使っているのはOpenShift側の要件ですよね。

石川:はい。まずわれわれは本当にSysdigが関係してるのかを確認しなければいけませんでした。原因究明を行い、関係していなければ無実を証明する必要があります。関係しているのであればテクニカルサポートに依頼して、さらなる原因の特定、場合によっては改修してもらう必要がありました。ただ、CRI-Oの問題も1つではなかったので、並行していろいろ調査して行く中で、いくつかの問題が見つかっていってという状況ではありました。

平山氏:先ほどお話ししたように、この問題はかなり深い層に起因しており、アプリケーションを利用するユーザや、アプリケーションチームからすると、ただ新規コンテナが起動しないとしか認識できません。ですが、本当の問題はまずCRI-Oにあって、それを解決すると今度は.lockファイルをロックしているという問題もあるというように、原因が多層になっているという複雑な状況でした。

Red Hat Bugzillaを起点としたONEチームでの問題解決法

奥:なるほど。今回Red Hat Bugzillaを使ってONEチームで問題解決に取り組んだと聞いていますが、具体的にどんなことをされたのでしょうか?

図3 スライド「苦労からの学び」

図3 スライド「苦労からの学び」

平山氏:ONEチームについて図3で表現しています。太い矢印がコミュニケーションパスを表していて、中央にRed Hat Bugzillaのウェブ画面があります。われわれが相対していたのはレッドハットさんでしたが、プロジェクトに関係していたSysdigさんやSCSKさん含めこの画面を全員で共有できていたので、メールで伝言ゲームのようになったり、タイムラグが発生したりすることもなく、迅速に共有することができました。特に、共有と同時に解析することができたことがスピード感を持って正確に対応できた要因だと考えています。

奥:レッドハットさんはコンサルティングとして支援も入られていたようですが、サポートにあたってはどのような支援を受けていたのでしょうか?コンサルの方でどんどん進めてくれたのかなどのお話あれば聞かせてください。

平山氏:はい、そこはむしろSCSKのTAM(テクニカル・アカウント・マネジメント)の方に積極的に対応いただきました。

石川:そうですね。われわれは直接この件には関わってはいなかったのですが、SCSKとはOpenShiftにおけるTAMの契約を締結いただいていて、定例会の中で共有を受け、実際に担当されている方とコミュニケーションをとって状況を掴むことができました。TAMとしての知見をもとにSysdig観点での調査を進めることができたと思います。Sysdig社とレッドハット社、お互いがそれぞれに調査して両社の直接的な連携は多くない状況でしたが、今回のケースではRed Hat Bugzillaを中心としたこのコミュニケーションパスがうまく機能したと思います。

奥:そうなのですね。TAMとしてお客様のプロジェクトの状況や、プロジェクトの周辺情報、また今回はSysdig社の動きも含め、すべてをRed Hat Bugzillaで介してしっかりと把握してコミュニケーションしたのが功を奏したのですね。

土田氏:その通りです。レッドハットではサブスクリプションを提供していますが、今お話にあった事象が起こったり、レイヤーが多層化していたり、登場人物が多いケースにおいて、TAMの提供と技術支援としてのプロフェッショナルサービスだけで解決する事は難しく、やはりプロジェクトの一部として、HPEさん、SCSKさんに非常にうまく我々のサービス使っていただいて、コミュニケーションパスと、オープンな場で詰めていく。そこがうまくワークしたし、潤滑に早い解決に至ってよかったなというふうに思っています。

石川:もう少しだけ話をさせてもらうと、今回CRI-Oが使うロックファイルが競合していましたが、Sysdigが特有の悪さをしていたということではないんです。CRI-Oを使う環境において動くサードパーティ製品すべてが関係してくるので、ご注意いただいた方がいいと思います。幸いSysdigは解決することができました。

― ありがとうございます。こういった状況の中で、とても苦労して解決したという事が伝わったのではないかと思います。

パネリスト達からの本音メッセージ

土田氏:みなさん、さまざまな課題にあたることがあると思いますが、今回のケースのようにHPEさん、SCSKさんが切り開いてくれてた道のようなものもありますし、Tipsやノウハウのような技術的な情報は限りなくオープンになっているので、まさに行けば分るさ的な感じがあると、私は思っています。既に切り開かれている道を是非一緒に、またこれがもっと広がっていったら良いなと思ってます。

石川:今回のテーマがKubernetesの壁ということで、私はこの分野に携わってまだ4年目ぐらいなので日々トラブルシューティングをしていますが、正直壁しかない気がしています。でも不思議なものでこれを続けていくと、だんだん壁が壁ではなくなってくるんです。まるで禅みたいなんですが、そこまで行くとコンテナってすごく便利で、さらにそれをオーケストレーションしてくれるOpenShiftもこの上なく便利なのです。今はもうコンテナが無い時代には戻れないとさえ思えるほどの便利さがあると思っています。Sysdigを使っていただくと、より便利に使っていただくことができるので、ぜひOpenShiftもSysdigも併せて一緒に使っていただけたらと思います。

平山氏:エンタープライズ企業のシステムは、一般的に5年や7年での原価償却を想定して使い続けると思いますが、Kubernetesの世界では、例えて言うならば6か月ぐらいが賞味期限なのです。なので、定常的にバージョンアップしながら使い続けていく必要があるのです。我々も考え方を変えていく必要があるとつくづく感じています。また石川さんから壁という話がありましたが、壁も一様ではなくて、高い所、低い所があります。実はKubernetesは古くから存在しているUNIXの技術がベースになっています。今までやってきたトラブルシューティングのノウハウはKubernetesに必ず使えます。今回やってみて本当に思いました。ですからそこは臆さずに、今後もみなさんと一緒に取り組んでいければ嬉しいです。

最新情報などをメールでお届けします。
メールマガジン登録

×