tailnetポリシーファイルの構文リファレンス

grants、acls、ssh、tagOwnersなど、各セクションの構文リファレンス

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

Tailscaleのアクセス制御ルール（ACLやグラントなど）は、human JSON（HuJSON）で記述されるtailnetポリシーファイル内に記述します。

tailnetポリシーファイルには、以下のトップレベルセクションがあります。

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

グラント

グラントは、アクセス制御に対する新しく、より強力なアプローチです。
ACLでできることをすべて行えるうえに、さらに多くのことができます。
宛先デバイスと通信する際、デバイスやユーザーの集合に対してアプリケーション層のケイパビリティを付与できます。
また、従来のネットワーク層のケイパビリティも引き続き定義できます。
例えば、グラントルールを使って、あるユーザーグループにサーバーの8443ポートへのアクセスを許可すると同時に、そのサーバー上で編集できるファイルを定義することができます。

グラントシステムは、ネットワーク層とアプリケーション層のケイパビリティを、共通の構文に統合します。
その結果、リソースへのアクセスに対して、より高い柔軟性ときめ細かな制御を提供します。
各グラントに必要なのは、送信元（source）と宛先（destination）のみです。
Tailscaleはデフォルト拒否（deny-by-default）のアプローチを採用しているため、各グラントには暗黙的なacceptアクションが伴います。

• グラント — ネットワーク接続とアプリケーションの権限の両方にわたって、アクセス制御の権限を付与します。
• グラントの構文 — Tailscaleのグラントシステムの完全なリファレンスドキュメントです。

ACL

Tailscaleは現在、次世代のアクセス制御ポリシー構文であるグラントを使って、リソースへのアクセスを保護しています。
グラントは、従来のACLのすべての機能に加えて、追加の機能を提供します。

ACLは今後も無期限に動作し続けます。Tailscaleは、この第1世代の構文のサポートを製品から削除することはありません。
ただし、ACLには新機能が追加されないため、Tailscaleはグラントへの移行と、すべての新しいtailnetポリシーファイルの構成でグラントを使用することを推奨しています。

aclsセクションには、tailnetのアクセスルールを列挙します。各ルールは、送信元の集合から宛先の集合へのアクセスを許可します。

アクセスルールでは、グループやタグを使って、あらかじめ定義したユーザーの集合にアクセスを許可したり、ノードにサービスロールアカウントを割り当てたりできます。
グループとタグを組み合わせることで、強力なロールベースアクセス制御（RBAC）ポリシーを構築できます。

Tailscaleは、すべてのACLを自動的に、送信元IPアドレスから宛先IPアドレスとポートへのトラフィックを許可する、より低レベルのルールに変換します。

次の例は、action、src、proto、dstを含むアクセスルールを示しています。

{
  "action": "accept",
  "src": [ <list-of-sources> ],
  "proto": "tcp", // オプション
  "dst": [ <list-of-destinations> ],
}

tailnetポリシーのaclセクションは、レガシーフィールドのusersとportsもサポートしていますが、（usersの代わりに）src、（portsの代わりに）dstを使うことがベストプラクティスです。

action

Tailscaleのアクセスルールは、デフォルトでアクセスを拒否します。
そのため、指定できるactionはacceptのみです。
acceptは、送信元（src）から宛先（dst）へのトラフィックを許可します。

src

srcフィールドは、ルールが適用される送信元のリストを指定します。リスト内の各要素には、以下のいずれかを指定できます。

オプションでsrcPostureフィールドを含めることで、デバイスポスチャの条件に一致するデバイスのみに、srcをさらに制限できます。

proto

protoフィールドはオプションのフィールドで、ルールが適用されるプロトコルを指定するために使用できます。プロトコルを指定しない場合、アクセスルールはすべてのTCPおよびUDPトラフィックに適用されます。

protoには、IANA IPプロトコル番号の1〜255（例: "16"）、またはサポートされている名前付きエイリアスのいずれかを指定できます。

protoフィールドに関する注意事項です。

• protoフィールドを使うには、Tailscaleバージョンv1.18.2以降が必要です。それより前のバージョンのTailscaleでは、プロトコルを含むアクセスルールが失敗し、ブロックされます。
• 特定のIPアドレスのペア間でトラフィックが許可されている場合、ICMPも許可されます。
• ポートの指定をサポートするのは、TCP、UDP、SCTPトラフィックのみです。それ以外のすべてのプロトコルでは、プロトコルのポートとして*のみがサポートされます。

dst

dstフィールドは、ルールが適用される宛先のリストを指定します。リスト内の各要素は、<host>:<ports>という形式で、hostと1つ以上のportsを指定します。

hostには、以下のいずれかのタイプを指定できます。

portsフィールドには、以下のいずれかのタイプを指定できます。

サブネットルーターとExit Node

ACLはルートの検出を制限しません。デバイスがサブネットルーターである場合、そのサブネットとは独立して、そのデバイスへのアクセスを制限できます。デバイスがExit Nodeである場合、そのパブリックIPアドレスとは独立して、そのデバイスへのアクセスを制限できます。

サブネットへのアクセスを制限するには、そのルートへのアクセスを許可するACLが存在しないことを確認します。
これは、誤ってアクセスを許可するルールがあった場合に失敗するテストを使って強制できます。
次の例は、not-allowed@example.comが198.51.100.7:22へのアクセスを許可されている場合に失敗するテストを示しています。

"tests": [
  {
    "src": "not-allowed@example.com",
    "accept": ["192.0.2.100:22"], // Tailscale IPへのアクセスを許可
    "deny": ["198.51.100.7:22"], // サブネットへのアクセスを許可しない
  }
],

autogroup:internetへのアクセス権を持つデバイスのみが、Exit Nodeを使用できます。
それ以外のデバイス（autogroup:internetへのアクセス権を持たないデバイス）は、Exit Nodeを使用できません。
これは、誤ってパブリックアドレスへのアクセスを許可するルールがあった場合に失敗するテストを使って強制できます。
次のテスト例は、not-allowed@example.comが198.51.100.8:22にアクセスできる場合に失敗します。

"tests": [
  {
    "src": "not-allowed@example.com",
    "accept": ["192.0.2.100:22"], // Tailscale IPへのアクセスを許可
    "deny": ["198.51.100.8:22"], // パブリックIPへのアクセスを許可しない
  }
],

ACLを使って特定のExit Nodeの使用を制限することはできません。更新情報については、issue #1567を参照してください。

4via6にはIPv4ではなくIPv6が必要

4via6サブネットルーターの背後にあるリソースをターゲットにするアクセス制御ルールを記述する際は、宛先としてIPv4アドレスではなく、IPv6のCIDRまたはアドレスを使用してください。

IPv6のCIDRを取得するには、tailscale debug viaを使用します。

Taildropの優先順位

Taildropを使うと、ACLでアクセスを制限している場合でも、自分がログインしているデバイス間でファイルを共有できます。

ユーザーを参照する

ユーザーは、すべてのプランで利用できます。

アクセスルールの送信元（src）と宛先（dst）フィールドには、ユーザーを指定できます。
ユーザーを指定するには、そのユーザーのTailscaleへのサインイン方法に応じて、以下のいずれかの形式を使用します。

グループを使うと、ユーザーの集合を参照できます。グループを使うと、ロールベースのアクセス制御を定義できます。グループには複数の種類があります。

• 同じプロパティを持つすべてのユーザーを参照する、オートグループ。
• tailnetポリシーファイルのgroupsセクションで、特定のユーザーのリストとして定義されたグループ。
• アイデンティティプロバイダーでプロビジョニングされ、ユーザー・グループプロビジョニングを通じて同期されたグループ。

オートグループ

オートグループは、すべてのプランで利用できます。

オートグループは、同じプロパティを持つユーザー、宛先、ユーザー名を自動的に含める特別なグループです。

autogroup:selfは、ユーザー所有のデバイスにのみ適用されます。タグ付きデバイスには適用されません。autogroup:selfとautogroup:taggedを同時に使用することはできません。

レガシーなオートグループであるautogroup:membersは今後も動作しますが、代わりにautogroup:memberを使うことがベストプラクティスです。autogroup:memberとautogroup:membersを同じtailnetポリシーファイル内で併用することはできません。

次のsshルールの例は、すべてのユーザーに、自分が所有するデバイスへの（root以外としての）Tailscale SSHアクセスを許可します。

"ssh": [
  {
    // すべてのユーザーは、自分自身のデバイスへ、root以外としてSSH接続できます
    "action": "accept",
    "src": ["autogroup:member"],
    "dst": ["autogroup:self"],
    "users": ["autogroup:nonroot"]
  },
]

デフォルトのACLでは、sshルールはdstフィールドにautogroup:selfを、usersフィールドにautogroup:nonrootを使用します。
dstフィールドをautogroup:selfから、ACLタグのような別の宛先に変更する場合は、usersフィールドのautogroup:nonrootも置き換えることを検討してください。
usersフィールドからautogroup:nonrootを削除しないと、src設定で許可された誰もが、dstデバイス上の任意のroot以外のユーザーとしてSSH接続できてしまいます。

ドメインベースのオートグループ

一部のオートグループには、特定のドメイン名が含まれます。例えば、user:*@example.comやlocalpart:*@example.comです。
これらのオートグループには、tailnetのメンバーであり、かつログインがそのオートグループのドメインに含まれるユーザーが含まれます。
例えば、example.comというtailnetがuser:*@altostrat.comというオートグループを使用する場合、このグループには、example.comtailnetのメンバーのうち、@altostrat.comのユーザー（laura@altostrat.comなど）としてログインするすべてのユーザーが含まれます。

オートグループで使用するドメインには、以下の制約が適用されます。

• 指定するドメインは、既知の共有ドメイン（gmail.comなど）であってはなりません。
• tailnetがドメインエイリアスを使用している場合、ACL内でエイリアス先のドメインを明示的に指定する必要があります。例えば、example.ioがexample.comのエイリアスであり、example.comとexample.ioの両方のユーザーを含めたい場合は、user:*@example.comとuser:*@example.ioの両方を使用します。
• この式ではワイルドカード*を使いますが、任意のワイルドカードはサポートされません。例えば、user:b*b@example.comはbob@example.comに一致しません。
• ドメインベースのオートグループは、外部の招待ユーザーとは併用できません。ドメインベースのオートグループには、直接またはドメインエイリアスを通じて、tailnetのいずれかのドメインにメールアドレスが一致する、tailnetのメンバーのみが含まれます。

グループ

グループは、すべてのプランで利用できます。ただし、tailnetでサポートされるグループの数は、プランによって異なります。詳しくは、料金ページを参照してください。

groupsセクションを使うと、ユーザーのグループを作成でき、アクセスルールの中で（ユーザーを個別に列挙する代わりに）使用できます。
グループのメンバーシップに加えた変更は、そのグループを参照するすべてのルールに反映されます。

次の例は、engineeringグループとsalesグループを作成する方法を示しています。

"groups": {
  "group:engineering": [
    "dave@example.com",
    "laura@example.com",
  ],
  "group:sales": [
    "brad@example.com",
    "alice@example.com",
  ],
},

すべてのグループ名は、接頭辞group:で始まる必要があります。
各グループメンバーは、上記のユーザーのセクションで説明したとおり、完全なメールアドレスで指定します。
グループメンバーシップがわかりにくくなるリスクを避けるため、グループの中に別のグループを含めることはできません。

ユーザーのグループメンバーシップは、上記のgroups定義の例のようにtailnetポリシーファイルを編集するか、管理コンソールのUsersページから直接、追加・削除できます。

Usersページからユーザーのグループメンバーシップを編集する

Usersページからユーザーのグループメンバーシップを編集するには、Owner、Admin、Network adminのいずれかである必要があります。

1. 管理コンソールのUsersページを開きます。
2. 名前でユーザーを見つけます。
3. 省略記号（…）アイコンのメニューを選択し、Edit group membershipを選択します。
4. Edit group membershipダイアログで、以下の操作を行います。
   1. グループを追加するには、Add to a groupを選択し、追加するグループを選択します。
   2. グループを削除するには、削除したいグループの横にあるXを選択します。
5. ユーザーのグループの編集が完了したら、Saveを選択します。

同期グループ

アイデンティティプロバイダーでグループを作成し、ユーザー・グループプロビジョニングを使って、Tailscaleのアクセス制御ポリシーと同期できます。

アイデンティティプロバイダーで使用しているのと同じ、人間が読める形式のグループ名を使って、tailnetポリシーファイル内のグループを参照できます。
次の例は、security-teamグループのアクセスを管理するアクセスルールを示しています。

{
  "grants": [
    {
      "src": ["group:security-team@example.com"],
      "dst": ["tag:logging"],
      "ip": ["*"]
    }
  ],
  "tagOwners": {
    "tag:logging": ["group:security-team@example.com"]
  }
}

編集できるのは、tailnetポリシーファイルで定義されたグループのみです。
System for Cross-domain Identity Management（SCIM）連携から同期されたグループや、tailnetのオートグループも使用できますが、これらを編集することはできません。

複数のデバイスを参照する

タグやホストを使って、デバイスの集合に対するアクセスルールを定義できます。
タグを使うと、サービスごとに異なるアクセスルールを持たせる、ロールベースのアクセス制御を定義できます。
ホストを使うと、IPアドレスへの参照に基づく制御を定義できます。

• タグは、（アプリケーションやサーバーなどの）非ユーザーデバイスのグループを参照します。例えば、特定のデータセンター内のすべてのサーバーをグループ化するタグを用意できます。
• ホストは、（tailnet内外を問わず）IPアドレス範囲でデバイスのグループを参照します。例えば、変更できない固定IPアドレスを持つアプリケーションを、ホストを使ってアドレス指定できます。

タグ

タグは、すべてのプランで利用できます。

tailnetポリシーファイルのtagsという表現は、人間ではないデバイスをグループ化するタグを作成するためのものです。作成したタグは、ACL内でこれらのデバイスを選択するために使用できます。

ACLでタグを使用する前に、tailnetポリシーファイルのtagOwnersセクションで、そのタグを定義する必要があります。
デバイスにタグを付けるには、そのデバイス上で、そのタグとして認証します。

ホスト

ホストは、すべてのプランで利用できます。

hostsセクションを使うと、IPアドレスまたはCIDR範囲に対して、人間が読みやすい名前を定義できます。

次の例は、2つのホスト定義を示しています。1つは単一のIPアドレス用、もう1つはCIDR範囲用です。

"hosts": {
  "example-host-1": "198.51.100.100",
  "example-network-1": "198.51.100.0/24",
},

人間が読みやすいホスト名には、文字@を含めることはできません。

デバイスポスチャポリシー

デバイスポスチャポリシーは、すべてのプランで利用できます。

posturesセクションを使うと、特定のアクセスルールの一部として、デバイスが満たすべきデバイスポスチャ管理ルールの集合を定義できます。

次の例は、posturesを使って、バージョン1.40以降のnodeを実行しているmacOSデバイスを選択する方法を示しています。

"postures": {
  "posture:latestMac": [
    "node:os IN ['macos']",
    "node:tsReleaseTrack == 'stable'",
    "node:tsVersion >= '1.40'",
  ],
},

各ポスチャは、接頭辞posture:に続けて名前を付け、ポスチャ属性とその許可される値の集合を、文字列のリストとして指定する必要があります。

詳しくは、デバイスポスチャ管理を参照してください。

タグオーナー

タグは、すべてのプランで利用できます。

tailnetポリシーファイルのtagOwnersセクションは、デバイスに割り当て可能なタグと、各タグの割り当てを許可されたユーザーのリストを定義します。

次の例は、以下のようなtagOwners定義を示しています。

• engineeringグループを、webserverタグのオーナーに設定します。
• president@example.comとsecurity-adminsグループを、secure-serverタグのオーナーに設定します。
• autogroup:memberオートグループを、corpタグのオーナーに設定します。

"tagOwners": {
  "tag:webserver": [
    "group:engineering",
  ],
  "tag:secure-server": [
    "group:security-admins",
    "president@example.com",
  ],
  "tag:corp": [
    "autogroup:member",
  ],
}

すべてのタグ名は、接頭辞tag:で始まる必要があります。
タグオーナーには、（上記のユーザーのセクションで定義した）ユーザーの完全なログインメールアドレス、グループ名、オートグループ、または別のタグを指定できます。

autogroup:adminには、[]という省略記法が使えます。つまり、以下は同等です。

"tag:monitoring": [
  "autogroup:admin",
],

"tag:monitoring": [],

autogroup:adminとautogroup:network-adminのオートグループは、すべてのタグを割り当てられるため、[]は暗黙的に、autogroup:adminとautogroup:network-adminのみにタグの割り当てを許可します。

自動承認

自動承認は、すべてのプランで利用できます。

tailnetポリシーファイルのautoApproversセクションは、管理コンソールからのさらなる承認なしに、特定のアクションを実行できるユーザーのリストを定義します。
Tailscaleの一部のアクションには、ダブルオプトインが必要です。すなわち、Adminが、Tailscaleを実行しているデバイス上と、Tailscale管理コンソールの両方で、そのアクションを有効にする必要があります。これには以下が含まれます。

• 指定したルートの集合をサブネットルーターとしてアドバタイズすること。
• Exit Nodeをアドバタイズすること。

ルートの場合、これにより自動承認の対象者は、指定したルートのサブネットもアドバタイズできるようになります。

以下のいずれかが発生すると、Tailscaleはルートのアドバタイズを停止します。

• デバイスが、（そのルートやExit Nodeをアドバタイズできない）別のユーザーによって再認証された場合。
• そのルートをアドバタイズしたユーザーが、停止または削除された場合。

Tailscaleがルートのアドバタイズを停止してしまう事態を避けるには、タグを自動承認の対象として使うことを検討してください。

次の例は、alice@example.com、engineeringグループのメンバー、およびfooタグの付いたデバイスに対して、192.0.2.0/24ルートを自動承認するautoApprovers定義を示しています。
また、barタグの付いたデバイスに対するExit Nodeのアドバタイズも自動承認します。

"autoApprovers": {
  "routes": {
    "192.0.2.0/24": ["group:engineering", "alice@example.com", "tag:foo"],
  },
  "exitNode": ["tag:bar"],
}

ルートまたはExit Nodeの自動承認の対象には、（上記のユーザーのセクションで定義した）ユーザーの完全なログインメールアドレス、グループ名、オートグループ、またはタグを指定できます。

自動承認ポリシーは、Tailscaleが最初にサブネットルートのアドバタイズを受け取った時にのみ適用されます。
自動承認の対象を追加・変更するためにtailnetポリシーファイルを更新しても、既存の未承認ルートが遡及的に承認されることはありません。
既存の未承認ルートに対して自動承認をトリガーするには、そのルートをサブネットルーターから削除し、再度アドバタイズしてください。

Tailscale SSH

Tailscale SSHのtailnetポリシーは、すべてのプランで利用できます。

tailnetポリシーファイルのsshセクションは、Tailscale SSHを利用できるユーザーとデバイスのリスト（およびSSHユーザー）を定義します。
接続を許可するには、tailnetポリシーファイルに、ネットワークアクセスとSSHアクセスの両方を許可するルールが含まれている必要があります。

1. 送信元から宛先への、ポート22での接続を許可するアクセスルール。
2. 送信元から宛先への接続と、指定したSSHユーザーを許可するSSHアクセスルール。Tailscale SSHは、これを使って認証済みのSSH接続にキーを配布します。

次の例は、送信元、宛先、SSHユーザーのリストに対して、20時間ごとの再認証を要求するssh定義を示しています。

{
  "action": "check", // "accept" または "check"
  "src": [ <list-of-sources> ],
  "dst": [ <list-of-destinations> ],
  "users": [ <list-of-ssh-users> ],
  "checkPeriod": "20h", // オプション、checkアクションの場合のみ有効。デフォルトは12h
  "acceptEnv": [ "GIT_EDITOR", "GIT_COMMITTER_*", "CUSTOM_VAR_V?" ], // オプション、クライアントからホストに転送できる環境変数を許可リスト化します
  "srcPosture": [ <list-of-posture-conditions> ], // オプション、ポスチャ条件のリストに一致する場合のみアクセスを許可します
},

action

接続を許可するか、追加のチェックを行うかを指定します。

• acceptは、tailnetですでに認証済みのユーザーからの接続を許可します。
• checkは、checkPeriodに従って、ユーザーに定期的な再認証を要求します。

src

送信元（接続の発信元）を指定します。アクセスルールの宛先（dst）として定義できるのは、自分自身、グループ、タグ、またはオートグループのみです。*、他のユーザー、IPアドレス、ホスト名は使用できません。

アクセスルールを作成する時点で、IPアドレスやホスト名の所有権を保証することはできません。
セキュリティ対策として、Tailscaleはアクセスルールのdstフィールドでユーザー、IPアドレス、ホスト名を使用することを禁止しており、あるユーザーが意図せず他人のデバイスにアクセスしてしまう事態を防いでいます。
また、Tailscaleは、複数のユーザーが単一ユーザーのデバイスにアクセスできてしまうようなsrcとdstの組み合わせも防止します。

autogroup:memberにアクセスを許可すると、宛先デバイスが共有されている場合、そのtailnetにデバイスを持たない外部の招待ユーザーにもアクセスが許可されます。

dst

宛先（接続先）を指定します。宛先には、タグ、（送信元がユーザーまたはグループのみを含む場合の）autogroup:self、または（送信元が同じ名前の単一ユーザーのみを含む場合の）単一の名前付きユーザーを指定できます。
このような制約がある理由は、送信元が同じユーザーが所有するデバイスでない限り、Tailscaleはユーザーが所有するデバイス上でTailscale SSHセッションを開始することを許可しないためです。

許可されるポートは22のみであるため、宛先にポートを指定することはできません。宛先として*を指定することもできません。

users

このポリシーは、すべてのプランで利用できます。

ホスト上で許可されるユーザー名の集合を指定します。Tailscaleは、ホスト上にすでに存在するユーザーアカウントのみを使用します。

• autogroup:nonrootを指定すると、rootではない任意のユーザーを許可します。
• localpart:*@<domain>を指定すると、ユーザーのログインメールアドレスが<domain>にある場合に限り、ユーザーのログインのlocal-partと名前が一致するホスト上のユーザーを許可します。Tailscaleはlocal-partに対して特別な処理を行いません。例えば、ログインがdave+sshuser@example.comの場合、TailscaleはこれをSSHユーザーdave+sshuserにマッピングします。この方法は、PremiumおよびEnterpriseプランでのみ利用できます。
• ユーザーが指定されていない場合、Tailscaleはローカルホストのユーザーを使用します。つまり、ユーザーがローカルでaliceとしてログインしている状態で、別のデバイスにSSH接続すると、Tailscale SSHはユーザーaliceとしてログインを試みます。

checkPeriod

このポリシーは、PremiumおよびEnterpriseプランでのみ利用できます。

actionがcheckの場合、checkPeriodは、チェックを要求するまでに接続を許可する期間を指定します。時間は分または時間で指定できます。指定できる時間は、最短1分、最長168時間（1週間）です。

• デフォルトのチェック期間は12時間です。
• alwaysを指定すると、すべての接続でチェックを要求できます。alwaysを使用すると、（Ansibleのような）多数のSSH接続を短時間に連続して開く自動化ツールで、予期しない動作が発生する場合があります。

acceptEnv

acceptEnvを使用するには、ホストがTailscale v1.76.0以降を実行している必要があります。

SendEnvまたはSetEnvを使ってクライアントがホストに送信できる、許可リストに登録された環境変数名の集合を指定します。

値には、ワイルドカード文字*と?を含めることができます。*はゼロ文字以上に一致し、?は1文字に一致します。

acceptEnvの例

srcPosture

srcPostureフィールドは、ネットワークの送信元（src）をさらに制限するために使用できる、デバイスポスチャ条件の配列です。
例えば、srcPostureを使って、特定のバージョンのTailscaleクライアントを実行しているデバイスのみに、アクセスを制限できます。

評価の順序

Tailscaleは、SSHアクセスルールを、最も制限の厳しいポリシーから順に評価します。

• Checkポリシー
• Acceptポリシー

例えば、ユーザーalice@example.comにあるリソースへのアクセスをacceptルールで許可するアクセスルールと、alice@example.comが所属するgroup:devopsに同じリソースへのアクセスをcheckルールで許可するルールの両方がある場合、checkルールが適用されます。

tailnetポリシーファイルを変更していないtailnetには、ユーザーが自分の所有するデバイスに、checkモードでアクセスできるデフォルトのSSHポリシーがあります。

許可される接続の種類は、以下のみです。

• ユーザーから、自分自身のデバイスへ（rootを含む任意のユーザーとして）。
• ユーザーから、タグ付きデバイスへ（rootを含む任意のユーザーとして）。
• タグ付きデバイスから、別のタグ付きデバイスへ（任意のタグの組み合わせで）。タグ付きデバイスからのSSHアクセスルールは、checkモードにはできません。
• ユーザーから、自分に共有されたタグ付きデバイスへ（宛先ホストにSSH付きのTailscaleが構成されており、かつ宛先のACLがそのユーザーのSSH接続を許可している場合に限る）。

つまり、許可される最も広範なポリシーは、以下のようになります。

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["tag:prod"],
      "users": ["root", "autogroup:nonroot"]
    },
    {
      "action": "accept",
      "src": ["tag:logging"],
      "dst": ["tag:prod"],
      "users": ["root", "autogroup:nonroot"]
    }
  ]
}

ユーザーが自分自身のデバイスにのみ（root以外として）SSH接続できるようにするには、次のようにします。

{
  "grants": [
    {
      "src": ["*"],
      "dst": ["*"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot"]
    }
  ]
}

group:sreに、tag:prodタグの付いた本番環境のデバイスへのアクセスを許可するには、次のようにします。

{
  "groups": {
    "group:sre": ["alice@example.com", "bob@example.com"]
  },
  "grants": [
    {
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["group:sre"],
      "dst": ["tag:prod"],
      "users": ["ubuntu", "root"]
    }
  ],
  "tagOwners": {
    // group:sreのユーザーはtag:prodタグを適用できます
    "tag:prod": ["group:sre"]
  }
}

共有された、tag:devタグの付いた開発環境のデバイスへのアクセスをAliceに許可するには、次のようにします。

{
  "ssh": [
    {
      "action": "accept",
      "src": ["alice@example.com"],
      "dst": ["tag:dev"],
      "users": ["root", "alice"]
    },
  ]
}

ホストのユーザーとログインメールアドレスを一致させると便利な場合があります。例えば、dave@example.comが、ホストユーザーdaveとして認証できるようにすることができます。

ログインドメインexample.comの任意のtailnetメンバーが、ログインメールアドレスのlocal-partと一致するユーザーとして、tag:prodタグの付いた本番環境のデバイスにアクセスできるようにするには、次のようにします。

{
  "grants": [
    {
      "src": ["user:*@example.com"],
      "dst": ["tag:prod"],
      "ip": ["*"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["user:*@example.com"],
      "dst": ["tag:prod"],
      "users": ["localpart:*@example.com"]
    }
  ]
}

ノード属性

tailnetポリシーファイルのnodeAttrsセクションは、tailnet内の特定のデバイスに適用する追加の属性を定義します。

ノード属性とグラントのアプリケーションケイパビリティは、どちらもデバイスにケイパビリティを付与でき、同じappマップが両方に現れます。
あるケイパビリティを（デバイス側か接続側かの）どちらに属させるべきかを判断するには、ノード属性 vs. グラントのアプリケーションケイパビリティを参照してください。

ノード属性の使い方の1つとして、tailnet内のデバイスごとに異なるNextDNS構成を設定することが挙げられます。
次の例は、my-kid@my-home.comとtag:serverをターゲットに、nextdns:abc123とnextdns:no-device-infoという属性を設定するnodeAttrs定義を示しています。

"nodeAttrs": [
  {
    "target": ["my-kid@my-home.com", "tag:server"],
    "attr": [
      "nextdns:abc123",
      "nextdns:no-device-info",
    ],
  },
],

target

属性が適用されるノード（デバイス）を指定します。
デバイスの選択には、タグ（tag:server）、ユーザー（alice@example.com）、グループ（group:kids）、または*を使用できます。

attr

それらのノード（デバイス）に適用する属性を指定します。

例えば、

• 属性nextdns:abc123は、NextDNS構成IDabc123を指定します。これを使用すると、この属性はグローバルなNextDNS構成を上書きします。
• 属性nextdns:no-device-infoは、NextDNSへのデバイスメタデータの送信を無効にします。

次の例は、tailnetのメンバーが自分のノードでTailscale Funnelを使用できるようにします。

"nodeAttrs": [
  {
    "target": ["autogroup:member"],
    "attr":   ["funnel"],
  },
],

ネットワーク全体のポリシー設定を使う代わりに、nodeAttrsポリシーを使って、特定のデバイスに対してrandomize-client-port設定を有効にすることもできます。

"nodeAttrs": [
  {
    "target": ["tag:office-network", "group:sea-office"],
    "attr":   ["randomize-client-port"],
  },
],

app

これらのノード（デバイス）に適用する、アプリケーション層のケイパビリティを指定します。

次のノード属性定義の例は、example.comドメイン用にexample-connectorタグを構成します。

{
  "target": ["*"],
  "app": {
    "tailscale.com/app-connectors": [
      {
        "name": "example-app",
        "connectors": ["tag:example-connector"],
        "domains": ["example.com"],
        "routes": ["192.0.2.0/24"],
      },
    ],
  },
}

個々のアプリケーションは、<domainName>/<capabilityName>という形式で、ケイパビリティの名前を定義します。この例ではtailscale.com/app-connectorsを使用しています。

各ケイパビリティに関連付けられる値は、JSONオブジェクトの配列であり、それぞれにそのケイパビリティ固有の構成オプションが含まれます。

詳しくは、アプリコネクタの仕組みとアプリコネクタ利用のベストプラクティスを参照してください。

テスト

テストは、すべてのプランで利用できます。

testsセクションを使うと、tailnetポリシーファイルが変更されるたびにチェックとして実行される、アクセス制御ポリシー（グラントとACL）についてのアサーションを記述できます。
アサーションが失敗すると、Tailscaleは更新されたtailnetポリシーファイルをエラーとともに拒否します。エラーメッセージには、失敗したテストが示されます。

テストを使うことで、重要な権限を誤って取り消したり、重要なシステムを露出させたりしないようにできます。

tests定義は、次のようになります。

"tests": [
  {
    "src": "dave@example.com",
    "srcPostureAttrs": {
      "node:os": "windows",
    },
    "proto": "tcp",
    "accept": ["example-host-1:22", "vega:80"],
    "deny": ["192.0.2.3:443"],
  },
],

src

テスト対象のユーザーアイデンティティを指定します。ユーザーのメールアドレス、グループ、タグ、またはIPアドレスにマッピングされたホストを指定できます。
テストケースは、指定したアイデンティティで認証されたデバイスの視点で実行されます。

srcPostureAttrs

アクセスルール内のポスチャ条件を評価する際に使用するデバイスポスチャ属性を、キーと値のペアとして指定します。
このフィールドが必要なのは、アクセスルールにデバイスポスチャ条件が含まれる場合のみです。

proto

acceptルールとdenyルールに対するIPプロトコルを指定します。ACLルールのprotoフィールドと同様です。省略した場合、テストはTCPまたはUDPのいずれかのアクセスをチェックします。

Internet Control Message Protocol（ICMP）のアクセスをテストする場合は、"proto": "icmp"を設定し、ICMPはポートを使用しないため、宛先にはポート0を使用します。
次の例は、ユーザーalice@example.comがtag:productionタグの付いたデバイスにpingできることをテストします。

"tests": [
  {
    "src": "alice@example.com",
    "proto": "icmp",
    "accept": ["tag:production:0"],
  },
],

acceptとdenyの宛先

許可または拒否する宛先を指定します。リスト内の各宛先はhost:portという形式であり、portは単一の数値のポート、hostには以下のいずれかを指定します。

サブネット範囲をテストするために、CIDR（サブネット）表記を使用することはできません。例えば、192.168.1.0/24は無効です。代わりに、個々のIPアドレスまたはホスト名を指定する必要があります。

srcの送信元、およびacceptとdenyの宛先は、特定のエンティティを参照する必要があり、ワイルドカード*はサポートされません。例えば、acceptの宛先としてtags:*を指定することはできません。

レガシーなallow（acceptの代わり）は、ACLで引き続き動作します。ただし、acceptを使用することがベストプラクティスです。

SSHテスト

SSHテストは、すべてのプランで利用できます。

sshTestsセクションを使うと、Tailscale SSHのアクセスルールについてのアサーションを記述できます。SSHテストは、ACLのテストと同様に機能します。

SSHテストは、tailnetポリシーファイルが変更された時に実行されます。アサーションが失敗すると、Tailscaleは失敗したテストの詳細を示すエラーとともに、更新されたtailnetポリシーファイルを拒否します。

次の例は、dave@example.comからexample-host-1への接続に対して、以下のテストを実行するsshTests定義を示しています。

• ユーザーがdaveの場合、接続を許可（accept）します。
• ユーザーがadminの場合、接続をチェック（check）します。
• ユーザーがrootの場合、接続を拒否（deny）します。

"sshTests": [
  {
    "src": "dave@example.com",
    "dst": ["example-host-1"],
    "accept": ["dave"],
    "check": ["admin"],
    "deny": ["root"],
    "srcPostureAttrs": {
      "node:os": "windows",
    },
  },
],

src

SSH接続を試みているユーザーアイデンティティを指定します。ユーザーのメールアドレス、グループ、タグ、またはIPアドレスにマッピングされたホストを指定できます。
テストケースは、指定したアイデンティティで認証されたデバイスの視点で実行されます。

srcPostureAttrs

アクセスルール内のポスチャ条件を評価する際に使用するデバイスポスチャ属性を、キーと値のペアとして指定します。
このフィールドが必要なのは、アクセスルールにデバイスポスチャ条件が含まれる場合のみです。

dst

srcユーザーが接続する、1つ以上の宛先を指定します。ユーザーのメールアドレス、グループ、タグ、またはIPアドレスにマッピングされたホストを指定できます。

accept

追加のチェックを必要とせずに、dstホスト上で拒否する、0個・1個、またはそれ以上のユーザー名を指定します。actionのacceptを参照してください。

check

srcユーザーが追加のチェックに合格した場合に、dstホスト上で拒否する、0個・1個、またはそれ以上のユーザー名を指定します。actionのcheckを参照してください。

deny

どのような状況であっても、dstホスト上で拒否する、0個・1個、またはそれ以上のユーザー名を指定します。

IPセット

IPセットは、IPアドレスのグループを管理するための仕組みです。IPアドレス、CIDR、ホスト、オートグループ、他のIPセットの集合をカプセル化できます。
IPセットの主な利点は、複数のネットワーク部分を1つのコレクションにグループ化できることです。これにより、個々のIPアドレス、ホスト、サブネットではなく、そのコレクションに対してアクセス制御ポリシーを適用できます。

詳しくは、IPセットのドキュメントを参照してください。

ネットワークポリシーオプション

ネットワークポリシーオプションは、すべてのプランで利用できます。

アクセスルールに加えて、tailnetポリシーファイルには、特殊な用途向けのネットワーク全体のポリシー設定がいくつか含まれています。ほとんどのネットワークでは、これらを指定する必要はないはずです。

derpMap

derpMapセクションを使うと、ネットワークにカスタムDERPサーバーを追加でき、デバイスは必要に応じてこれをトラフィックのリレーに使用します。
このセクションを使って、Tailscale提供のDERPサーバーの使用を無効にすることもできます。例えば、企業のコンプライアンス要件を満たすために、tailnet提供のDERPサーバーを無効にしたい場合があります。
詳しくは、カスタムDERPサーバーの実行を参照してください。

disableIPv4

disableIPv4フィールドの代わりに、CGNATの競合で説明されているdisable-ipv4ノード属性を使用することを推奨します。

disableIPv4フィールドをtrueに設定すると、デバイスへのTailscale IPv4アドレスの割り当てが停止します。
IPv4を無効にすると、ネットワーク内のすべてのデバイスは、Tailscale IPv6アドレスのみを受け取ります。
IPv6をサポートしないデバイス（例えば、OSでIPv6が無効になっているシステム）には到達できなくなります。
このオプションは、100.64.0.0/10というキャリアグレードNATアドレス範囲を、既存の用途と競合させて使用しているユーザーを対象としています。

OneCGNATRoute

OneCGNATRouteフィールドは、Tailscaleクライアントが生成するルートを制御します。

Tailscaleクライアントには、以下のいずれかを持たせることができます。

• デバイスのオンライン・オフラインに伴うルーティングテーブルの変動を避けるための、1つの大きな100.64/10ルート。（この変動は、macOS上のChromiumベースのブラウザに悪影響を与えます。）
• きめ細かな/32ルート。

OneCGNATRouteに指定できる値は、以下のとおりです。

• 空の文字列、または未指定: 各プラットフォームのデフォルトのヒューリスティクスを使用します。
  • macOS以外のすべてのプラットフォームでは、Tailscaleは各デバイスに対して、きめ細かな/32ルートを追加します。
  • macOS（Tailscale v1.28以降）では、Tailscaleは1つの100.64/10ルートを追加します。他のインターフェースもその範囲内のIPアドレスをルーティングしている場合、Tailscaleは1つの100.64/10ルートを使用しません。
• "mac-always": macOSクライアントは、常に1つの100.64/10ルートを追加します。
• "mac-never": macOSクライアントは、常にきめ細かな/32ルートを追加します。

randomizeClientPort

randomizeClientPortフィールドは、Tailscaleサポートに相談したうえで、一部のファイアウォールデバイスへの回避策としてのみ使用してください。

randomizeClientPortフィールドをtrueに設定すると、デバイスはデフォルトの静的ポート41641ではなく、WireGuardトラフィックにランダムなポートを使用します。