KubeCon + CloudNativeCon NA 2021 レポート

概要

KubeCon + CloudNativeCon North America が 2021年10月11日から15日の日程で行われた。 11日と12日には co-located event があり、本体のイベントは13日からの3日間であった。

トラック毎のセッション数の比較を下に示す。 強いて変化を述べるなら、運用 (Operation) のセッション数が減っている程度である。

f:id:iwamotoo:20220113183607p:plain
セッション数

今回はパンデミック以降初の会場とネット配信のハイブリッド開催であったが、音声が聞きにくいったといったトラブルはなく、運営の準備の苦労がしのばれる。 なお、感染対策として会場ではコーヒーも含め一切の飲食が禁止だったそうである。

質疑は収録されていないが、発表動画は CNCF YouTube channel (https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA) から辿ることができる。

SupplyChainSecurityCon

software supply chain が攻撃対象となっていて対策が必要というのは、前回の Cloud Native Security Con の頻出トピックだったが、今回は supply chain 単独での会議が設定された。

最初の welcome キーノートで、Kubernetes のリリース毎に SBOM を作るようになったと言って拍手されていた。あと、operation SLSA の宣伝の動画 (https://www.youtube.com/watch?v=S_MXbt0p_pg) が公開されていた。(この動画は KubeCon 本体でも出てきた)

発表資料は以下のスケジュールから辿ることができる。

https://events.linuxfoundation.org/supplychainsecuritycon-north-america/program/schedule/

Project Trebuchet: How SolarWinds is Using Open Source to Secure Their Supply Chain in the Wake of the Sunburst Hack

SolarWinds というのは network management software を開発している会社である。

Trebuchet というのは CNCF のツールとかを使って作られた build system のことで、半年くらいで opensource にするつもりとか言ってる。

Trebuchet の内容に先立って、SolarWinds の製品である Orion Platform に起きた攻撃 (supply chain attack) を説明していた。 ビルドプロセスの途中で悪意を持つDLLが挿入され、それがお客さんの Orion Platform の更新時に配信されていったとのことである。 攻撃を受けたと判明してから、大量の DLLを decompile してどれがやられたか調べたそうである。 検出を難しくするような手口が使われており、すごく洗練された攻撃 (adversary) だと言っていた。

そのような DLL の注入を許さないようにするために build インフラを作りなおさなくてはいけなくて、それの technical requirement を話していた。 ephemerality, determinism, consensus, proof だそうである。

github actions とか使いものにならなかったので tekton ベースにつくったとか言っていた。 SaaS だと同じ repo に pipeline definition を置くことになるからポリシーを強制できないからだめ、とのことである。

github から tekton pipeline 叩くとか、in-toto で記録をとってるとか、validation cluster でも自動でビルドを流して同じ結果になるか確認しているなどと動作を説明していた。

重大なセキュリティ事故だったため、質疑では CEO が2回議会証言したといった話もでてきた。 他に、Slack では、なんで build system 2つ要るんだといった質問も出ていた。

参考: SUNBURST について https://www.microsoft.com/security/blog/2021/01/20/deep-dive-into-the-solorigate-second-stage-activation-from-sunburst-to-teardrop-and-raindrop/

The state of SBOMs

司会が話題を振ってそれを他の参加者が答えるといった形式で、4人で話していた。

SBOM があるかどうかをサンドイッチにたとえてる人がいて、subway sandwich と farm to table restaurant がどうとか言っている。後者のは中身の生産者がわかっててより高品質な素材を使っているとか話していて、それが SBOM ありに対応するのだろうが、ちょっとわかりにくい比喩のような気もした。

他に、package manifest と SBOM は違う (前者には dependency の情報がない) といった話がでていた。

最後に、configuration management が次の課題だとか言っていた。これは、製造物が意図した使われかたをされているかを管理するといったことで、例えばインターネットに直接繋ぐことを意図して作られてないものがまちがえてインターネットに直結されてないかをどう担保するかといった話である。

whose sign is it anyway?

sign の問題点についてのプレゼンである。 有効な署名とは秘密鍵とデータが過去の一時点で一緒に存在したことを示すだけで、他の全てはポリシーできまると問題をまず定義していた。 署名を信用してよいかとか、誰がサインしたのかとかいった、署名を役立たせるために必要なものはポリシーであって、緩すぎても厳しすぎてもうまくいかないと言っていた。 続いて、key management の問題、key hygiene の問題、compromise された場合の回復手段を順番に話していた。

後半は Marina Moore (NYUの PhD candidate) にかわって、ケーススタディとして、uptane, pypi & pep 480, notary v2 を順に取りあげてどういうポリシーになっているかを話していた。

脅威モデルが最初にあるべきで、それによって解はかわってくるとまとめていた。

An overview of SLSA

今回の会議でしばしば紹介されていた SLSA (https://slsa.dev) の概要のプレゼンである。 サプライチェーンのどこでどういった攻撃が可能かといった図を示した後、SLSA の目的は改竄 (tampering) から守ることであって、SLSA ではセキュリテイレベルが4段階定義されてると言っていた。

その後、いくつか例を挙げて、どういった攻撃がどの SLSA level で reject されるかといった説明をしていた。 サプライチェーンを防御することを考えると、どの箇所をどういったポリシーで守っていくか考えるだけで大変な気もするが、SLSA では 4段階のレベルに単純化されていて、徐々にセキュリティを高めていけることがポイントなのかと思った。

最後に SLSA level 1 は tampering の耐性はないとわざわざ断っていた。 まだ開発中なので協力してくれとまとめていた。

Cloud Native Security Conference

発表資料は https://events.linuxfoundation.org/cloud-native-security-conference-north-america/program/schedule/ から辿ることができる。

Replacing PSPs? Keep Bad Pods out of your cluster using Kyverno!

PSP (PodSecurityPolicy) が 1.21 で deprecate されたが、PSP の代わりに PSA (PodSecurityAdmission) と kyverno を使うようにするとよいとか話している。 PSA は細かい制御ができないので kyverno (https://kyverno.io) を使うとよいとのことである。

PSP とか PSA の細かい話には立ち入らず、ひたすら kyverno の話をしていた。

Security Chaos Engineering For Fun & Profit

chaos engineering との違いは、これは security fault を突っ込んでみて、防御できたり対処したり回復したりがちゃんとできるかを調べるということだそうである。 security fault が具体的になんなのかはよくわからない (後で出てくる)。

cloud native では attack surface がひろいとか言っている。

後半になって、 security fault の例として S3 bucket に対する攻撃がでてきた。 S3 bucket はよく攻撃対象になるからだそうである。 悪意のあるポリシーを設定したり勝手に暗号化したりといった攻撃例を示していた。

Risk Driven Fault Injection というタイトルで、管理職に security chaos engineering を説得するのに使えそうな図がでてきた。

本も論文もでてるから興味があったら見てねとまとめていた。最後のスライドにリンクがある。

Data Security: Theoretical and Real World Approaches to Compartmentalization

Rook Ceph operator の説明をしているが、どうもこれはセキュリティの例題のようである。 ディスクとか経路の暗号化もできると説明している。

Rook で Ceph が便利につかえるがセキュリティ的にはまだまだであると言って本題になった。これ以降は Rook も Ceph もあまりでてこない。 CVE の数を減らすにはどうしたらいいかという話になった。

RedHat の CVE のうち1%が CWE 284 (improper access control) だとか、CVE の 21% がバッファオーバーフローだとか言っている。

バッファオーバーフローが起きないから go とか rust いいよねとか話してる。そういった言語の機能でバッファオーバーフローをなくしていこうと言っていた。

後半では formalization とか proof とか話していた。形式手法で安全性を保証したいということのようであった。

キーノート

KubeCon + CloudNativeCon のキーノートは、 Priyanka Sharma の歓迎メッセージから始まった。 hybrid 開催できて嬉しそうである。会場はカメラからは結構人が入っているように見えた。 時折歓声が聞こえたので、会場席から喋ってはいけないといった規制はないようである。

通例通り、CNCF project updates と Kubernetes project updates とユーザーストーリーが主な内容であったが、これらは既に他所で記事になってると思うのでばっさり省略する。 目新しい話題としては、 RISC-V や、SupplyChainSecurityCon でも頻出の SBOM などがあった。

And Here We Go: Dual-stack Networking in Kubernetes

発表者は Lachlan Evenson, Azure の人である。

2019 年の San Diego の KubeCon の写真がでてきた。会場の大きさがぜんぜんちがう気がする。 2019 年の KubeCon に出てた人は、当時もキーノートで dual-stack の話があったから time warp した気分になるかもしれないけどそうじゃないよとか言っている。

当時はシンプルに ipv4 と ipv6 で service (kubernetes リソース) を別になる設計にしたけど、使いにくくて良い考えではなかったので書き直したという話である。 dual-stack service のために network を結構書きなおした (11000行足して3000行消した) と言っていた。

シンプルなものが必ずしもよいわけではないとか、大きな変更もコミュニティの協力があれば成し遂げられるとかまとめていた。

Sustaining a Contributor Community's Next Generation

Paris Pittman が踊りながら登場した。SIG contributor experience の話とかをしている。

すごい額の computing resource が Kubernetes の CI/CD に使われているとか言っている。月あたり 20万から30万ドルだそうである。

次の世代の contributor を育てるための shadow program とか community building の話をしていた。 sponsorship が大事で、おかげで私達もここに来れたとか言っていた。

一般セッション

KubeCon + CloudNativeCon の一般セッションのいくつかを以下に紹介する。

発表資料は以下から確認できる。

https://kccncna2021.sched.com/

Deploying Unikernels in Production with Kubernetes

前半では unikernel を説明していた。カーネル、OS、アプリケーションのうち必要なものだけ取りだしてビルドして、 single address space で動かすというやつである。libOS とかキーワードもでてきた。 CI/CDパイプラインで unikernel をビルドできるとか言っている。

後半では、起動時間の比較とかいろいろグラフが出てきて unikernel は速いと言っていた。

runc を runu に置きかえて unikernel を CRI 経由で起動するんだとか、unikernel image は containerd に取ってこさせると説明していた。 runu は libvirt を叩いて unikernel を実行するようである。

デモもあった。 runtimeClassName で runu を指定していた。

発表者たちはこの技術をもとに Unikraft (https://unikraft.io) という会社を作ったようである。質疑も活発に行われていた。

Kubernetes and Checkpoint Restore

発表は Adrian Reber @RedHat で、checkpoint & restoreを 10年くらいやってるとか言っている。 container live migration の話である。 CRIU (Checkpoint/Restore in Userspace) と呼ぶらしい。 いろんなアプローチがあるけど userland 実装でやっていると言っている。

CRIU は OpenVZ とか Borg とか LXC/LXD とか Docker とか Podman では動いてるが、cri-o は CRI いじらないといけないので中断してるとのことである。

Forensic Container Checkpointing という KEP (https://github.com/kubernetes/enhancements/issues/2008) を出していて、checkpoint 機能で forensic analysis をできるようにしようとしてると言っていた。

TCP connectionもそのままだと (質疑で) 言っていた。

CRIU の実装は以下のようになっている。

  • ptrace でとめる
  • /proc から情報をあつめる
  • parasite code でプロセスの内部から情報をあつめる

質疑がいっぱいでていた。

参考: https://github.com/checkpoint-restore/criu

Notary: State of the Container Supply Chain

Executive Order on America's Supply Chains (https://www.whitehouse.gov/briefing-room/presidential-actions/2021/02/24/executive-order-on-americas-supply-chains/) という大統領命令がでてびっくりしたという話を冒頭にしていた。 現状の container supply chain の状況は、いろんな人がやろうとしていて gold rush のようであると言っている。 重なる部分があるけど gap があるよりいいよねとか言っていた。

supply chain の段階には、作成、配布、消費の3段階があるが、Notary v2 で扱うのは後2者であると言っている。

image の署名について、空港のセキュリティを例にして説明していた。 image をどういった条件で信用するかについて模式的な例をだして、どういうポリシーでどう判断するかといった話をしていた。 image をビルドする場所と Docker Hub と image を使う場所が分かれていて、ネットワークの制約もあったりして難しいんだとのことである。 OCI artifact を拡張して ORAS artifact (http://github.com/oras-project/artifacts-spec/) を作って SBOM とか security scan の結果を記述できるようになったとか言っている。

デモもあって盛り沢山な内容であった。

SIG Node Intro and Deep Dive

SIG Node の担当範囲やサブプロジェクトを紹介した後、 roadmap の話になった。 Memory QoS (https://github.com/kubernetes/enhancements/issues/1769) の話をしていた。

1.23 の roadmap では、 In-place Pod update (動いてる Pod の resource 制限を変更できる機能)が入るといいなと言っていた。(実際には 1.23 には間にあわなかったようである。)

kubelet の Pod lifecycle イベントループのリファクターをやったとも言っていた。 元々バグを1つ直そうとしていたのだが、 race condition を含めいろいろバグがみつかったので直していたそうである。

conprof - profiling in the cloud-native era

タイトルは conprof という名前であるが、今は parca (https://github.com/parca-dev/parca) という名前にかわったそうである。

最初にプロファイリングの一般的な話とか pprof (https://github.com/google/pprof) の説明をしていた。 問題が起きてからプロファイリングするから正常時のデータがわからないとか、手動でやるから間違えるといったプロファイリングの問題点を列挙して、常にプロファイリングするようにすればいいと言っている。 サンプリング方式のプロファイリングだから性能の影響はほとんどないとのことである。

parca の説明になった。 inspired by prometheus とか言っていて、prometheus の実装を参考にいろいろ作ってあるみたいである。 parca-agent は cgroups を discover してデータ収集していて、eBPF つかって実装してると言っていた。

デモでは、 web UI でプロファイル結果を表示させてみていた。

parca の storage の実装についても話していて、これも prometheus のまねをしたけど TSDB を書きなおしたといったことを話していた。 TSDB の実装についてやたら詳しく話していた。

最後に roadmap を話していたが、まだデータをディスクに保存したりはできないようで、まだまだ開発中なのかなと思った。

まとめ

2019年の秋以来の久しぶりにリアル会場でも開催された KubeCon であった。 Linux Foundation のスポンサー用資料 (https://events.linuxfoundation.org/wp-content/uploads/2021/12/sponsor-cncf-2022-12.23.21.pdf) によると、約3500人がリアル参加登録、2万人弱がバーチャル参加登録したそうである。

キーノートで発表があった通り、次回は Valencia, Spain の予定である。 個人的事情で海外出張に行くのはちょっと難しく、covid もまだまだ怖いので、オンライン参加の選択肢があることはありがたい。 一方で、イベント主催者にとってはリアル参加者が増えないと困るのではないかと思われる (上記のスポンサー用資料では強気の参加者数予想が示されている) し、現地に行けばたのしいだろうなとも思うので、単純に選択肢が増えてよかったと喜んでるわけにもいかないのかななどと考えてしまう。