About this page
- AWSのLambdaとFargateで採用のFirecrackerについて解説する、以下論文を読んだ際のメモです
- コンテナ基盤のマルチテナント設計やセキュリティ設計について有益な説明が多かったのでその観点でメモを残しておきます
Multi Tenancy Capabilities の定義
- 特性の異なる複数のワークロードを1つの基盤上で同時に実行すること/それを可能にする能力
Multi Tenancyを検討する際の2つのisolation課題
Security上のisolation課題
- あるワークロードの中で、権限昇格(privilege escalation)などの攻撃が実行された際に、その影響が他のWorkloadに波及することを防ぐことは可能か？
Performance上のisolation課題
- 実行されるワークロードのPerformanceが "isolated from neighbor" される状態を実現することは可能か ( noisy neighbor 問題)
- リソース競合(Resource contention)が発生してしまうと、この条件が満たせない。そのため、収容性やSchedulingの話になることが多い印象?
Isolation課題の解として選択可能なオプション群
- Virtual Machine
- ホストOSのKernelとは別個にKernelを起動する方式
- Host/Guest間でKernelがisolateされているためprivelege escalationなどに強い？その分コンテナと比べるとオーバーヘッドやリソースの使用効率に課題
- i.e. QEMU+KVM
- Container
- ホストOSのKernelを複数のワークロードが共有する方式
- VirtualのMachineの逆で、privelege escalationに弱いが、オーバーヘッドやリソースの使用効率に優れる
- i.e. Docker, LXC
- language specific virtual machine
Container technologyのSecurity ModelにおけるSecurityとCompatibilityのトレードオフ
- コンテナ型仮想化は、ホストOSのKernelを共有するため、Privilege Escalationなどの攻撃に脆弱という課題がある
- そのような攻撃にセキュリティ対策をつけるために、コンテナ上で実行されるsyscallに対し、「実行可能なsyscallを制限する」という機構をseccomp bpfで実装している
※元論文のFigure 1を元に作成
- しかしここには、SecurityとCompatibilityのトレードオフ関係が存在する
- 非コンテナのLinuxOS上で実行可能なコードを、コンテナ上でもできる限り互換的に動かそうとすると沢山のsyscallについて実行の許可を出す必要がある
- しかしながら、セキュリティの観点で考えると実行可能なsyscallはできるだけ減らしたい
Firecracker
- KVMのbackendで動作するVMM、Linux上で動作させる前提で設計
- REST形式のconfiguration用のAPI endpointを保持
- 軽量なmiaro vmがコンセプトなので、ディスクIOやprocess schedulingなどの機能についてはホストOSの機能をそのまま使う。一方、ディスク、シリアルコンソール、ネットワークについてはデバイスエミュレーションを行う
- 実装はgoogleのcrosvmが元になっている
参考文献
https://tech.gunosy.io/entry/read-firecracker
