2024.12.03
セキュリティ製品を入れても検出されず…被害事例から見る最新の攻撃トレンド 不正侵入・悪用を回避するポイント
リンクをコピー
記事をブックマーク
星野真知氏:(スライドを示して)さて、これを紹介するまでが私のセッションですが、とはいえちょっとはテクニカルなことを話したほうがいいと思うので、この中でビルドクラスタを紹介したいと思います。
これは何かというと、InnerLoopとOuterLoopをつなぐ、ある意味門番の役割をするものだと思っています。このビルドの考えかたを持っている方は、けっこう少ないと思っています。何が特に特徴かというと、まず所有者が基本的にインフラ部隊ということです。
目的は何かというと、最終的にOuterLoopにやってくる開発物の品質を均一化することです。パッチなどの問題があった時も、開発の方々を巻き込むことなく、この世界で完結してパッチの適用などができます。こういうものを作ろうというのが、ビルドクラスタの目的です。
このビルドクラスタの中にも、いろいろな技術要素は説明できると思いますが、今日はその中でも1個だけ、コンテナを作るところに着目をして話を取り上げたいと思います。
(スライドを示して)これは、弊社の人間が「Javaでコンテナを作る時にどうしているか?」をアンケートしたものです。その他を抜いた数字が右にありますが、ソースコードからコンテナを作る時に、Dockerfileを使っている方が大多数と思っています。
ところが、先ほどのInnerLoop、OuterLoopの考えかたを適用する最初のステップとして、我々VMwareは、マストとは言いませんが、Dockerfileはなるべくやめるべきだと思っています。
なぜか。まずDockerfileがどういうものなのかを左に例を書いていますが、まず、いくらでもエンジニアたちが好きなことを書けてしまうので、属人化します。(スライドを示して)特徴的なのが、この例の「ENTRYPOINT」の2個目の「Xmx」です。Javaの開発を見たことがある方はみんな知っているヒープサイズを2GBと入れていますが、これを何と入れるかは、開発者によってぜんぜん違うと思っています。
それ以外にもいろいろなオプションがあるので、これがどのように入っているかは、完全に開発者依存になってしまうというところです。
もう1個の問題は、ブラックボックスになってしまうところです。でき上がったイメージがどういうDockerfileで作られたかは、DockerfileをGitHubに置いている方はいいのかもしれませんが、普通その手段はなくなってきています。
もう1個の問題です。「FROM」のところにopenjdk:17-jdk-alpineと書いてあって、Javaの17が使われているのがわかりますが、いつのJavaの17なのかがわからないというところです。
コンテナのFROMのところは、基本的にミュータブル、変更可能であるのが問題になってきて、Java17は非常に長いライフサイクルを持っていますが、どのマイナーパッチが当たっているのか、1年前のものなのか、いやいや1週間前のものなのかが、これだけでは絶対に判断できないブラックボックスになってしまうところです。
もう1個の問題も何度か出てきますが、独占という問題があります。例えば、でき上がったコンテナに脆弱性ができたとしましょう。脆弱性をパッチする時に、毎回このDockerfileを作った人を呼び戻して、ビルドパイプラインを流すように指示しなくてはいけなくなってきてしまいます。テストはどうするんでしょうね。
テストも、「基本的にはインフラ起因でパッチを当ててくれ」という依頼にもかかわらず、ビルドもテストもアプリの方々にお願いし直さなければいけない問題が発生します。
こういうのが、このDockerfileにまつわる問題だと思っています。
(スライドを示して)InnerLoop、OuterLoopの考えかた、特にこのコンテナを使った開発をしていく上で、まず非常に検討してほしいと思っているのが、Cloud Native Buildpacksと呼ばれているものです。
先ほどのDockerfileとの対比になるものですが、特徴は何かというと、まずDockerfileを使っていないということです。ソースやコンパイルしたものを投げつけると、ベストプラクティスという言葉は間違っていますが、標準イメージをopinionatedな方法でコンテナを作ってくれます。
後ほどちょっと触れますが、BOMによるホワイトボックス化や、Rebaseによる外部パッチ適用にも対応できる特徴を持っています。
このあたりを、もう少し細かく見ていきましょう。
(スライドを示して)Cloud Native Buildpacksは、今、実際にCloud Native Buildpacksのページに比較表があります。まずこの中のRebasingを取り上げたいと思います。
(スライドを示して)先ほどのDockerfileのパターン、もう少し細かく言うと、例えばDockerfileの中にFROMやJavaのレイヤー、アプリのレイヤーがあると思いますが、ベースイメージ側に脆弱性があってパッチしましょうという時に、どうしなければいけないか。
Dockerfileは、レイヤーが下位になればなるほど、そこの下位の変更をする時は、上位も全部ビルドし直す動きを基本的にしなければいけません。
そのため、ベースイメージの更新とともに、Javaの再更新、アプリケーション、もしかしたら再コンパイルも走らせなければいけないので、コンテナを全部再ビルドしなくてはいけません。
Cloud Native Buildpacksで作ると何がいいかというと、コンテナはちゃんと作る。レイヤーを使って、ファイルシステムが分かれるようになっています。各ファイルシステムに独立性が保証されています。Cloud Native Buildpacksは、ファイルシステムのみを差し替えられるようになっています。
ベースイメージに脆弱性が出たら、そのベースイメージのレイヤーだけを差し替える(ことができます)。ファイルシステムとして差し替えられるようになっていて、上位のレイヤーを触らないことができます。再コンパイルなどは走りません。
同じバイナリで、しかもJavaのランタイム系だったら、ランタイムがその違いを吸収してくれます。これは「絶対にテストしなくていいのか」と言われると、私も難しいです。お客さまごとに判断は変わってくるとは思います。
少なくとも、テクノロジーとしてなにか脆弱性があった場合に、インフラ起因でそこだけをパッチしていく技術が取れます。これはCloud Native Buildpacksの1個大きな強みだと思っています。
(スライドを示して)もう1つ、「Bills of Material」という話をしたいと思います。
最近のバージョンだと説明が変わってきますが、旧バージョン方式で説明します。
Dockerfileで作ったイメージに、一応メタ情報というものがありますが、スライドのように、メタ情報はあまり大したことが書いていません。これが1つ、先ほど言ったブラックボックス(のこと)ですが、メタ情報以外のものがないので、この中で使われているバイナリのバージョンを見ようと思っても、直接ログインして、最悪の場合、findコマンドで探しに行くことが必要になってきます。
Cloud Native Buildpacksの大きな特徴は、ビルド時に、例えばOSSのライブラリ、ベースイメージで使われているUbuntuであればUbuntuのライブラリのバージョンを、メタ情報に残すことをやってくれます。
これがコマンドでできます。例えばpackというコマンドを使うと、実際のコンテナの中に入らずとも、そのコンテナの中にどういうライブラリ、どういうソフトウェアが、どういうバージョンが使われているかの一覧を取得できるようになっています。
脆弱性のイメージスキャニングは、普通大きくやっていくとすべてのファイルシステム総スキャンをするパターンが多いと思っていますが、BOMであれば非常に低負荷かつ高速でスキャニングできます。
インフラとしてうれしいのは何かというと、今後アセットがどんどん増えていく中で、管理台帳を作らなくていいわけです。私はあるお客さまで、コンテナ開発をこれからしていくものの、インフラ担当者がExcelで管理台帳をつけ始めてしまっているのを見ています。
Cloud Native Buildpacksを加えることによって、やってきた開発物たちがどのようなものを持っているのかを自動的に取得できる仕組みが取れるのも、大きな特徴です。
これを先ほどのInnerLoopとOuterLoopの考えかたに照らし合わせましょう。(スライドを示して)この絵は若干複雑にはなっていますが、見てほしいところは何かというと、InnerLoop、OuterLoopの登場人物は開発者と言っていますが、おそらくお客さんの多くは、開発者にもいろんなタイプがあると思っています。
(タイプの1つは)まず、フル内製化しているチームです。内製化しているチームの方々は、一番左の開発クラスタを使いながら、InnerLoopの早いところ、でき上がったらコミットをする時に、ビルドクラスタが先ほどのCloud Native Buildpacksを中心に作っていた場合、それでコンテナのイメージとYAMLはでき上がってきます。
別のチーム、SIerの方々が作ったとしましょう。SIerの方々には開発クラスタではなく、自分の環境で作ったJavaのソースコードがあるとします。これも同じように共有させられます。同じ仕組みでビルドパックを使って、コンテナを使って、YAMLファイルができてきます。
保守チームは、なにか脆弱性に問題があった時にRebaseで対応できるパッチであれば、そのままRebaseで対応していきます。コンテナで作ったものもそうですが、ビルドクラスタはその時のYAMLファイルの更新もやってくれます。
また、いろいろビルドする時に出てくる脆弱性検査を、例えばSBOM(Software Bill Of Materials)を外部のデータベースに保管をしていきます。なので、これから環境にデプロイされるものの一覧表を取得できる仕組みが取れることになってきます。要は、彼らをいちいち戻さなくても、ある程度保守側で開発物の管理ができるようになってきます。
これはOuterLoop側からして何がうれしいかというと、この3チームがどういう手段でやろうと、このOuterLoopから常に同じに見えてくるわけですね。
保守でやってきたイメージ、SIerが作ったイメージ、内製が作ったイメージ、全部ビルドパックです。今日紹介したビルドパックの部分だけにしますが、ビルドパックでまず標準化されたコンテナや、このビルドクラスタが、そのようなした仕組みで成果物がやってくるという方式になってきます。
本日は、あくまでこの1ヶ所のみの紹介となってしまいましたが、これ以外にもこの考えかたはいろいろなところであると思います。ステージングクラスタ、プロダクションクラスタといったところです。
今日以外のところで、このInnerLoop、OuterLoop、それを取り巻く技術にどういったものがあるのかを、最近は我々VMwareのブログで少しずつ紹介しています。興味があればぜひ見てもらえればと思っています。
短い時間でしたが、本日はVMwareの新しい考えかたと、InnerLoop、OuterLoopを紹介しました。
関連タグ:
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える秘訣 「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2024.12.02
給料や人間関係が良いだけでは部下は満足しない メンバーの「働きがい」を育む5つのステップ
2024.11.29
やたらと多い自慢話、批判や噂好き…「自己重要感」が低い社員の特徴 管理職が知っておきたい「一生働きたい職場」の作り方
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.28
“新規事業が生まれない組織”に足りていないもの 「PoC貧乏」に陥らず、アイデアを形にするためのヒント