Kubecon 2021: Kubernetesハッキングのロールプレイが中心だった、全体的には退屈で企業向けのイベント

Table of Contents

Kubecon 2021: Kubernetesハッキングのロールプレイが中心だった、全体的には退屈で企業向けのイベント

Kubecon Kubernetes クラスターに侵入する方法に関するセッションは、Kubecon のハイライトの 1 つでした。Kubecon の主なイベントは概して当たり障りのない企業関連のものでしたが、これはおそらく、このテクノロジが現在、企業の間で事実上のインフラストラクチャ標準となっていることを示しているのでしょう。

Kubernetes プロジェクトをはじめ多くのプロジェクトを主催する Cloud Native Computing Foundation (CNCF) の CTO、Chris Aniszczyk 氏によると、Kubecon Europe は先週オンラインで開催され、27,000 人以上が参加したという。

これは、同じくバーチャルで開催された昨年のイベントで報告された約13,000人から大幅に増加した数字です。Kubernetesは巨大な存在であり、今回のイベントの根底にあるテーマは、Kubernetesが標準的なランタイムプラットフォームになりつつあるという点でした。

イベントでは強力な技術的コンテンツが多数提供されましたが、Kubernetes が大きなビジネスであることは参加者に疑いの余地がなく、基調講演の多くの内容には、いつもの相互の称賛とともに、冷淡な企業風味が漂っていました。

CNCFは27の新規メンバーを迎え、可観測性スペシャリストのNew Relicがプラチナメンバーに選出されました。これは、Kubernetesデプロイメントからメトリクス、ログ、トレースを収集・分析するOpenTelemetryプロジェクトの重要性を浮き彫りにするものです。New RelicのZain Asgar氏がCNCF理事会に加わりました。Asgar氏は、2020年12月にNew Relicが買収したPixie LabsのCEOです。Kubernetesネイティブの可観測性製品であるPixieはオープンソース化されており、CNCFへの貢献が予定されています。

「私たちは、観測可能性製品をどこにでも普及させたいと考えていました。どこでも使える商用製品を提供するのは非常に困難です」と Asgar 氏は語りました。

「Pixieの目標は、ベンダーに依存しない、誰もが使えるものにすることです。」商業的な側面としては、PixieはNew Relicのプラットフォームが利用できるデータソースであり、同社はこの技術を管理するためのオプションとしてPixie Cloudもホストしている。

Spotifyは、複数のサービスの管理と情報共有を容易にするソフトウェア「Backstage」の開発で「CNCFエンドユーザー賞」を受賞しました。Kubeconで講演したウェブエンジニアのエマ・インダル氏によると、Spotifyは1,600人のエンジニア、14,000のソフトウェアコンポーネント、そして1,400のマイクロサービスを運用しており、これがBackstageの開発理由、そしてSpotifyアプリが人気が出たときのようなシンプルで素早い音楽ストリーミングではなくなった理由を物語っています。

Kubernetesのハッキング:ストーリー

いつものことながら、最高のコンテンツは基調講演ではなく、目立たないセッションにありました。特に注目すべきは、Title社のプロダクト責任者であるEllen Körbes氏と、Datadog社のシステムセキュリティエンジニアであるTabitha Sable氏による「Kubernetesへのハッキング」に関する短いセッションでした。Korbes氏は架空の企業の開発者役を演じ、Sable氏は「DevSecOps実施責任者」という大役を演じました。

物語は、ケルベス氏がクラスタ上で自分のポートを別の開発者が使っていることに腹を立てたことから始まった。「セキュリティ担当者を呼ぶつもりはありません。彼らは面白くないですから。自分でやります」と彼女は言った。

彼女はクラスターに対する限定的なRBAC(ロールベースアクセス制御)権限しか持っていませんでしたが、それでも彼女は諦めませんでした。より高い権限を持つ名前空間で実行されているポッドのシェルにアクセスし、そこから必要なコマンドを実行したのです。侵害は発覚しましたが、ケルベスは「開発クラスターが一日中使えないなら、残りの一日は休んでもいい」と考えていました。

彼女は CVE-2019-11253 を発見しました。「Kubernetes API サーバーにおける不適切な入力検証により、承認されたユーザーが悪意のある YAML または JSON ペイロードを送信でき、API サーバーが過剰な CPU またはメモリを消費し、クラッシュして使用できなくなる可能性があります。」

Tiltのエレン・ケルベスがKubecon EuropeでKubernetesハッカーを装う

Tiltのエレン・ケルベスがKubecon EuropeでKubernetesハッカーを装う

DevSecOpsは、開発者の行動をコントロールするためにセキュリティを強化しているが、Körbes氏は監視されることを嫌がり、ログを削除することにした。「誰も何も監査していない」。そこでCVE-2020-15257が登場した。「containerd-shim APIがホストネットワークコンテナに不適切に公開されている」。Körbes氏はこう考えた。「Kubernetesが稼働している基盤の脆弱性を利用すれば、Kubernetesのセキュリティを完全に回避できる」

リバースシェルと少しの(未公開の)コードを経て、彼女は参加することができました。Kubernetesの脆弱性は「めったに発生しませんが、一度発生すると1日が台無しになることもあります」と彼女は考え込んでいました。続きがあります。この話は5月14日から公開されるので、完全にネタバレはしません。

「講演を魅力的にするには、どうしたらいいか学ぶのにとても苦労しました。人々の興味を引き続けるには、ストーリーが重要です」と、Körbes氏はその後の総括で説明した。一方、Sable氏は次のように述べた。「Kubernetesのセキュリティは、Linuxセキュリティとネットワークセキュリティ、そして通常はクラウドプロバイダのセキュリティが融合しているため複雑です。さらにKubernetesには、特にRBACとRBACとの連携に関して、さらに複雑なレイヤーがあります。…これは、Kubernetesに対するContainerdのエクスプロイトが公開された最初の例だと思います。」

複雑すぎますか?

素晴らしいセッションでした。Kubernetesの大きな問題点、つまりその複雑さゆえに習得が難しく、間違いやすい点を端的に示していました。この問題をどのように解決するのか、あるいは解決すべきなのかについては、まだコンセンサスが得られていません。そこで、軽量なK3Sディストリビューション(最近ますます話題になっています)をベースにしたホスト型Kubernetesを提供する英国企業、CivoのCEO、マーク・ブースト氏にお話を伺いました。

Boost氏は、同社がKubernetesに注力しているにもかかわらず、将来的にはKubernetesを直接扱う組織は減少するだろうと考えている。「Kubernetesは優れた製品ですが、将来的にはKubernetesが裏で動作するようになり、Kubernetesは引き続き稼働しますが、その上に管理レイヤーが追加されることで、物事をシンプルにしていくことになるでしょう。」

そうなると、結局、インフラを管理せずにクラウドで Ruby アプリケーションを実行する方法として 2007 年に開始された革新的なサービスである Heroku に戻ることになるのでしょうか (その後、他のランタイムもサポートするように進化しました)。「ある意味ではそうなります」と Boost 氏は語りました。

Kubernetesの使用はもっと簡単になるべきだ、そしてもっと簡単にできるべきだという意見に多くの人が同意している一方で、柔軟性と制御性のために複雑さを我慢するユーザーもいるようです。「アプリケーションのモダナイゼーションを始めるチームが増えるにつれて、導入時の認知コストを下げるためにできることは何でも良いのです」と、HEBのエンジニアリングディレクター、ジャスティン・ターナー氏は、クラウドネイティブ開発の未来に関するKubeconパネルで述べました。

「しかし、抽象化を過剰に重ねすぎると、制御性が大幅に低下してしまうという問題があります。演算子を実行する能力も失われます。抽象化の層が多すぎると、そうしたオプションが利用可能であることを理解するのが難しくなるかもしれません。」

IBM CloudのCTO、ジェイソン・マギー氏は次のように述べています。「Kubernetesから学んだ教訓は、ワークロードには多様性があるということです。人々はサービスとしての消費モデルへと移行しつつあり、Kubernetesはユーザーが何をしようとしているかに応じて、プラットフォームの利用方法に関して異なる個性を持つように進化しています。HerokuやCloud Foundryスタイルのプッシュコードなど、多くの人がそれを望んでいます。しかし、おそらくその世代の教訓の一つは、プラットフォームがあらゆることに対応できるわけではないということでしょう。」

私にとってKubernetesの強みは、シンプルなアプリを作るならKubernetesのスタイルを使えることです。アプリケーションの詳細をいじってステートフルな動作をさせたい場合でも、すべて1つの環境で実行できます。Kubernetesの利用方法にこれを追加していくつもりです。問題は、それを1つの方法で実現するのか、それとも35通りの方法を用意するのかということです。

おそらく35通りもあるでしょう。Kubernetes自体をめぐるコンセンサスはさらに注目に値します。「業界で初めて、Kubernetesを事実上のコントロールプレーンとしてインフラストラクチャを標準化しました」とアニシュチク氏は述べています。®

Discover More