グラントの例

単純なものから複雑なものまで、実践的なグラント構成例集

最終検証日：2026年1月5日
翻訳: 竹洞 陽一郎

グラントは、tailnetポリシーファイルでアクセス制御ルールを定義する、最新の方法です。
グラントは、より柔軟で機能豊富な構文で、従来のACL形式を置き換えます。

このトピックでは、Tailscaleのtailnetポリシー向けのグラントの例を、単純なものから複雑なものへと順に、包括的にまとめています。
各例には、背景情報、完全な構成（メモまたは完全なtailnetポリシーファイルとして）、そして実装上の注意点が含まれており、自身の環境で同様のパターンを適用する方法を理解する助けとなります。

すべて許可する

この例は、Tailscaleネットワーク（tailnetと呼ばれます）における、最も許可的なデフォルトポリシーを示しています。
小規模なチームや、すべてのデバイスが自由に通信すべき個人のtailnetなど、信頼できる環境で最小限の制限を望む場合に使用します。
この例は、より制限の厳しいポリシーを実装する前の出発点として、よく使われます。

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、3つの主要パラメーターすべてにワイルドカードを使用しています。
送信元（src）のワイルドカードは、任意のデバイスまたはユーザーが接続を開始できるようにします。
宛先（dst）のワイルドカードは、tailnet内の任意のデバイスへの接続を許可します。
IPプロトコル（ip）のワイルドカードは、任意のポートでのTCP、UDP、ICMPを含む、あらゆる種類のトラフィックを許可します。

この許可的なポリシーであっても、別のtailnetから共有されたデバイスは、自分のtailnet内のデバイスにアクセスできません。
共有デバイスは、自分のtailnetからの受信接続にのみ応答でき、接続を開始することはできません。

ユーザーに自分自身のデバイスへのアクセスを許可する

この例は、オートグループを使って、自己アクセスを維持しながら、基本的な形のユーザー分離を実装します。
ユーザーがリモートワークステーション、サーバー、その他の個人リソースに引き続きアクセスできるようにしながら、最小権限の原則を実装するための、優れた出発点です。
このアプローチは、ユーザー間のデータ分離が重要な組織に適しています。

{
  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

autogroup:memberの送信元は、tailnet内の認証済みユーザーすべてを表し、autogroup:selfは、接続元のユーザーが所有するデバイスを動的に参照します。
これにより、完全な自己アクセスを維持しながら、ユーザー間の自然な分離が生まれます。
これらのオートグループはTailscaleに組み込まれているため、カスタムグループを作成する必要はありません。

この例は、ユーザーデバイス間の横方向の移動を防ぎますが、共有リソースに関するルールは定めていません。
ファイルサーバーのような共通リソースへのアクセスを許可するには、適切なタグやグループを使った追加のグラントを設ける必要があります。
また、この例では、Tailscaleの共有を通じて明示的に招待されている場合、ユーザーが他のユーザーのデバイスにアクセスすることを防ぐわけではありません。

Exit Nodeの使用を許可する

この例は、オートグループを使って、ユーザーがtailnet内のExit Node経由でインターネットトラフィックをルーティングできるようにします。
これは、地域制限のあるコンテンツへのアクセス、信頼できないtailnet上でのトラフィック保護、一貫した送信元IPアドレスの維持に特に役立ちます。
Exit Nodeは、専用サーバー、クラウドインスタンス、あるいは十分な帯域幅を持つ個人用デバイス（Apple TVなど）に構成できます。

{
  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["autogroup:internet"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

autogroup:memberの送信元は、tailnet内のすべての認証済みユーザーがExit Nodeを使用できるようにします。
autogroup:internetの宛先は、tailnet外の、あらゆる可能なインターネット上の宛先を表します。
ワイルドカードのIPプロトコルは、あらゆる種類のトラフィックがExit Node経由でルーティングされることを許可します。

この例が効果を発揮するには、tailnet内に少なくとも1台、Exit Nodeとして構成されたデバイスが必要です。
このグラントは、ルーティングの関係を許可するだけであり、Tailscale管理コンソールまたはデバイスの構成を通じて、Exit Nodeを別途構成・承認する必要があります。
また、Exit Nodeを使用するには、ユーザーがTailscaleクライアントの設定でExit Nodeを選択する必要もあります。

タグを使って用途に基づいて許可する

この例は、アプリケーションコンポーネント間の通信境界を強制し、各ティアが隣接するティアとのみ通信できるようにします。
アプリケーション層間のトラフィックの流れを厳密に制御したい、ゼロトラストアーキテクチャを実装するのに理想的です。
このアプローチは、フロントエンド、バックエンド、データベースのコンポーネントを持つWebサービスのような、マルチティアアプリケーションでよく使用されます。

{
  "grants": [
    {
      "src": ["tag:frontend"],
      "dst": ["tag:backend"],
      "ip": ["*"]
    },
    {
      "src": ["tag:backend"],
      "dst": ["tag:logging"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

最初のグラントは、frontendタグの付いたデバイスが、backendタグの付いたデバイスと通信できるようにします。
2つ目のグラントは、backendデバイスがloggingサービスと通信できるようにします。
これにより、意図したアプリケーションアーキテクチャに沿った、方向性のあるトラフィックの流れが生まれ、デバイスが中間層を迂回することを防ぎます。

この例を実装するには、tailnetポリシーファイルのtagOwnersセクションでタグを定義し、誰がこれらのタグをデバイスに割り当てられるかを制御する必要があります。
また、各デバイスに、その適切な役割を表すタグを明示的に付ける必要があります。

グループごとに異なる環境へのアクセスを許可する

この例は、ポート制限付きのグループベースのアクセス制御を実装します。
異なるチームがアクセスする必要があるものの、権限レベルが異なる共有リソース（社内ツールなど）がある場合によく使用されます。
このアプローチにより、各グループがどのプロトコルとポートを使用できるかを正確に制御でき、アクセスのしやすさとセキュリティのバランスを取れます。

{
  "grants": [
    {
      "src": ["group:eng"],
      "dst": ["tag:internal-tools"],
      "ip": ["*"]
    },
    {
      "src": ["group:sales"],
      "dst": ["tag:internal-tools"],
      "ip": ["tcp:443", "tcp:22"]
    },
    {
      "src": ["*"],
      "dst": ["tag:dns"],
      "ip": ["udp:53"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

最初のグラントは、エンジニアリングチーム（group:eng）に、社内ツールへの無制限のアクセスを与え、すべてのプロトコルとポートを許可します。
2つ目のグラントは、営業チーム（group:sales）に限定的なアクセスを提供し、HTTPS（ポート443）とSSH（ポート22）のみに制限します。
3つ目のグラントは、tailnet内の全員がDNSサービス（UDPポート53）にアクセスできるようにします。

この例を実装するには、tailnetポリシーファイルで参照しているグループとタグを定義する必要があります。
グループにはチームメンバーのメールアドレスを列挙し、タグは関連するデバイスに適用します。
このアプローチでは、チームメンバーシップの変更に応じて、継続的なメンテナンスが必要です。
組織で人事異動が頻繁にある場合や、ユーザー数が多い場合は、グループ管理の自動化の導入を検討してください。

場所に基づいてExit Node経由でトラフィックをルーティングする

この例は、ユーザーの地理的な場所に基づいて、Exit Nodeの使用をセグメント化します。
異なる場所にExit Nodeがある場合、最適なパフォーマンスのために、ユーザーに最も近いExit Nodeを使用させたいことがあります。
このアプローチは、コンプライアンス上の理由やtailnetのレイテンシ最適化のために、ユーザーが適切な管轄区域のExit Node経由で接続することを保証するのに役立ちます。

{
  "grants": [
    {
      "src": ["group:nyc"],
      "dst": ["autogroup:internet"],
      "via": ["tag:exit-node-nyc"],
      "ip": ["*"]
    },
    {
      "src": ["group:sea"],
      "dst": ["autogroup:internet"],
      "via": ["tag:exit-node-sea"],
      "ip": ["*"]
    },
    {
      "src": ["group:eng"],
      "dst": ["autogroup:internet"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、viaフィールドを使って、特定のデバイス経由でトラフィックを強制的にルーティングします（これはルートフィルタリングと呼ばれます）。
ニューヨークオフィス（group:nyc）とシアトルオフィス（group:sea）のユーザーは、それぞれの場所にあるExit Nodeを使用する必要がありますが、エンジニアリングチーム（group:eng）は、任意のExit Nodeを使用するか、直接接続できます。
この例は、ユーザーが手動で適切なExit Nodeを選択する必要なく、ルーティングパスを強制します。

この例を機能させるには、ポリシー内で参照しているグループを定義し、適切なExit Nodeにタグを付ける必要があります。
各Exit Nodeは、Tailscale管理コンソールでも適切に構成されている必要があります。
viaフィールドがなければ、ユーザーは利用可能な任意のExit Nodeを選べてしまい、最適でないルーティングやコンプライアンス上の問題につながる可能性があります。

指定したExit Nodeが利用できなくなった場合、そのグループのユーザーは、Exit Nodeが再び利用可能になるか、ポリシーを更新するまで、Tailscale経由でインターネットにアクセスできなくなります。

デバイスポスチャに基づいてリソースへのアクセスを許可する

この例は、デバイスのコンプライアンス状況に基づいて、異なるサブネットルーター経由でリソースへのアクセスを制御します。
デバイスポスチャチェックにより、準拠しているデバイスのみが機密性の高いリソースにアクセスできるようになります。
このアプローチは、デバイスのセキュリティ状態に基づいてサブネットアクセスを制御する方法を示しており、準拠しているデバイスには直接アクセスを許可し、それ以外は制御されたゲートウェイ経由でルーティングします。

{
  "postures": {
    "posture:latestMac": [
      "node:os == 'macos'",
      "node:osVersion == '13.4.0'",
      "node:tsReleaseTrack == 'stable'"
    ]
  },
  "grants": [
    {
      "src": ["group:eng"],
      "srcPosture": ["posture:latestMac"],
      "dst": ["192.0.2.0/24"],
      "ip": ["*"]
    },
    {
      "src": ["autogroup:member"],
      "dst": ["192.0.2.0/24"],
      "via": ["tag:office-router"],
      "ip": ["*"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、デバイスがmacOS Ventura 13.4.0を、安定版のTailscaleクライアントバージョンで実行していることを検証する、posture:latestMacというポスチャチェックを定義しています。
最初のグラントは、準拠しているデバイスを持つエンジニアリングチームのメンバーが、サブネットに直接アクセスできるようにします。
2つ目のグラントは、それ以外のすべてのユーザーをオフィスルーター経由でルーティングし、準拠していないデバイスに対して追加のセキュリティ層を設けます。

この例を実装するには、ポスチャチェックのパラメーターを定義し、参照しているグループを作成し、少なくとも1台のデバイスにオフィスのサブネットルーターとしてタグを付ける必要があります。
ポスチャチェックはリアルタイムで評価されるため、デバイスの状態が変化すると、権限が自動的に調整されます。

この例では、OSやTailscaleのバージョンが進化するにつれて、ポスチャ要件を慎重に維持する必要があります。
バージョン要件を厳しく設定しすぎると、まだシステムを更新していない正当なユーザーを誤ってブロックしてしまう可能性があります。

グループのトラフィックをアプリコネクタ経由でルーティングする

この例は、異なるユーザーグループ向けに、特定のアプリコネクタ経由でアプリケーションアクセスをセグメント化します。
アプリコネクタは、ユーザーに直接公開することなく、特定のアプリケーションへの安全なアクセスを提供します。
このアプローチにより、ユーザーが指定された安全なチャネルを通じてのみ特定のアプリケーションにアクセスできるようになり、接続経路に認証・監視のポイントが追加されます。

{
  "grants": [
    {
      "src": ["group:github-users"],
      "dst": ["autogroup:internet"],
      "ip": ["*"],
      "via": ["tag:github-appconnector"]
    },
    {
      "src": ["group:salesforce-users"],
      "dst": ["autogroup:internet"],
      "ip": ["*"],
      "via": ["tag:salesforce-appconnector"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、異なるユーザーグループを、そのサービスのニーズに応じて、異なるアプリコネクタ経由に誘導します。
github-usersグループのユーザーはGitHubアプリコネクタを、salesforce-usersはSalesforceアプリコネクタを経由する必要があります。
viaフィールドはこれらのルーティングパスを強制し、トラフィックが安全な接続方式を使用することを保証します。

この例を機能させるには、ユーザーグループを定義し、適切なタグを付けてアプリコネクタを設定する必要があります。
また、各アプリコネクタを、その特定のアプリケーション向けに構成する必要があります。

この例では、アプリケーションごとに個別のコネクタを維持する必要があり、運用の手間は増えますが、強力なセキュリティ分離を実現できます。
アプリコネクタに障害が発生すると、そのコネクタが再び利用可能になるか、ポリシーを更新するまで、ユーザーはそのアプリケーションへのアクセスを失います。

autogroup:internetをカスタマイズする

この例は、IPセットを使ってカスタムのインターネットアクセスルールを作成し、特定のサブネットルーター経由でトラフィックをルーティングします。
ユーザーがアクセスできる外部リソースを、よりきめ細かく制御する必要がある場合があります。
このアプローチでは、インターネットアドレスのカスタムなサブセットを定義し、それぞれのサブセットに異なるルーティングルールを適用でき、一般的なインターネットアクセスルールから特定のサービスを除外するのに役立ちます。

{
  "ipsets": {
    "ipset:internet": [
      "add autogroup:internet",
      "remove ipset:cdn-edge",
      "remove ipset:partner-net"
    ],
    "ipset:cdn-edge": ["198.51.100.6", "198.51.100.7", "198.51.100.13", "198.51.100.14"],
    "ipset:partner-net": ["203.0.113.0/24"]
  },
  "grants": [
    {
      "src": ["group:sea"],
      "dst": ["ipset:internet"],
      "ip": ["*"],
      "via": ["tag:officerouter-sea"]
    },
    {
      "src": ["group:lon"],
      "dst": ["ipset:internet"],
      "ip": ["*"],
      "via": ["tag:officerouter-lon"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、特定のCDNエッジノードとパートナーネットワークを除く、すべてのインターネットアドレスを含む、カスタムのipset:internetを作成します。
IPセットの定義は、addとremoveのオペレーションを使って最終的なセットを構成します。
シアトル（group:sea）とロンドン（group:lon）のユーザーは、それぞれのオフィスルーター経由でルーティングされ、このカスタマイズされたインターネットの定義にアクセスします。

この例を実装するには、適切なネットワークアドレスでIPセットを定義し、場所ごとのユーザーグループを作成し、それに応じてオフィスルーターにタグを付ける必要があります。
特に除外対象のネットワークが頻繁に変わる場合、この例ではIPアドレスリストの慎重な管理が必要です。
動的なクラウドリソースや、頻繁に変わるパートナーネットワークを参照している場合は、これらのIPセットを最新の状態に保つための自動化の利用を検討してください。

デバイスポスチャを使って異なる環境へのアクセスを許可する

この例は、デバイスのセキュリティポスチャに基づいて、異なるインフラ環境へのアクセスを制御します。
複数の段階（開発、ステージング、本番）を持つ環境では、より機密性の高い環境へのアクセスには、より厳格なセキュリティ要件を求めることがよくあります。
このアプローチは、環境の機密性に応じた、段階的なセキュリティポスチャを強制します。

{
  "grants": [
    {
      "src": ["group:devs"],
      "dst": ["ipset:prod-infra"],
      "ip": ["*"],
      "via": ["tag:prod-connector"],
      "srcPosture": ["posture:strict-mac"]
    },
    {
      "src": ["group:devs"],
      "dst": ["ipset:stg-infra"],
      "ip": ["*"],
      "via": ["tag:stg-connector"],
      "srcPosture": ["posture:semi-strict-mac"]
    },
    {
      "src": ["group:devs"],
      "dst": ["ipset:dev-infra"],
      "ip": ["*"],
      "via": ["tag:dev-connector"],
      "srcPosture": ["posture:any-mac"]
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、宛先の環境とデバイスのセキュリティポスチャに基づいて、開発者のトラフィックを異なるアプリコネクタ経由でルーティングします。
本番インフラには最も厳格なデバイスセキュリティポリシーが求められ、ステージングには中程度の要件、開発には最小限の要件が求められます。
ユーザーは、追加のセキュリティ制御を実装できる専用コネクタを通じて、各環境にアクセスします。

この例を実装するには、ポスチャチェック、各環境用のIPセットを定義し、適切なコネクタデバイスにタグを付ける必要があります。
参照しているポスチャ、IPセット、グループ、タグは、tailnetポリシーファイルの他の箇所で定義する必要があります。
この例は、デバイスのセキュリティ検証とネットワークパスの制御を組み合わせることで、多層防御を提供します。
セキュリティポスチャの定義を個別に維持するには、重要な環境へのアクセスを誤ってブロックしないよう、要件を更新する際に慎重な調整が必要です。

権限付きでKubernetes Operatorへのアクセスを許可する

この例は、異なる権限レベルでKubernetes Operatorへのアクセスを管理します。
tailnet内でKubernetesクラスターを運用する場合、異なるユーザーに異なるレベルのアクセス権を付与したいことがあります。
この例は、TailscaleのKubernetesケイパビリティを通じて、本番チームに管理者権限を、他のユーザーに読み取り専用アクセスを付与する方法を示しています。

{
  "grants": [
    {
      "src": [
        "group:prod"
      ],
      "dst": [
        "tag:k8s-operator"
      ],
      "app": {
        "tailscale.com/cap/kubernetes": [
          {
            "impersonate": {
              "groups": [
                "system:masters"
              ]
            }
          }
        ]
      }
    },
    {
      "src": [
        "group:k8s-readers"
      ],
      "dst": [
        "tag:k8s-operator"
      ],
      "app": {
        "tailscale.com/cap/kubernetes": [
          {
            "impersonate": {
              "groups": [
                "tailnet-readers"
              ]
            }
          }
        ]
      }
    }
  ]
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、appフィールドを使って、特定のKubernetesケイパビリティを付与します。
本番チーム（group:prod）は、管理者権限を持つsystem:mastersグループになりすませますが、読み取り専用グループ（group:k8s-readers）は、読み取り専用アクセス権を持つtailnet-readersグループにしかなりすませません。
Kubernetes Operatorのデバイスには、tag:k8s-operatorタグを付ける必要があります。

この例を実装するには、ユーザーグループを定義し、Kubernetes Operatorのデバイスにタグを付ける必要があります。
また、なりすまし先のグループをKubernetesクラスターが認識し、適切な権限を付与するように構成する必要もあります。
この例により、基盤となるKubernetesの構成を変更することなく、Tailscale経由でKubernetesへのアクセスを管理できます。
これが正しく機能するには、tailnet-readersグループが、適切な読み取り専用権限を持ってKubernetesの構成内に存在している必要があります。

アプリケーションのピアリング

アプリケーションのピアリングとは、2つのアプリケーションまたはアプリケーション環境の間に、双方向のピアツーピア接続を確立することを指します。

この例は、クラウドプロバイダーやSaaSアプリケーションをまたいだ、アプリケーション間の接続を可能にします。
このアプローチは、複数のクラウド環境にわたってアプリケーションやサービスを接続するのに役立ちます。
例えば、異なるクラウドプロバイダーのデータベース間でデータをストリーミングしたり、サービスを公開することなく、環境をまたいだ安全なサービス間通信を実現したりする場合に使えます。

{
  "groups": {
    "group:infra": ["carl@example.com"]
  },
  "grants": [
    {
      "src": ["tag:database", "tag:gcp", "tag:aws"],
      "dst": ["tag:database"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:database": ["group:infra"],
    "tag:gcp": ["group:infra"],
    "tag:aws": ["group:infra"]
  }
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、データベース間の双方向通信を可能にし、クラウドプロバイダーのタグが付いたデバイスが、データベースにアクセスできるようにします。
インフラチーム（group:infra）は、どのデバイスにどのタグを付けるかを管理でき、どのサービスが通信できるかを制御できます。
この例は、デバイスの機能（database）と環境（gcp、aws）の両方を識別するために、タグの組み合わせを使用しています。

この例を実装するには、インフラチームのグループを定義し、クラウドリソースに適切なタグを適用する必要があります。
各クラウドリソースは、tailnetに参加するために、稼働中のTailscaleクライアントを必要とします。
この例は、複雑なVPN構成やパブリックIPの露出を必要とせず、クラウドプロバイダーをまたいだ安全なオーバーレイtailnetを作成します。

この例では、databaseタグの付いた任意のデバイスが、他の任意のデータベースと通信できてしまう点に注意してください。厳密なデータ分離要件がある環境には、許可的すぎる可能性があります。

CI/CD開発パイプライン

この例は、チームの役割に基づいて、デプロイパイプラインのコンポーネントへのアクセスを制限します。
DevOpsやSRE（サイト信頼性エンジニアリング）チームは、開発者が開発ツールにアクセスできるようにしながら、本番環境へのアクセスをDevOpsチームに制限するなど、デプロイパイプラインの保護が必要になることがよくあります。
この構成は、自動デプロイを可能にしながら、ソフトウェア配信プロセスに適切な境界を作ります。

{
  "groups": {
    "group:dev": ["alice@example.com", "bob@example.com"],
    "group:devops": ["carl@example.com"]
  },
  "grants": [
    {
      "src": ["group:dev"],
      "dst": ["tag:dev"],
      "ip": ["*"]
    },
    {
      "src": ["group:devops"],
      "dst": ["tag:ci", "tag:prod"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:ci": ["group:devops"],
    "tag:dev": ["group:devops", "tag:ci"],
    "tag:prod": ["group:devops", "tag:ci"]
  }
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、開発、CI/CD、本番環境へのアクセスを分離します。
開発者は開発リソースにアクセスでき、DevOpsチームはビルドツールと本番環境にアクセスできます。
興味深い点として、tag:ciタグの付いたデバイスもデバイスのタグを管理できるため、自動デプロイプロセスが、環境を進むにつれてリソースに適切にタグを付けられるようになります。

この例を実装するには、開発者とDevOpsのグループを定義し、各環境の適切なリソースにタグを付ける必要があります。
この例は、セキュリティの分離と自動化能力の間でバランスを取っています。
CI/CDシステムがタグを管理できるため、人間の直接的な介入なしにデプロイパイプライン全体を扱えます。
このアプローチでは、CI/CDシステム自体がtailnet内で昇格した権限を持つため、そのシステム自体を慎重に保護する必要があります。

アプリケーションへのアクセスを監視する

この例は、tailnet全体で、特定のポートのサービスへの監視サーバーのアクセスを可能にします。
DevOpsやSREチームは、tailnet内のサービスからログやメトリクスを問い合わせるために、監視ツールを必要とすることがよくあります。
このアプローチにより、tailnet全体へのアクセスを許可することなく、監視サーバーが特定のアプリケーションポートにアクセスでき、可観測性のニーズとセキュリティのバランスを取れます。

{
  "groups": {
    "group:devops": ["carl@example.com"]
  },
  "grants": [
    {
      "src": ["tag:monitoring"],
      "dst": ["tag:logging"],
      "ip": ["80", "443", "9100"]
    },
    {
      "src": ["group:devops"],
      "dst": ["tag:monitoring", "tag:logging"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:monitoring": ["group:devops"],
    "tag:logging": ["group:devops"]
  }
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、監視サーバーが、ロギングデバイス上の特定のポート（HTTP、HTTPS、Prometheusのnode exporter）にアクセスできるようにします。
DevOpsチームは、監視インフラとロギングインフラの両方に完全なアクセス権を持ち、どのデバイスにこれらの役割のタグを付けるかを管理できます。
これにより、監視インフラと監視対象のサービスの間に、明確な分離が生まれます。

この例を実装するには、DevOpsグループを定義し、監視とロギングの役割に応じて適切なデバイスにタグを付ける必要があります。
この例は、監視アクセスを必要なポートのみに制限することで、可観測性を維持しながら攻撃対象領域を減らします。
ポートの制限は、自社の監視ツールとプロトコルに合わせて調整してください。

監視要件の変化や、新しい監視ポートの導入に伴い、このアプローチは更新が必要になる場合があります。

ネットワークのマイクロセグメンテーション

ネットワークのマイクロセグメンテーションとは、セキュリティを強化し、潜在的な攻撃の拡大を抑えるために、tailnetを小さく分離されたセグメントに分割することです。

この例は、サポートチームがセグメントをまたいでアクセスできる、論理的なtailnetセグメンテーションを実装します。
ネットワークのマイクロセグメンテーションは、セキュリティ上の理由から、tailnetを論理的な単位に分割し、潜在的なセキュリティインシデントの影響範囲を限定します。
各セグメントは分離された状態で存在しますが、サポートチームには、セグメントをまたいだ制御されたアクセスが必要になる場合があります。

{
  "grants": [
    {
      "src": ["group:support"],
      "dst": ["tag:segment-abc", "tag:segment-xyz"],
      "ip": ["443"]
    },
    {
      "src": ["tag:support"],
      "dst": ["tag:segment-abc", "tag:segment-xyz"],
      "ip": ["443"]
    }
  ],
  "groups": {
    "group:support": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:support": ["autogroup:admin"]
  }
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、制御されたセグメント間アクセスを備えた、分離されたtailnetセグメントを作成します。
サポートチームのメンバーと、サポート用にタグ付けされたデバイスは、両方のセグメントにアクセスできますが、ポート443（HTTPS）に限られます。
これにより、サポートチームは、すべてのプロトコルへの広範なアクセスを許可することなく、各セグメントのWebインターフェースやAPIにアクセスできます。

この例を実装するには、サポートチームのグループを定義し、各セグメント内のデバイスにタグを付け、サポートツールにもタグを付ける必要があります。
Adminは、必要に応じてデバイスにサポートタグを割り当てられます。
この例は、各セグメント内での通信までは定義していません。セグメント内のデバイス同士が通信できるようにするには、追加のグラントが必要です。
このアプローチは、サポートアクセスに対する制御された例外を設けつつ強力な分離を提供し、セキュリティインシデント発生時の横方向の移動リスクを減らします。

VPCへのアクセス

この例は、サブネットピアリング機能を備えた、開発者のVPCリソースへのアクセスを可能にします。
組織がクラウドプロバイダーでVPCを使用している場合、適切なサブネット分離とルーティングを維持しながら、開発者にこれらのリソースへのアクセスを許可したいことがあります。
このアプローチは、パブリックに露出することなく、クラウドリソースへ安全にアクセスするのに特に役立ちます。

{
  "groups": {
    "group:dev": ["alice@example.com", "bob@example.com"]
  },
  "grants": [
    {
      "src": ["autogroup:admin"],
      "dst": ["tag:vpc-peering:*"],
      "ip": ["*"]
    },
    {
      "src": ["group:dev", "192.0.2.0/24", "198.51.100.0/24"],
      "dst": ["192.0.2.0/24:*", "198.51.100.0/24:*"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:vpc-peering": ["autogroup:admin"]
  },
  "autoApprovers": {
    "routes": {
      "192.0.2.0/24": ["tag:vpc-peering", "autogroup:admin"],
      "198.51.100.0/24": ["tag:vpc-peering", "autogroup:admin"]
    }
  }
}

ビジュアルポリシーエディタを使ってtailnetポリシーファイルを管理することもできます。
ビジュアルエディタの使い方については、ビジュアルエディタリファレンスを参照してください。

この例は、2つのVPCサブネット間の双方向通信を可能にし、開発者に両方へのアクセスを許可します。
Adminは、VPCピアリングデバイスにアクセス・管理できます。
autoApproversセクションは、VPCのサブネットルートを自動承認し、Tailscale管理コンソールでの手動承認を不要にします。

この例を実装するには、開発者グループを定義し、VPCピアリングデバイスにタグを付け、サブネットルーティングを構成する必要があります。
これがサブネットルーティングで正しく機能するには、サブネット間の直接通信を可能にするために、サブネットルートのマスカレードを無効にする必要がある場合があります。
この例は、人間のユーザーとサブネット内のデバイスの両方が互いに通信できるようにし、複雑なハイブリッドクラウドアーキテクチャを実現します。
この例では、競合を避けるためのサブネットアドレッシングの慎重な管理と、クラウドtailnet設定の適切な構成が必要です。

自動承認を使って、ルートを自動的に承認することもできます。

Tailscale Peer Relaysを使用する

次の例は、tag:us-east-vpcタグの付いたすべてのデバイスが、tailnet内の他のデバイスと通信する際に、tag:us-east-relaysタグの付いたTailscale Peer Relaysを、アンダーレイネットワークのリレーとして使用できるようにします。
つまり、tailnet内の他のデバイスは、tag:us-east-vpcタグの付いたデバイスと通信する際に、tag:us-east-relaysタグの付いたデバイスを、アンダーレイネットワークのリレーとして使用できます。
これは、tailscale.com/cap/relayというアプリケーションケイパビリティを使って、Peer Relay機能を有効にします。

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

これが機能するには、tailscale setコマンドを使ってPeer Relayデバイスを構成し、tag:us-east-vpcタグの付いたデバイスへのオーバーレイネットワークアクセスを許可する、基本的なグラントポリシーも作成する必要があります。
例えば、次のグラントポリシーは、tailnetのすべてのメンバーが、tag:us-east-vpcタグの付いたデバイスに、TCPポート80と443でアクセスできるようにします。

{
  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["tag:us-east-vpc"],
      "ip": ["tcp:80","tcp:443"]
    }
  ]
}

まとめ

グラントはデフォルト拒否の原則で動作するため、（デフォルトの全許可ポリシーを維持しない限り）許可したい接続は明示的に許可する必要があることを覚えておいてください。
グラントシステムの柔軟性により、組織に必要な接続性を確保しながら、セキュリティのベストプラクティスに沿った、きめ細かなアクセス制御を実装できます。