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

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

Blink: Intent to Prototype: SameParty cookie attribute https://t.co/Hn1KwJ1W0z

— Intent To Ship (@intenttoship) January 15, 2021

日本語で書かれた資料は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

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

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

• 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あたりが該当するが違いについて触れられていない．

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

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

---

余談:

VPNレスにするとしてSSH + SocksプロキシがGUIでできれば良いのではないか!?

— Coyama (@tmyk_kym) January 5, 2021

GoogleのIAPはover HTTPSでTCP接続できるよという話で便利だとは思うのだけど、ほかのIAPではできない気がするんだよね。

— Coyama (@tmyk_kym) January 5, 2021

SSOの悩みは個々のアプリ上のロールとSSO Proxyのアカウントをマッピングする事なんですよね〜

— Coyama (@tmyk_kym) January 5, 2021

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

ログの扱い

• ログに認証情報や個人情報をはじめとする機密情報を出力しない．
• ログを大量に出力するとコスト(お金)に影響が生じる．

koyamaの脳内

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

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

koyamaの脳内

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