- 概要
- Cloud Native Security Day
- Modern least privilege with DevSecOps
- Securing open source
- Computing confidentially in the clouds
- Securing the software supply chain
- Making dynamic admission control even more dynamic
- Namespaces-as-a-Service with HNC and Kyverno!
- Beyond signatures
- Security Nutrition Labels
- A First Look at the Security of Serverless Applications
- Keynote
- 一般セッション
- まとめ
執筆者 : 岩本 俊弘
概要
KubeCon + CloudNativeCon Europe 2021 Virtual が 2021年5月3日から7日の日程で行われた。 3日と4日には Co-located Events があり、Keynote があったのは5日からの3日間であった。 4日には Kubecon の Lightning Talks があったが、Cloud Native Security Day に参加していたので視聴していない。
トラック毎のセッション数の比較を下に示す。全般的に前回や前々回より少なめである。
発表資料や録画されたセッションは、 sched.org のスケジュール表 (https://kccnceu2021.sched.com/) や CNCF youtube チャンネル (https://www.youtube.com/channel/UCvqbFHwN-nwalWPjPUKpvTA) から参照できる。
Cloud Native Security Day
並行して CTF (Capture The Flag) が行われていて、私も参加してみたのだが、英語の発表を聞きながらシステムの脆弱性を探すのはつらく、残念ながら課題はクリアできなかった。
kubesimulator というもので用意された kubernetes cluster を CTF 参加者ごとに用意していた。 CTF の解答は、 twitch (https://www.twitch.tv/cloudnativefdn) で数回に分けて攻撃方法の解説をやっていた。 container の中から host filesystem を mount したりとか、overlayfs の mount option から下のレイヤがなにかわかるとか説明していた。
Modern least privilege with DevSecOps
VMware Tanzu の Sponsored Keynote で、least privilege 自体は昔からいわれていることだけど、Cloud Native ではセキュリティはどうあるべきかといった話をしていた。 Repair (脆弱性のあるソフトを直す), repave (known good state からサーバを作りなおす), rotate (システムの証明書を頻繁に更新する) が重要であると言っていて、それらをまとめて 3R と呼んでいた。 ephemeral, immutable などど1年前の Security Day でも聞いたようなことを言っていたのでそういうものなのかと思った。
Securing open source
ビルドしてパッケージするといったソフトウェアリリースの一連の作業を図示する software supply chain integrity map というものがでてきた。 各段階でのどんな攻撃ができてどんな対策が可能かといった話をしていた。
silver bullet はなくて簡単な解決策はないが、OSS開発者やユーザは openssf.org/edx-courses で勉強したり、ソフトウェアを使う前に評価したほうがいいといった話をしていた。
Computing confidentially in the clouds
Hypervisor は伝統的には host を悪意のある guest から守るものであったけど、Confidential Computing は guest を悪意のある host から守るものであると説明している。 TPM と HSM の違いなども説明していた。
Intel が SGX device plugin for Kubernetes をリリースして、Azure でも使えるよと宣伝していた。
- https://azure.microsoft.com/en-us/blog/bringing-confidential-computing-to-kubernetes/
- https://intel.github.io/intel-device-plugins-for-kubernetes/README.html#sgx-device-plugin
Securing the software supply chain
ビルドパイプラインを secure にする話である。 伝統的な CI/CD はデータではなく過程を信用していたが、これからの zero trust architecture では evidence based にならないといけないとか言ってる。 in-toto を使って、build policy と build pipeline を decouple して各段階で署名をチェックするといったことを言っているようである。 ビルドパイプラインの各段階でのワークロードの identity は SPIFFE/SPIRE を使って確認するようである。
後半では in-toto のデモで、パイプラインの各段階で実行されるコマンドを in-toto run で wrap していると説明していた。 spiffe の URL が in-toto の引数に追加されていた。 実行を許可されたコマンド (引数も) は in-toto の設定に書いてあって、それ以外のコマンドが実行されたらエラーになるようである。gitlab CI の設定 yaml に変なコマンドを一行足して、ほらエラーになったでしょと実演していた。
Making dynamic admission control even more dynamic
導入で DevSecOps は実際にやるのは難しくてポリシーを実際にコードで実装してる人は16%しかいないとか、ポリシー X を言語 Y でかくのにたくさん時間かかるとか言っている。
kubewarden.io を使えば WebAssembly で書かれたポリシーを Kubernetes で使えるという話になった。 好きな言語で書けるとか他にもいろいろいいことがあって WebAssembly がすばらしいと言っている。
ポリシーは container registry を使って配布されるとか、safe Wasm 環境で動くとか説明していた。 現状は alpha quality で、validation と mutation ができるそうである。
OPA があるのになんで wasm based のを作るのとか質問されていた。 OPA は rego でかかなきゃいけないからというのが答えで、rego も Wasm にできるよとも言っていた。
go は standalone wasm にコンパイルできなくて、tinygo にしなきゃいけないけどそうすると今度は kubernetes data types が使えないとか話していて、なんか難しいんだなと思った。
Namespaces-as-a-Service with HNC and Kyverno!
HNC (hierachical namespace controller) の話をしている。 Kubernetes の namespace に階層構造を入れることによって、管理がしやすくなったり、管理者がユーザ毎に作った namespace の中を各ユーザが self-service できるようになるといったメリットを言っていた。
ただ、HNC だけだと namespace の self-service はできなくて、 kyverno というポリシーエンジンを一緒に使うことで、新しい namespace を作ったときの設定を自動化して適切な権限を付与できると話していて、デモもしていた。
HNC は https://github.com/kubernetes-sigs/hierarchical-namespaces にある。
Beyond signatures
NYU の PhD student による notary v2 の話である。(NYU には TUF をやっている人がいる)。
TUF がどうなってるとか、攻撃の耐性がどうとか説明していた。 TUF は threshold signature を使っているので、指定した threshold 未満の鍵が奪われることに対する耐性があるとか言っていた。
Notary v2 は設計段階で、以下の prototype-tuf ブランチに TUF を使ったプロトタイプがある。 複数のブランチで開発が並行しているようなので、プロトタイプをいくつか作って試しているということなのかと思った。
https://github.com/notaryproject/nv2/tree/prototype-tuf
Security Nutrition Labels
Nutrition Label とは "nutrition facts" と食品に表示されてるあれのことである。 依存するソフトウェアが大量にあって困っちゃうので、各ソフトウェアのセキュリティ情報を一目でわかるようにまとめて表示したらどうかといった話で、善意にもとづくシステムを想定しているようである。
ユーザはその表示をもとに信頼してあるいは使ってよいソフトウェアかどうかを判断できるようにしたいようである。
label にどんな情報を書くべきかとか、例として telepresence とか linkerd ではこんな表示になるんじゃないかといった説明をしていた。
概して好意的な反応が多かった。
A First Look at the Security of Serverless Applications
VM から container になって分離があやしくなったけど serverless だともっとあやしいとか言っている。
性能を優先するためにセキュリティを犠牲にするような設計上の選択がされているとも言っていた。 serverless だとユーザがいじれる部分があまりないので false sense of security を持ちがちだけど、クラウドプロバイダの serverless の中身はドキュメントされてないのでよくわからないと言っている。 研究者は関数インスタンスがどう置かれているかとかリソースがどう管理されてるかといったことを調べていて、クラウドプロバイダによって結構差があるそうである。
最後にどんな攻撃が考えられて、アプリケーションレベルではどういった対策ができるかといった話をしていた。
Keynote
初日のキーノートでは最初に Priyanka Sharma 氏が話していた。 パンデミックで全てが変わってしまったが Anthem (保険会社?) では Cloud Native 技術を使ってワクチンを受けられる場所を表示するサイトを作っているという事例や、 DoorDash というフードデリバリーのサービスも Cloud Native を使っているといった事例を引き合いにだして、 パンデミックでみんな オンラインに移行したので Cloud Native にとってはチャンスであるといった話をしていた。
恒例のセッションとして、CNCF の各プロジェクトと Kubernetes の最近の変更をざっと説明するセッションやスポンサーのセッションもあった。 Kubernetes の dockershim と podsecuritypolicy の deprecation にも触れられていた。
covid-19 パンデミックに対してソフトウェアで何ができるかといったセッションが複数あったのも印象的であった。 Linkerd vs COVID-19 というセッションでは、 linkerd がパンデミック対策のどういうプロジェクトで使われていると話していた。また、 COVID Tracker - Testing & Contact Tracing というセッションでは、アイルランドでの接触追跡アプリの話をしていて、Googleとかが接触追跡フレームワークを作る前からやっていたとか、プライバシーの懸念があるからオープンソースでやらなきゃいけないとか説明していて、技術のわかる人がトップにいるとこうも違うのかと溜息がでた。 Facebook とか Instagram のアプリを使っているのに Covid トラッカーにはプライバシーの懸念がとか言わないでよと冗談をいっていた。
Shaping Kubernetes Community Culture というセッションでは、 パンデミックでみんな疲れて review が減ったとかそれに対応するためにリリースサイクルを延ばしたとかをグラフを用いて説明していた。 後半ではダイバーシティとか injustice の話になって、コミュニティメンバーで相談して Kubernetes のサイトに BLM バナーをつけたと言っていた。そのことで何人かから嫌がらせのメッセージを送られたがそんなことは許されないと静かではあるがはっきりと言っていたのが印象的であった。無意識の人種バイアスを解消するための研修をリーダーに提供したりという活動もやっていると言っていた。
一般セッション
Protecting ourselves from CNCFgate
CNCF SIG Security, Citi, VMware の人が話している。 supply chain attack を防ぐにはといった話で、1つの製品で解決するような簡単な問題ではないと言っている。 コミュニティに、ツールの他にもどういったことを推奨するかといった情報も提供するそうである。
ソースコード、依存関係、ビルドパイプライン、アーティファクト、デプロイの5段階に分けて各段階でどうすればいいかという話を順にしていた。
ビルドパイプラインに関しては、DoD DevSecOps reference paper を読めとか、都度 immutable image を使ってシングルタスクだけ実行するようにして attack surface を減らせとか言っていた。 また、reproducible build を複数のパイプラインで実行して同じ結果になるか確認するとよいとも言っていた。 アーティファクトに関しては、アーティファクトのセキュリティを確保するために in-toto とか notary を使えと言っていた。
アーティファクトを署名して検証するためのサービスとして sigstore というものがあると言っていた。
コミュニティにサプライチェーンのテンプレートを提供したいとも言っていた。
質疑では、発表で述べた対策を全部いっぺんにやる必要はないとか deployment とバランスとってやればいいとか答えていた。 また、continuous scanning も要るとも答えていた。
From Tweet to BadIdea
Kubernetes の CRD は便利な API なので、 kube-apiserver から CRD の機能だけ持ったものを作ってみてはどうかという話である。 Kubernetes そのものだと依存関係が多すぎて大変だからとか動機を説明していた。 もともと冗談から始めたということも言っていた。
デモでは badidea repo の dependency とかコードとかを説明していた。
昨日の Keynote で話に出ていた https://github.com/kcp-dev/kcp とどうちがうのかという質問があって、ゴールは似てるのではと回答していた。 他にどんな機能を足していけばいいのかといった話をしていた。
コードは https://github.com/thetirefire/badidea にある。
Sidecars at Netflix
Netflix で sidecar container をどのように使用しているかという話である。
発表では Titus executor というものが特に断りなく出てきたが、Netflix のシステムは Kubernetes を前提として作られたものではなく、既存のシステムを virtual kubelet を駆使して Kubernetes 化したという話が San Diego でやった KubeCon で発表されていた。そういった事前知識があるとちょっとこの話がわかりやすくなる。
VM であれば普通に systemd で各種サービスを動かせるが、container で同じようなことをやろうとするには、リソース分離の観点からシステム上のサービスではだめで、container 毎にサービスを動かす必要があると言っていた。
それを実現するために tini (tiny init) とかいうものを作って container 起動時に sidecar container として動かしているようである。 VM で動かしていたような各種 service を sidecar container で動かしているようで、例えば sshd もそうやっているようである。
後半になって titus の話を少ししていた。
最後に Kubernetes での話になって、昔に mesos を使って作ったシステムを順次移行していると話していた。ここまでで説明した内容を kubernetes の上でどうやって実現するかというのが後半の話題であった。 sidecar は起動順序の保証がないので linkerd-await のようなものを使うか crash するに任せる (何回か crash して再起動すると安定状態になる) かであると言っていた。
終了時も順序保証がないのでちょっと困るとも言っていた。
KEP 753 として提案していたが、2020年10月に reject されたので違うアプローチを模索してるそうである。 use cases を集めて pre-proposal の段階だということであった。
Kubernetes Advanced Network Testing with KIND
kind (https://kind.sigs.k8s.io/) というのは Docker 内で Kubernetes クラスタを構築するもので、テストに利用されている。
docker network を複数作って kind で複数ネットワークを持つ Kubernetes クラスタを作るデモをやっていた。
次に kind で複数クラスタを立ちあげて multi-cluster とか multi-zone のテストができるという話になって、 multi-cluster だと通信のレイテンシやパケットロスもエミュレートしないといけないと言っていた。
wanem という container を使ってクラスタ間の通信を forward してるようである。 デモでは cluster 間を iperf で通信したり、wanem に入って tc コマンドで latency を設定できるとかやっていた。
質疑では、maintainer としてこれはできないというと怒る人がいるけどみんなを満足させることはできないからしょうがないじゃんなどと話していた。
There is a New Spec in Town
Pod に複数 NIC がついてるけどどれがどれかわからないからどうしたらいいのという人と答える人の2人の疑似対話形式で進むプレゼンである。 この問題は device information spec で最近解決されていて、Pod の annotation の network-status に device-info という形で NIC の情報が格納されると話している。
sriov device plugin と multus が独立に動く作りになっているので、情報のやりとりが難しいのだが、device-info-file をローカルに書いて multus がそれを読んで Pod の CNI を呼ぶといった実装になっていて、ちょっとトリッキーである。
memif とか vdpa とかいったキーワードがでてきて、 そういう NIC の情報 (capability) を伝えるのにも使えるようである。
device info は Pod 側で情報をとって処理する必要があるが、openshift/app-netutil (https://github.com/openshift/app-netutil) というライブラリが使えると言っていた。
最後にもうこんな時間だビールでも飲もうといってプレゼンが終了した。
質疑で Container orchestrated devices WG がどうこうと話していた。 この WG は GPU とか FPGA を扱っていてちょっと毛色が違うけど似た課題を扱っているとも言える。
Kubernetes Data protecting WG
アプリケーションデータと API resource のバックアップの話である。
いろいろ足りない機能があって、それを解決する KEP を順に説明するという流れの発表であった。 一例としては、PV の snapshot をとってもデータが書きこみ中だったりすると使いものにならないので、ContainerNotifier というものでアプリケーションに通知して静止状態にしてからバックアップを取る必要があるといった話をしていた。 他にも Volume Populator という名前で、バックアップから PV を作成するやり方を議論したりしているようである。
https://github.com/kubernetes/community/tree/master/wg-data-protection
まとめ
バーチャル開催であることを逆手にとったのか、 Hacking into Kubernetes Security for Beginners (https://www.youtube.com/watch?v=mLsCm9GVIQg) のように、もはや発表と言えないくらい制作に手間のかかったものもあって、見てる分には面白かった。
次回は10月にロサンゼルスと Virtual のハイブリッド形式で行われる予定である。 キーノートで、ワクチンの接種も進んでるしようやく長いトンネルの出口が見えてきて実際に会えるのを楽しみにしていると Priyanka Sharma 氏も言っていた。 ただ、ワクチン接種状況は国によって大きな違いがあるのは周知の通りであり、故郷のインドでは家族が亡くなっているという話もしていたように思う。 10月に国境を越えてロサンゼルスに行くのは基本的に難しいだろうし、次回については日本に住む身としては選びようがなさそうであるが、主催者は困難を乗りこえてリアル開催に向けて努力しているという印象を受けた。
