Tailscaleロゴ

タグでデバイスをグループ化する

非ユーザーデバイスを認証・識別するためのタグ

最終検証日：
翻訳: 竹洞 陽一郎

タグは、すべてのプランで利用できます。
すべてのプランに50台のタグ付きデバイスが含まれます。50台を超えるタグ付きデバイスが必要な場合は、営業チームにお問い合わせください。

Tailscaleのタグ（tag）は、サーバーやEphemeralノード（ephemeral nodes）など、非ユーザーデバイスを認証・識別するための仕組みです。
タグには2つの主な目的があります。非ユーザーデバイスにアイデンティティを付与すること、そして「用途（purpose）」に基づいてアクセス制御ポリシーを管理できるようにすることです。
ここでいう用途とは、Webサーバーのホスティングから、特定の地域の従業員向けのサブネットルーターとしての役割まで、さまざまなものが含まれます。

タグは基本的にサービスアカウントですが、より柔軟性があります。1台のデバイスに複数のタグを割り当てて、複数の用途に対応させることができます。
例えば、PostgreSQLデータベースを実行しつつ、内部アクセス用のWebサーバーとしても機能するデバイスがあるとします。
このような場合、そのデバイスに次のタグを割り当てられます（それぞれをアクセス制御ポリシーで個別にターゲットにできます）。tag:postgresql、tag:internal-access、tag:web-serverです。

タグには、次のような特徴もあります。

要件

タグは無料機能であり、すべての料金プランで利用できます。
ただし、タグに関連する一部の操作を行うには、権限が必要です。

制限事項

タグには、以下の制限と制約があります。

ユースケース

タグは、特定のユーザーに紐付けたくないデバイス（Webアプリケーションをホストするサーバーなど）を管理するのに適しています。
ユーザーを削除すると、そのユーザーが持つすべてのデバイスも削除されるためです。
サービスを提供するデバイスをユーザーに紐付けていると、そのユーザーを削除した際にそのデバイスも失われます。
代わりにタグでデバイスを管理していれば、ユーザーを削除してもデバイスには影響しません。
ユーザーデバイスをユーザーアカウントに関連付けるためにタグを使わないでください。
タグは、個々のユーザーをデバイスに紐付けるようには設計されていません。
サービスアカウントの役割を持つデバイスを管理することを目的としています。
タグをユーザーの代替として使うと、ユーザーを削除してもそのユーザーのデバイスがネットワーク上に残ってしまうため、セキュリティ上のリスクになります。

タグは、複数のユーザーが1台のデバイスを管理できるようにする方法でもあります。
ユーザーでデバイスを管理する場合、各デバイスを1人のユーザーに紐付ける必要があり、共有リソースをホストするデバイスには適していません。
一方、タグでデバイスを管理する場合は、1つ以上のタグに対して複数のユーザーをタグオーナーとして割り当てられます。
これらのユーザーは、自分がオーナーであるタグを持つすべてのデバイスを管理できます。

タグに関する注意事項
タグは、人間ではないマシンにのみ使用してください。
ユーザーは、指定されたユーザーアカウントを通じてのみTailscaleにアクセス・利用できます。
デバイスはユーザーとタグを同時に持てないため、ユーザーデバイスへの注釈としてタグを使うことは望ましくありません。
デバイスにタグを追加すると、関連付けられていたユーザーは解除されます。
デバイスは、タグかユーザーアカウントのどちらか一方のみを持てます。

タグを使うべき場面:

タグを使うべきではない場面:

オーナーシップ

tailnetポリシーファイルには「タグ」専用のセクションはありません。
代わりに、tailnetポリシーファイルのtagOwnersセクションで、タグをそのオーナーによって定義します。
タグのオーナーのみが、Tailscaleネットワーク（tailnetと呼ばれます）内のデバイスにそのタグを適用できます。
タグオーナーには、ユーザー、グループ、さらには他のタグを設定でき、これにより複雑なタグのオーナーシップ階層を作成できます。

タグ付きデバイスのアイデンティティは、そのデバイスに設定されたすべてのタグの組み合わせです（積集合ではありません）。
デバイスには任意の数のタグを割り当てられ、各タグの権限を個別に管理できます。
例えば、tag:postgresql、tag:prod、tag:ci-cdのタグを持つデバイスがある場合、これらのタグのいずれか1つに対するアクセス制御ポリシーが、そのデバイスに適用されます。

Owner、Admin、Network adminは、タグオーナーでなくても、任意のタグを適用できます。

タグ認証とユーザー認証の違い

タグは、ユーザー認証と並列の仕組みです。
ユーザーアカウントと同じ役割を果たしますが、Webサーバーやアプリコネクタのような、サービスベースのデバイスを対象としている点が異なります。
そのため、同一デバイス上にユーザーアカウントのアイデンティティとタグのアイデンティティが同時に存在することはできません。
以前ユーザーアカウントで認証されていたデバイスにタグを適用すると、そのユーザーアカウントは解除されます。
同様に、ユーザーアカウントでデバイスを認証すると、そのデバイスからすべてのタグが削除されます。

タグは非ユーザーデバイス向けであるため、MacBookやモバイルデバイスなどのエンドユーザーデバイスの認証には適さない性質と制約があります。
例えば、タグベースのアイデンティティを持つデバイスは、ユーザーベースのアイデンティティを持つデバイスへSSH接続できません。

キーの有効期限

デバイスに初めてタグを適用して認証すると、そのタグ付きデバイスのキーの有効期限はデフォルトで無効になります。
2022年3月10日より前にタグ付けされたデバイスを再認証した場合も、有効期限はデフォルトで無効になります。
管理コンソール、Tailscale CLI、Tailscale APIからデバイスのタグを変更しても、再認証しない限りキーの有効期限は変わりません。再認証すると、Tailscaleはそのデバイスのキーの有効期限を無効にします。
デバイスのキーの有効期限は、管理コンソールのMachinesページから、またはTailscale APIを使って有効化・無効化できます。

Tailscaleエコシステムにおけるタグ

tailnetの多くの側面と同様に、タグもtailnetポリシーファイルで定義・管理します。
エンドユーザーデバイスの認証には使用できないという制約はありますが、Exit Node、サブネットルーター、アプリコネクタ、ACL、グラントなど、他のほぼすべてのTailscale機能とシームレスに連携します。

Exit Node

デバイスをExit Nodeとして使うと、他のtailnetデバイスは、そのデバイス経由ですべてのインターネットトラフィックをルーティングできるようになります。
Exit Node経由ですべてのトラフィックをルーティングすることで、インターネットトラフィックを暗号化し、内部ネットワークへアクセスできます。
例えば、社内オフィスでデバイスをExit Nodeとして運用できます。
これにより、従業員はそのExit Nodeを使うことで、社内オフィスの内部ネットワークへアクセスできます。
エンドユーザーデバイスもExit Nodeとして機能できますが、Exit Nodeにはタグベースのアイデンティティを使うのが一般的です。

サブネットルーター

サブネットルーターは、tailnet内の他のデバイスに対してサブネットルートをアドバタイズするために使う、tailnetデバイスです。
サブネットルーター以外のデバイスにTailscaleクライアントをインストールすることなく、サブネット全体をtailnetに追加できる優れた方法です。
エンドユーザーデバイスもサブネットルーターとして機能できますが、サブネットルーターにはタグベースのアイデンティティを使うのが一般的です。

アプリコネクタ

アプリコネクタ（app connector）は、tailnet内でアプリ固有のトラフィックをルーティングするデバイスです。
アプリコネクタとして動作するデバイスは、厳密にサービスベースのデバイスです。
そのため、アプリコネクタとして使用するデバイスの認証には、タグベースのアイデンティティを使う必要があります。

アクセス制御

タグを使うと、tailnet内のサービスベースのデバイスを選択・ターゲットして、ACLやグラントでアクセス制御ポリシーを作成できます。
Tailscaleは、割り当てられたタグのいずれか1つでタグ付きデバイスを識別できるため、多くのタグを持つデバイスに適用されるアクセス制御ポリシーは複雑になる可能性があります。
そのため、tailnet内でタグをどのように活用・管理しているかを明確に文書化しておくことがベストプラクティスです。

ACL

アクセス制御リスト（ACL）の一部としてタグを使うと、どの種類のデバイス同士が通信できるべきかを管理しやすくなります。
例えば、本番サーバーと本番データベース用にtag:prodというタグを使い、tag:prodタグを持つすべてのデバイス同士が通信できるようにする、といった使い方ができます。

次のtailnetポリシーファイルの例は、tag:prodタグが付いたすべてのデバイス同士の通信を許可します。 

{
  "acls": [
    {
      "action": "accept",
      "src": ["tag:prod"],
      "dst": ["tag:prod:*"],
    },
  ],
}

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

また、テスト（tests）を使うことで、タグ付きデバイス用のACLが期待通りに動作するかを確認できます。
テストは、tailnetポリシーファイルを保存・適用する前に検証します。

例えば、tag:sreグループのユーザーがtag:prodタグの付いたデバイスへアクセスできることを確認するために、次のようなACLを記述できます。 

"tests": [
  {
    "src": "group:sre",
    "accept": ["tag:prod:1234"],
  },
],

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

グラント

ACLと同様に、グラントでもタグを使って、タグ付きデバイスのグループをターゲットにできます。
次の例は、tag:prodタグを持つデバイスに、tag:tailsqlタグを持つデバイスへのアクセスを許可します。 

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

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

オートグループ

オートグループ（Autogroups）は、カスタムグループとして作成するのが難しい、tailnet内のデバイスの定義済みグループです。
これらのオートグループの1つであるautogroup:taggedは、タグベースのアイデンティティを持つすべてのデバイスを選択します。
autogroup:taggedを使って、IPセットやカスタムグループを定義することはできません。

高度なタグ階層

タグオーナーの指定は、設計上柔軟に行えます。
デバイスには必要な数だけタグオーナーを割り当てられ、タグオーナーにはユーザー、グループ、または他のタグを設定できます。
あるタグを別のタグのオーナーとして設定できるため、複雑なタグオーナーシップの階層を作成することも可能です。
そのため、タグの使い方を明確に文書化し、アクセス制御ポリシーのテストなどのツールを使ってタグを監査することがベストプラクティスです。

ベストプラクティス

タグを効果的に活用するために、以下のベストプラクティスを検討してください。

タグ名の一般的なパターン

タグを使うと、組織の要件に基づいたアクセスパターンとネットワークセグメントを反映できます。
これらのアクセスパターンとネットワークセグメントは、通常いくつかの一般的なカテゴリに分類されます。
これらのカテゴリに基づいて一貫したタグ名のパターンを使うことで、アクセス制御ポリシーを長期的に理解・保守しやすくなります。
タグ名で検討すべき一般的なアクセスのカテゴリには、以下のようなものがあります。

デバイスには多くのタグを割り当てられますが、アクセスルールにおいてタグは「結合」されません。
例えば、tag:prodとtag:databaseの両方を持つデバイスへのアクセスを許可するルールを定義することはできません。
代わりに、このようなセグメント化されたアクセスパターンを表現するには、tag:prod-databaseのような複合タグを使えます。
以下に、複合タグの例をいくつか示します。

複合タグの例
タグ アクセス制御
tag:prod-app 本番環境のアプリケーションサーバーへ
tag:nonprod-db 非本番環境のデータベースサーバーへ
tag:prod-app-finance-reporting 本番環境の財務レポートアプリケーションへ
tag:prod-emea-app-support-console EMEAの本番環境のサポートコンソールアプリケーションへ
tag:prod-asiasouth-ingest-logging 南アジアの本番環境のログ取り込みエンドポイントへ

タグを扱う

タグの扱い方について詳しくは、以下のセクションを参照してください。

タグを定義する

デバイスにタグを割り当てる前に、tailnetポリシーファイルでそのタグを作成し、誰がそのタグを使ってデバイスを認証できるかを定義する必要があります。
タグは、tailnetポリシーファイルのtagOwnersセクションで定義することで作成します。

次の例は、tag:serverタグを作成し、dave@example.comを唯一のオーナーとして割り当てます。
このタグを適用できるのは、そのタグオーナーのみです。 

{
  "tagOwners": {
    "tag:server": ["dave@example.com"], // dave@example.comはtag:serverタグでデバイスを認証できます
  }
}

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

Tailscaleはタグ名の大文字・小文字を区別せず、tailnetポリシーファイル内のすべてのタグを小文字として解釈します。

タグオーナーを定義する

タグの権限をデバイスに付与できるのが誰かを、明示的に定義する必要があります。
タグオーナーは、tailnetポリシーファイルのtagOwnersセクションで定義できます。

tailnetポリシーファイルでは、タグのオーナーリストを空にすることもできます。
すべてのタグは、tailnetのOwner、Admin、Network adminによって暗黙的に所有されます。
これらのユーザーは、管理コンソールから、また認証キーの一部として、これらのタグをデバイスに適用できます。

次の例は、タグオーナーが設定されていないtag:infrastructureを示しています。 

{
  "tagOwners": {
    "tag:server": ["dave@tailscale.com"],
    "tag:infrastructure": [], // タグオーナーが定義されていません
  }
}

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

デバイスにタグを適用する

デバイスへのタグ付けは、管理コンソール、Tailscale CLI、Tailscale APIのいずれかを使って行えます。
デバイスを再認証してタグ付けすると、そのデバイスの新しいノードキー（node key）が生成されます。デバイスのTailscale IPアドレスは変更されません。

管理コンソールでデバイスにタグを適用する

管理コンソールからデバイスにタグを付けるには、tailnetのOwner、Admin、Network adminのいずれかである必要があります。
現在のユーザーが自動的にデバイスの認証に使われるため、再認証する必要はありません。

管理コンソールからデバイスにタグを付けるには、以下の手順で行います。

  1. 管理コンソールのMachinesページを開きます。
  2. 対象のデバイスに対応する行を見つけます。
  3. 右端の省略記号（…）アイコンのメニューを選択し、Edit tagsオプションを選択します。
  4. 必要なタグを追加、変更、または削除します。タグを適用するには、そのタグがtailnetポリシーファイルにあらかじめ存在している必要があります。
  5. Saveを選択してタグを適用します。

Owner、Admin、Network adminは、そのタグを所有していなくても、管理コンソールから任意のタグを適用できます。
デバイスにはアイデンティティが必要なため、管理コンソールからタグ付きデバイスのすべてのタグを削除することはできません。デバイスに新しいタグを割り当てるか、デバイスからTailscaleを再認証してください。

CLIでデバイスにタグを適用する

Tailscale CLIを使って、Linux、macOS、Windowsで動作するデバイスのタグを追加・削除できます。
その他のデバイスにタグを付けるには、管理コンソールを使ってください。

CLIを使ってデバイスにタグを割り当てるには、--advertise-tags=tag:<tag-name>フラグを付けてtailscale loginコマンドを実行します。 

sudo tailscale login --advertise-tags=tag:server

デバイスに複数のタグを割り当てるには、複数のタグをカンマ区切りで--advertise-tagsフラグに渡します。 

sudo tailscale login --advertise-tags=tag:server,tag:development

デバイスからすべてのタグを削除するには、値を指定せずに--advertise-tags=フラグを使います。 

sudo tailscale login --advertise-tags=

デバイスが認証キーを使用している場合、--advertise-tagsフラグでタグを削除することはできません。代わりに、新しいタグセットで新しい認証キーを生成してください。

デバイスがすでに別のユーザーで認証されている場合、サインイン中のユーザーを変更する必要があるかもしれません。
現在のユーザーで再認証するには、tailscale upコマンドに--force-reauthフラグを追加します。 

sudo tailscale up --advertise-tags=tag:server --force-reauth

APIでデバイスにタグを適用する

Update device tagsメソッドを使って、Tailscale APIからデバイスにタグを適用できます。

この方法でタグを適用するには、デバイスに対してPOSTリクエストを送信し、ボディに希望するタグを指定します。例: 

curl https://api.tailscale.com/api/v2/device/11055/tags \
-u "tskey-<key>" \
-H "Content-Type: application/json" \
--data-binary '{"tags": ["tag:foo", "tag:bar"]}'

別のタグからタグを適用する

認証時に、認証キーに含まれるものとは異なるタグを適用することもできます。
ただし、その場合はデバイスの既存のタグが置き換えられます。

OAuth認証における重要事項: OAuthクライアントまたは認証キーがデバイスにタグを割り当てる場合、リクエストされたタグは、そのOAuthクライアントまたは認証キーが持つタグの完全なセットと厳密に一致するか、またはリクエストされた各タグが、tagOwnersセクションで定義された認証エンティティのタグのいずれかによって所有されている必要があります。
厳密一致のチェックではtagOwnersは参照されず、リクエストされたタグが認証エンティティのタグと同一であるかのみを検証します。
タグのサブセットを適用する場合を含め、それ以外の組み合わせでは、tagOwnersで明示的にオーナーシップを設定する必要があります。

別のタグからタグを適用する仕組みは、多くのサーバーにタグを付ける必要がある大規模なインフラのデプロイで、通常デプロイツールを使う場合に役立ちます。
例えば、デプロイシステムにtag:deployment-1というタグを付け、そのタグにtag:prod-2とtag:test-2の両方のオーナー権限を持たせることができます。 

"TagOwners": {
  "tag:deployment-1": ["alice@tailscale.com"],
  "tag:prod-2": ["tag:deployment-1"],
  "tag:test-2": ["tag:deployment-1"],
},

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

この構成では、tag:deployment-1を持つOAuthクライアントは、tag:prod-2またはtag:test-2のどちらもデバイスに適用できます。
tag:prod-2のみを持つOAuthクライアントも、タグが厳密に一致するためtag:prod-2を適用できます。
ただし、OAuthクライアントが複数のタグを持ち、そのうちの一部のみを適用したい場合は、リクエストされた各タグが認証エンティティのタグのいずれかによって所有されている必要があります。
これに対応するには、タグ自身をそのオーナーとして追加します。 

"TagOwners": {
  "tag:deployment-1": ["alice@tailscale.com"],
  "tag:prod-2": ["tag:deployment-1", "tag:prod-2"],
  "tag:test-2": ["tag:deployment-1", "tag:test-2"],
},

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

tag:deployment-1タグを持つ認証キー<key-1>を生成し、デプロイツールで使えるようにします。
その後、デプロイするワークロードに応じて、システムはデバイスを認証し、適切なインフラタグを適用することで、正しいアクセス制御を適用します。
新しい本番サーバーを起動する際、デプロイツールはそのデバイスにtag:prod-2タグを付けることができます。 

sudo tailscale up --auth-key=<key-1> --advertise-tags=tag:prod-2