Weekly Selection 2021-01-22

しばらく記事を書き溜めて毎週だしてみる.

Service Meshを紹介する動画

NCSA HTTPd

NCSA HTTPdは世界で二番目のHTTPサーバ.一番目はCERN httpd.

NCSA_HTTPd – Wikipedia

Awesome Storage

分散ファイルシステム(DFS)のことを調べていたら発見.特にCeph, GlusterはKubernetesクラスタのストレージとして検討してみたい.同様の役割としてDRBDがあるが,DRBDはスケーラビリティに課題があるそう.

Awesome Storage – GitHub

SameParty Cookie

TwitterのIntent To Shipを眺めていたら発見した.Prototypeがリリースされるとのこと.以下のリンクのMotivationに導入の背景が説明されていた.

Motivation

In order to increase privacy on the web, browser vendors are either planning or already shipping restrictions on cross-site tracking, such as phasing out third-party cookies. Third-party cookies are currently defined as those associated with a site that is different from the site of the top-level page. However, modern websites are typically served over multiple domains/sites, many of which are owned by the same organization. First-Party Sets provides a mechanism to group domains/sites belonging to the same organization as being same-party with each other, and thus defines a privacy boundary for websites.

出典 https://groups.google.com/a/chromium.org/g/blink-dev/c/-unZxHbw8Pc/m/_23CsOkHAQAJ

日本語で書かれた資料はyukiさんが書かれた以下の記事が分かりやすい.

PHPとRubyとPythonのデータ構造改善

辞書(連想配列)の内部実装が変更された話.Pythonは辞書の順序が変更されたのと同じタイミングだった.

HTTPのバージョン

RFCとHTTPバージョンを整理した図が素晴らしい!

HTTPのバージョンについて、現在のまとめ – Qiita

YAMLのフォーマット

YAMLでは文字列をダブルクオートまたはシングルクオートで囲まないと,意図しない動作をすることが知れた.JSONのほうがStrictではあるが楽になりそう.YAMLパーサーの実装によって,扱いに違いが生じてきそうで怖い.

AWSが生まれたきっかけ

Sunのサーバによるコストを削減するためにHP/Linuxのサーバに乗り換える挑戦をした.大きな賭けが結果的に,大きなコスト削減の成果を生んだ.

AWSが生まれたのは、Amazonが経費削減のためにSunのサーバからHP/Linuxサーバへ切り替えたことがきっかけ。当時の社員が振り返る - Publickey

論文メモ「Firecracker: Lightweight Virtualization for Serverless Applications」

AWSのLambdaの裏側で動いているマイクロVMの論文を読んでみた.
4章はAWSでのLambdaの動作を知るには有益なので読んでみるとGoodかも.

URL) https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

最初のLambdaではLinux Containerを使っていたのが意外だ.
顧客アカウント単位で単一のVM内で複数の関数を実行していたのか.

When we first built AWS Lambda, we chose to use Linuxcontainers to isolate functions, and virtualization to isolatebetween customer accounts. In other words, multiple func-tions for the same customer would run inside a single VM,but workloads for different customers always run in differentVMs.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

AWSにおいて重要だったポイントは「density (密集度)」と「overhead (オーバヘッド)」の2つ
ねらい(たぶん)→関数が起動するまでの時間の削減,マルチテナンシー(収容率)の向上

Two key, and related, challenges of virtualization are density and overhead

出典) Firecracker: Lightweight Virtualization for Serverless Applications

QEMUの複雑さがエグい… 140万行のコードと270のシステムコール…

To illustrate this complexity, the popular combination of Linux Kernel Virtual Machine [29] (KVM) and QEMU clearly illustrates the complexity. QEMU contains>1.4million lines of code, and can require up to 270 unique syscalls [57] (more than any other package on Ubuntu Linux15.04). The KVM code in Linux adds another 120,000 lines. The NEMU [24] project aims to cut down QEMU by removing unused features, but appears to be inactive.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Rustで書いて96%のコード量をQEMUに比べて削減… 

Firecracker’s approach to these problems is to use KVM(for reasons we discuss in section 3), but replace the VMM with a minimal implementation written in a safe language. Minimizing the feature set of the VMM helps reduce surface area, and controls the size of the TCB. Firecracker contains approximately 50k lines of Rust code (96%fewer lines than QEMU), including multiple levels of automated tests, and auto-generated bindings. Intel Cloud Hypervisor [25] takes a similar approach, (and indeed shares much code with Fire-cracker), while NEMU [24] aims to address these problems by cutting down QEMU.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Lambdaの関数実行環境はコロコロ変わるけれど,コードの読み込みとコードの移動にかかるコストを抑えるために関数実行環境をSticky(2回目以降は1回目を使う)に割り当てるのか !!

The execution of the customer code happens on the Lambda worker fleet, but to improve cache locality, enable connection re-use and amortize the costs of moving and loading customer code, events for a single function are sticky-routed to as few workers as possible.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

SSO ProxyとZero Trust ProxyとSSO Proxyが分からない

これらの違いが分からない.

  • Zero Trust Proxy
  • Identity Aware Proxy
  • Single Sign On Proxy

具体的なソフトウェア名はわかる.

  • (製品) Google Cloud IAP → IAP
  • Pomerium → IAP
  • OAuth2-Proxy→SSO Proxy
  • BuzzFeed SSO→SSO Proxy

検索してみた.わからない.Zero Trust Proxyの実装のひとつがIdentity Aware Proxyなのだろうか.では従来のSSO Proxyとは何が違うのだろうか.

特に「ID認識型プロキシ(Identity Aware Proxy)」と呼ばれる仕組みを中心に据え、認証・認可を強化している。これは、アプリケーションやユーザーの場所を問わず、無理のない方法でアクセスさせる仕組みだ。アカマイのID認識型プロキシは、EAA(Enterprise Application Access)という製品として顧客にもサービスを提供している。

解説「ゼロトラスト」シフト:脱“境界セキュリティ”が進む2つの動き https://japan.zdnet.com/article/35134505/ より

CNCF Landscapeを見たが分からない.Pomerium, BuzzFeed SSO, OAuth2 Proxyあたりが該当するが違いについて触れられていない.

CNCF Landscape https://landscape.cncf.io/ より

Google Cloudの説明を見てみる.これによるとAuthNに加えてAuthZが詳細に行えるように見える.Role Based Access Controlが従来のSSO Proxyよりも細かく行えるということだろうか?

Cloud IAP 使用時の App Engine へのリクエストパスの図
Identity-Aware Proxy の概要 https://cloud.google.com/iap/docs/concepts-overview より

やはりよくわからなかった.有識者各位もし補足や答えを知っていれば教えて下さい.


余談:

感想「SREがセキュアなWebシステムを構築、維持するためにやれることはなにか」

mixiの清水さんがSRE NEXT 2020で発表されていたスライドを見て感じたことをメモする.

ログの扱い

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system 49 ページより引用
  • ログに認証情報や個人情報をはじめとする機密情報を出力しない.
  • ログを大量に出力するとコスト(お金)に影響が生じる.

koyamaの脳内

  • 役立つログを適切な粒度で出力するよう適切な設定が必要になりそう.
  • この粒度を適切に決めるのは,熟練したソフトウェア開発者しか出来ないのでは?
  • 複数メンバーが参加するソフトウェアプロジェクトで認識を統一するのは難しい.
  • 開発用のデバッグログもプロダクションで出力すると機密情報になるので,動作モードによって出力するログも制御すべきということかな.
  • 開発環境→トークンをログに表示
  • 本番環境→トークンをログに非表示

デフォルト設定を使わない

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system 67 ページより引用

koyamaの脳内

  • デフォルトVPCとセキュリティグループを使わないことをプラクティスにするのはイマイチな気がした.
  • 全利用者にセキュアな状態をデフォルトで提供するために,明示的な指定を利用者に求めればいいのに.
  • 利用者が簡単に使えること,デフォルトでセキュアな状態が作られることを両立してほしいな.
  • AWSはクラウド事業者なので,簡単に使えることを優先しているのではないか?と思った.

draft-ietf-httpbis-cacheを眺めてみた[執筆途中]

IETFのメーリングリストを眺めていたら,httpbis-cacheのdraftの議論があったので眺めてみました.既存のRFC 7234からの変更点(Change Log)で気になったものピックアップしてみました.

この記事では,draft-ietf-httpbis-cache-08の段階での情報を書いています.今後の動向は最新のDraftを確認してください.

C.4. Since draft-ietf-httpbis-cache-02

Warningヘッダの非推奨

In Section 5.5, deprecated “Warning” header field
(https://github.com/httpwg/http-core/issues/139)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

個人的には,こんなヘッダがあることに驚きです.MDNによるとレスポンスヘッダに状況の説明として含めることが想定されているそうです.ヘッダの構造は以下で定義されています.

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]

C.5. Since draft-ietf-httpbis-cache-03

リクエストヘッダのキャッシュ制御を削除

Remove requirements around cache request directives
(https://github.com/httpwg/http-core/issues/129)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先のGitHubでも書かれているとおり,リクエストヘッダのキャッシュ制御ヘッダがブラウザやWebサーバ,CDNで無視されている状況から取り除くことになったそうです.

Pragmaヘッダの非推奨

Deprecate Pragma (<https://github.com/httpwg/http-core/issues/140>)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

HTTP/1.1ではCache-Controlヘッダが同様の働きをするので非推奨になったようです.

C.7. Since draft-ietf-httpbis-cache-05

キャッシュ可能メソッドのコンセプトを削除

In Section 3, remove concept of “cacheable methods” in favor of prose (https://github.com/httpwg/http-core/issues/54, https://www.rfc-editor.org/errata/eid5300)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先の表には,メソッドごとにSafe(安全性), Idempotent(冪等性)の2カラムが存在します.Safeはリクエストのメソッドがリソースの読み取り専用であるか(変更を伴うか)を表しています.Idempotentは,同時に同一のリクエストが複数あった場合と1つあった場合で影響が同一であることを表しています.

MethodSafeIdempotentReference
CONNECTnonoSection 7.3.6
DELETEnoyesSection 7.3.5
GETyesyesSection 7.3.1
HEADyesyesSection 7.3.2
OPTIONSyesyesSection 7.3.7
POSTnonoSection 7.3.3
PUTnoyesSection 7.3.4
TRACEyesyesSection 7.3.8
Table 8
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.7.2

7.2ではSafeとIdempotent, Cacheについて触れられているものの,表にはSafeとIdempotentの2つのみ記載がありCacheは省略されていました.以下がGitHubのPull Requestです.

Get rid of “cacheable methods” by mnot · Pull Request #229 · httpwg/http-core

クオートで囲まれたキャッシュ制御ディレクティブの扱い

Change requirements for handling different forms of cache directives in Section 5.2 (https://github.com/httpwg/http-core/issues/128)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.8. Since draft-ietf-httpbis-cache-06

Varyディレクティブが * の場合キャッシュを無効化

In Section 4.1, clarify that any “*” as a member of Vary will disable caching (https://github.com/httpwg/http-core/issues/286)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.9. Since draft-ietf-httpbis-cache-07

明確: 他のキャッシュ要件を無視

In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these directives do not ignore other requirements for caching (https://github.com/httpwg/http-core/issues/320)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中