2023-06
jq があることを前提にしたスクリプトを書いていたら，VyOS に jq がなくて全てが破滅してやる気を失った 各ノードがメタデータを安全に取得できる API が欲しい！→ノードが「それ」であることを検証する仕組みが……と思っていたが，node attestation って呼ぶらしい
ACME HTTP01 とかを使ってネットワーク上での関係性を検証するとかしか見えないが，どうすればいいんだろうか 全部自動である必要はない(Approve を手作業でやるのは普通に許容できる)のだが，無意味なリクエストを送りまくれるのは MFA 疲労攻撃みたいなのが通ってしまうのでよろしくない気がする
知った
複雑で大量のリソースを使う仕組みを使って署名の鍵管理を簡単にしたとしても何を署名してるのかを意識しないと何の意味もないのだよなあ
現代的な，/home/user 以下をユーザーパスワードとマシン固有の鍵を用いて暗号化するような構成において，osxkeychain のような特定ユーザーからのアクセスかどうかを見て動作する仕組みに意味はあるのか? まあこの仕組みはユーザーディレクトリがログインされてない状態だと見えないだけでユーザーからのアクセスであるかは判別してないんで意味はあるのかもしれないが
無いよりはマシか
クラウドにあるみたいな Metadata API があればクラスタ構築の自動化で楽をできそうという気持ちになった
Controller ロールを持つホストは CA の秘密鍵や SA の OIDC ID Token を署名するための秘密鍵を持っている必要があるがこれを配る機構が必要であり……という問題
dex 真面目にやるか……と思ったがだめな理由が色々あるのだった (GitHub connector を使うと)groups claim が空のトークンも発行できてしまう DDoS で kube-apiserver が死んでしまう！
と思ったが別にこのレイヤーの問題では無い気もする
これを解決するにはポリシーを埋め込む必要があるがパッチが重い
このクライアントのトークンを発行するにはほげほげといったポリシーが必要
あるいは認証プロキシを前段に置く
接続先の真正性の担保のために
やはり自作？
Namespaced な顔をするために Envoy のリソース名を Qualified しようとしているがやりきれていなかったりする 最悪な例: spec.services.listenerはspec.resourcesのlistenerのnameを指定するのかと思いきや qualified された名前を入れる必要がある
無理すぎ
最悪ではないがまあ悪い: spec.servicesやspec.backendServicesは EDS API を通じて Cluster とマップされるが，このときのnameは <namespace>/<svc name>の形になっている必要がある
Namespaced とはいったい？？？
当然のように cluster unique であることを要求される，意味がわからん
これはどうなったのかわからんが思い出として，Service IP への接続は曲げるが Service Endpoint はそのままなのでたまに異常な挙動をするというのがある
たぶんそのままな気がしている