2022-11
Neco プロジェクトありがとうシリーズ
BIRD の設定を書きまくったので--auto-direct-node-routesを切ることができた 意味はない
https://scrapbox.io/files/6385ea4ddfe8dd001d917901.png
ファイアウォールが厳しくなって色々が壊れているらしい，感動
「ファイアウォール設定: 低」がなくなったことのマイグレーションに失敗した？
(おそらく)全部 Sercomm に投げてるせいでサポートができることが何もなくて「とりあえず ONU を再起動してみてください」「ファームウェアのアップデートを試してみてください」しか言えないのが悲しみに拍車をかけている ラックマウントサーバーの同一ラック内の通信ってどうやるんだろうと思ったら全部 ToR スイッチが処理するらしくて完全に納得した
現代的な構成(CLOS ネットワーク)では ToR スイッチは L3 スイッチなので ToR に対して BGP で経路広告するみたいな話が出てくる 2022-11-27 くらいに「そういや Cilium の --auto-direct-node-routesを切ったらどうなるんだろう？」と思って実行し，クラスタを破壊したままにしていたのだが，戻した --auto-direct-node-routesは同一 L2 セグメントのノードと通信をするためのルーティングの設定を Cilium に自動で行わせるフラグ 他ノードのpodCIDRとnodeIPに対してnodeIPが同一 L2 セグメントに存在するならルーティングテーブルに直接{{podCIDR}} via {{nodeIP}}みたいなルートを書き込むみたいな挙動
この設定を行うことで，L2 セグメント内においてはノードを跨いだポッド間通信が実現される
……のだが，(オタクなので)「じゃあ別セグメントならどうなるの？」と考えてしまう
別セグメントにある(fyi. ネットワーク(旧))デスクトップ PC に仮想マシンを立てて一時的にノードにして遊びたくなったりとか VPS 上にノードを立てたくなったりとか
L3 のトンネリングを使うと別セグメントになる
これはクラスタのネットワークを利用するので L3 での接続になる
より切実な問題として，IPv6 アドレスはインターネットに接続するときに NAPT しない構成になっているので，ルータから戻ってくるときにルータがノードに直接投げられるようになっていないと困る 何をやっても証明書関連をいじることになっている
クラスタ認証 続き
有用そうな事例を見つけた
GCP のサービスアカウントは証明書付きの公開鍵をアップロードすることで自前の鍵を使って署名したトークンが使える サービスアカウントに GKE へのアクセス権を与えればクラスタアクセスができる gcp auth provider をつかう
YubiKey で署名をするのはアリなのではという気はしている，問題はどのようにして署名を与え，どのようにして RBAC と結びつけるかなのだが…… Kubernetes クラスタに対して machine auth を提供する方法，よくわかっていなかったのだが実はServiceAccountに対応する JWT を生成できるらしいのでこれを外部の OIDC Issuer が生成した ID Token と交換する機構を作ることでできるらしい これは Workflow Identity Federation みたいなやつで，Auth key 的なもっと単純なやつが欲しい場合は静的トークン認証とかを用意するとよいはず
よく考えると，Workflow Identity Federation の正当性を保証するのは DNS の管理者権限をtosuke.iconが持っていること
正しくはhttps://${ISSUER}/.well-known/openid-configurationを管理できることだが
しかし DNS の管理権であるところの Cloudflare の API Token をExternalSecretとして持ってしまっている 循環参照が生じてないか？という疑問がある
DNS の管理を奪取できると Secret を全部取り出すことができてしまうが，そこから何ができるのか？という問題もあったりはする
やばいのはそうなのだが
それを言ってしまうとクラスタアクセスの正当性も id.tosuke.me を持っていることに依存していてよくない気もしてきた
クラスタ認証の自分のグループの持つ権限が強すぎるのでデフォルトで持つ権限を小さくしておき，YubiKey を使った認証を経ないと強い権限が使えないようにしたい ……したいのだが，Kubernetes の認証機構は(クライアント証明書認証を除いて)トークンベースなので，こちらから送るトークンを変えないといけない 認証機構の制約上 OIDC Issuer は1つしか使えないので，どうしようといった状態 だめだった
妥協策として system:masters グループへの偽装権を与えるがデフォルトの権限は小さくしておくというのも考えられなくはない
事故は防げる
偽装権があること自体は kubectl を叩ける存在ならわかってしまうのでどこまで安全なのかはわからん
impersonate できるグループを制約していたとしていたとしてそもそもそれは公開されている
逆に公開しなかった場合設定を忘れて何もできなくなる可能性が高い
Flux CD，v1 の印象しかなくてナメてたけど v2 がけっこういい感じで株が上がっている 今まではクライアント証明書の検証を kube-apiserver が行う必要があったため， SNI を見て TLS をパススルーすることで公開していたが，OIDC では単純に HTTP をプロキシすればいいので単純に公開できるように control plane は1台しかなく，外部からの過度なアクセスに対して脆弱なため
できるようになったこと
JWT の検証を分散することもできる (やってない) 結局これは Traefik のワイルドカード証明書周りの変な挙動に引っ掛かって使うハメになった(一敗) ちゃんと更新が伝搬されていないというか，使えそうな証明書があったらマニフェストの記述を無視して使ってしまっている気がするのだが，どうなっているのだろうか
そこまで新しいサブドメインを使う機会があるかと言えば無いので，最悪毎回 Traefik の Pod を殺して回ればいいのではあるが…… netgo の *nix における DNS 実装は/etc/resolv.conf だけを読んで動くらしいが，macOS は resolv.conf に書いてあるのとは全然違う名前解決をすることがあるので，netgo を使わずに libc の getaddrinfo を呼んでほしい netgo が活きるのは libc すら入れたくない / ポータビリティを損う場合なので，そうでもないならやめろといった気持ち
brew で配布されてるパッケージがこの状態でビルドされていてキレた
GitHub Actions とかでまとめてビルドされてるとかならまあわからなくもないけど……
dex，かなり気に入ったのでお安く外部の環境にデプロイしたい，のだが ストレージがあんまり良さげなものがない
とりあえず自分にだけ権限を与えた(無意味)
昨今の流行りであるゼロトラストとは別の方向に，スケール可能な VPN を提供するサービス
WireGuard で接続が暗号化されているのだし接続元ユーザもわかっているのだから SSH の公開鍵認証はいらないよね？(tailscale SSH) みたいなことをやっていて面白い /config/scripts/firstboot.dに service を配置するシェルスクリプトを置いておけばいい，なるほどね
複数のサービスに対して異なるポリシーを適用した認証を用意したいが，oauth2-proxy を複数デプロイするのはやりたくない，といった状態