ハクソク

世界を動かす技術を、日本語で。

新世代のTailscaleアクセス制御

361日前原文(tailscale.com)

概要

Tailscale は新しいアクセス制御方式「 grants」の一般提供を発表。 grants は従来のACLよりも簡単に書けて読みやすい上位互換。 ネットワーク制御とアプリケーション権限を 一元管理 可能。 従来のACLも引き続き利用可能で、両者の 共存 が可能。 新機能や移行方法についても柔軟に対応可能。

Tailscaleの新しいアクセス制御「grants」概要

  • grants は従来の ACL（Access Control List） を拡張したアクセス制御方式
  • すべてのACL設定は grant で表現可能、両者の 共存 もサポート
  • 人間にも機械にも読み書きしやすい シンプルな構文設計
    • ポートやプロトコルを ipフィールド に統合
    • actionフィールド の削除による簡素化
  • ACLからの移行が不要、 既存ポリシーはそのまま運用可能

grantsによる新機能と拡張性

  • アプリケーション権限 の拡張
    • Layer 3のネットワーク制御だけでなく、 アプリケーション認可 も一元管理
    • Goライブラリ tsnet でTailscaleをアプリに直接組込むことで、ユーザー認証と権限付与を実現
    • 権限情報は JSON形式 で柔軟に定義可能、独自スキーマの利用も自由
  • Golink などの社内ツールでの利用例
    • Tailscale IDで認証し、grantでユーザーごとに ロール付与 を実現
    • ネットワーク制御とアプリケーション認可をTailscaleで一元管理
    • アプリ側でユーザーDBを持つ必要がなく、 運用負荷軽減
  • 他のOSSツールでの実装例
    • TailSQL: tailnet内のプライベートSQLプレイグラウンド
    • Setec: 機密管理サービス
    • Kubernetes API server proxy: Kubernetesコントロールプレーンへのアクセス管理

viaフィールドによるルーティング制御

  • viaフィールド 追加により、出口ノードやサブネットルーター、アプリコネクタ経由のアクセスを柔軟に指定可能
    • 例：オフィスごとに異なる出口ノードを指定
    • タグ付けされたノードやリージョナルルーティング、高可用性構成でのフェイルオーバーもサポート

既存ポリシーとの互換性と移行

  • 既存のACLポリシーはそのまま利用可能
    • 強制的な移行や期限、非推奨化はなし
    • grants と ACL は同一ポリシー内で併用可能
    • 新機能を利用したい場合のみ、 段階的な移行 が可能
  • 詳細な移行ガイドも提供

Tailscaleのgrants は、ネットワークとアプリケーションのアクセス制御を統合し、柔軟かつ将来性のある管理体制を実現。 既存の環境を壊すことなく、 スムーズな拡張 と 運用の簡素化 を両立。

Hackerたちの意見

新しい構文を使うために、いつ既存のポリシーを更新しなきゃいけないの？… 既存のルールを新しいグラント構文に更新する必要は全くないよ。元のACL構文は永遠にサポートするからね。… Tailscaleが安定したプラットフォームだって言うとき、本気だからね。いいビジネス判断だと思う。Headscaleへの反応を見て、Tailscaleが開発者コミュニティとどう接しているか、そしてその人気が続く理由を思い出すよ。

└

Headscaleに対してどう反応したの？発表を見逃しちゃったかも。

└

これ（そして、それがグラントと一緒に使えるってこと）は、もし古い設定があれば、リアルタイムで新しいフォーマットに変換してるってことだと思う。そうじゃなかったら、メンテナンスモードで二つのものを動かして、両方が効果を持って衝突しないようにするのは、かなり大胆だよね。「永遠に」って約束するのは。でも、一度だけ変換する方がいい理由がよく分からないな。それでもユーザーが心配する必要はないけど、古いやり方は終わりにできるし。

最初のグラント例にカンマが抜けてる気がするんだけど、気のせいかな？dst行の最後にね。実際、ネストされたオブジェクトの最後の要素のカンマの使い方が不一致な気がする。公平に言うと、JSONのルールもあんまり覚えてないから、ちょっと調べる必要があるな。

└

うん、カンマが抜けてる例は間違ってると思う。彼らのJSONパーサーについて間違ってなければね。JSON5を使ってると思うけど、最後のオプショナルカンマはOKだよ。オプショナルカンマやコメントが許可されてるからね。

└

彼らはhujsonを使ってるよ: https://github.com/tailscale/hujson でも、中間のカンマを省略した例みたいなのは受け付けないんだよね。例えば、{ "foo": 42 "bar": 123 } みたいなやつ。 > hujson: line 3, column 5: object valueの後に無効な文字'"'があるよ（','か'}'を期待してる）。

なんとなく関連してるけど、tailscale sshを使ってるユーザーのメールアドレスやユーザー名に簡単にアクセスする方法ってまだないよね？これがTeleportの良かったところで、特別な設定なしで共有マシンのgitコミットを適切に属性付けできたんだよね。

これを、keycloakみたいなIDPにリンクするようなより一般的な解決策の代わりに使いたいのはいつ？ネットワークレベルでのブロックができるのは利点だけど、アプリケーション自体を変更する必要があるのはIDPに接続するのと同じだよね？このアプローチの欠点は、エンドユーザーがtailnetにいる内部アクセスにしか使えないことだね。

└

ネットワークレベルでの話だよ。クライアントがネットワーク上の宛先に接続するのをブロックするから、宛先のアプリケーションを変更する必要はないよ。

└

内部アプリを書くなら、これの方がサポートしやすいよ。リダイレクト、セッション、クッキー、ユーザーとその役割をTSとKeycloakで同期させたり、二つの別々のポリシーファイルを維持したり、そんなことを考えなくていいからね。

└

いつ、KeycloakみたいなIDPにリンクするようなもっと一般的な解決策よりもこれが欲しいの？ Tailscaleを使ってる人は「シンプルなコードと管理」を選んでると思うんだけど、「NATを突き破ってWireguardトンネリングを自分で扱う」ってのは選ばないよね。その観点から見ると、「アイデンティティ管理」はTailscaleが最初に手助けしてくれる「もの」の一部なんだから、なんでそれを「アイデンティティ管理」の解決策として使わないの？ tailscale serveを使うと、Tailscale-User-Login、Tailscale-User-Name、Tailscale-User-Profile-Picのヘッダーが得られて、誰がTailscaleエンドポイントを通じて接続したかが分かるよ。 https://tailscale.com/kb/1312/serve#identity-headers それとは別に、最初から公開されているOpenID Connectサービスがあれば、それをTailscaleのtailnet認証SSOとして使えるよ: https://tailscale.com/kb/1240/sso-custom-oidc

ACLやグラントの話が出たついでに、Tailnet Lock[0]がそれにも対応してくれたらいいのに。つまり、もしコーディネーションサーバーやノードの一つが侵害された場合でも、攻撃者がポリシーファイルを変更して、侵害されたノードから私のtailnet内の任意のサービスにアクセスできないように、tailnetポリシーファイルに署名できるようにしてほしいな。最悪の場合、SSH[1]も含めてね。[0]: https://tailscale.com/kb/1226/tailnet-lock [1]: https://tailscale.com/kb/1193/tailscale-ssh

最近、SaaSの支出を見直してたら、Tailscaleが今一番の支出になってることに気づいた。彼らのアプローチはどうやらうまくいってるみたいだね。

Linux上のTailscaleは、驚きの設定やnetfilterルールの混乱だよ。誰にでも合うわけじゃないけど、netfilterテーブルをコントロールしたいなら、確かに向いてないね。

└

バニラのiptablesを使うなら、ずっと理にかなってるよ。それに、少なくともDockerよりはずっと整理されてる。

└

最近、Calicoがこうやって動いてるって知ったんだけど、うまくいかないと本当に驚くことがあるよね。少なくともk8sの文脈では、デバッグしようとするよりも、ノードを焼き捨てて再スタートする選択肢があるからまだマシかな。

でも、いつになったら一度に複数のtailnetに接続できて、スリープから復帰した後にtail scaleが自動で再接続できるようになるの？ それがユーザーが本当に気にしてるクオリティ・オブ・ライフの部分なんだよね。

Tailscaleに「パラノイドモード」を作ってほしいな。今のところ、Tailnet Lockを使えば、新しいマシンを信頼できるノードから承認しないとネットワークに追加できないから、Tailscaleが勝手にマシンを追加することはないって安心できる。これは、基本的にネットワークにバックドアがある競合他社と比べると素晴らしい機能だよね。でも、ACLの変更やその他の多くの変更は、ホストからの承認なしにWebUIからできちゃうんだ。だから、UIで変更を承認しなきゃいけないけど、Tailscaleは本当に私の同意なしにそれをやってしまうこともできる。信頼できるノードから詳細な変更内容を伴って、Tailscaleネットワークの_どんな_変更も承認が必要なモードがあったらいいな。そうすれば、Tailscaleが私のネットワークをいじることができないって確信できるから。もちろん、Headscaleを使ってTailscaleのサーバーなしで完全に運用することもできるけど、この中央サービスを管理しなくて済むために、少額の月額料金を払う方が好きなんだ。