Google Cloud リソース階層は、リソースをツリー構造に整理する方法です。この階層は大規模なリソース管理に役立ちますが、組織構造、リージョン、ワークロード タイプ、コストセンターなど、一部のビジネス ディメンションをモデル化しているだけです。階層では複数のビジネス ディメンションを一緒にレイヤ化することはできません。
タグを使用すると、リソースのアノテーションを作成できます。場合によっては、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでポリシーの許可や拒否を行えます。リソース階層全体にわたるきめ細かい管理のために、タグとポリシーの条件付き適用を使用できます。
タグとラベル
ラベルは、リソースのアノテーションを作成する別個の方法です。次の表に、タグとラベルの違いをいくつか示します。
| タグ | ラベル | |
|---|---|---|
| リソース構造 | タグキー、タグ値、タグ バインディングはすべて個別のリソース | リソース自体ではなく、リソースのメタデータ |
| 定義 | 組織レベルまたはプロジェクト レベルで定義する | 各リソースによって定義される |
| アクセス制御 | タグの管理と取り付けには、Identity and Access Management（IAM）ロールが必要 | ラベルの取り付けには、サービス リソースに応じて異なる IAM のロールが必要です |
| 取り付けの前提条件 | タグがリソースに取り付け可能になる前にタグキーとタグ値を定義する必要があります | 取り付けの前提条件なし |
| 継承 | タグ バインディングは、 Google Cloud 階層内のリソースの子に継承されます | リソースの子には継承されない |
| 削除の要件 | タグのバインディングが存在しない場合を除き、タグを削除できない | リソースからいつでも削除可能 |
| 命名の要件 | タグ値とタグキーの要件 | ラベルの要件 |
| Key-Value 名の長さ | 最大 256 文字 | 最大 63 文字 |
| 許可ポリシーと拒否ポリシーのサポート | タグは、許可ポリシーの条件と拒否ポリシーの条件で参照できます。 | 許可ポリシーと拒否ポリシーのサポートなし |
| 組織のポリシーのサポート | 一部のリソースのタグは、組織のポリシーの条件付き制約で参照できます。 | 組織のポリシーのサポートなし |
| Cloud Billing の統合 | チャージバック、監査、その他の費用割り当て分析を実行し、Cloud Billing の費用データを BigQuery にエクスポートする | Cloud Billing でラベルごとにリソースをフィルタリングし、BigQuery に Cloud Billing データをエクスポートする |
ラベルの詳細については、ラベルの作成と管理をご覧ください。
タグの作成
タグは Key-Value ペアとして構成されます。タグキー リソースは、組織リソースまたはプロジェクト リソースの下に作成できます。タグ値はキーに関連付けられるリソースです（たとえば、値 production と development を持つタグキー environment など）。
タグの管理
管理者は、タグを作成、更新、削除、およびリソースに添付する権限を持つユーザーを制限することにより、タグの使用を制御できます。個々のタグを選択して、編集（値の追加や削除など）や説明の更新を行うことができます。これにより、タグをきめ細かく制御できます。
タグには、タグに関する情報を取得するときに表示される説明を付けることができます。説明は、リソースにタグを付加するユーザーがタグの目的を理解するのに役立ちます。
親プロジェクトまたは組織では、各タグキーは一意である必要があります。これにより、各タグ値がリソースにバインドされると、タグキーとの一意のペアが作成されます。
ポリシーとタグ
タグと IAM の条件を組み合わせて使用すると、次のことができます。
タグ値を作成したら、タグ値をリソースにバインドできます。その後、タグキーがリソースにバインドされているかどうかに基づいてリソースを識別する条件付きの IAM ポリシーを作成できます。タグと IAM 条件の使用については、タグと条件付きアクセスをご覧ください。
組織のポリシーを使用した必須タグの適用
組織のポリシーを使用して、リソースに必須タグを適用できます。必須タグを適用すると、組織のタグ付けポリシーに準拠するリソースのみを作成できます。つまり、リソースは、ポリシーで指定された必須タグキーのタグ値にバインドされます。詳細については、タグを適用するカスタム制約を設定するをご覧ください。
必須タグの適用は、次のリソースタイプでサポートされています。
- Resource Manager のプロジェクトとフォルダ
- Filestore インスタンス
- AlloyDB for PostgreSQL クラスタとバックアップ リソース
- Workflows ワークフロー
タグの継承
タグ値がリソースに付加されると、デフォルトで、そのリソースのすべての子孫が同じタグ値を継承します。子孫リソースで、継承されたタグ値をオーバーライドできます。継承されたタグ値をオーバーライドするには、別のタグ値を子孫リソースにバインドします。異なるタグ値には、継承されたタグ値と同じタグキーを使用する必要があります。
たとえば、environment: development タグを適用したフォルダに team-a と team-b という名前の 2 つの子フォルダがあるとします。別のタグ environment: test を team-b フォルダに適用することもできます。その結果、team-a フォルダのプロジェクトと他のリソースは environment: development タグを継承しますが、team-b フォルダのプロジェクトと他のリソースは environment: test タグを継承します。
team-b フォルダから environment: test タグを削除すると、そのフォルダとリソースはタグ environment: development を継承します。
リソースによって添付され、継承されるすべてのタグは、集合的に効果的なタグと呼ばれます。リソースで有効なタグは、直接接続されているタグと、階層全体でリソースの祖先のすべてに添付されているすべてのタグを組み合わせたものです。
IAM 条件でタグを使用する場合は、IAM 条件で使用されるタグキーごとに安全なデフォルトのタグ値を作成することをおすすめします。安全なデフォルトのタグ値を組織にバインドして、組織内のすべてのリソースに継承されるようにします。関連するリソースで継承されたバインディングを明示的にオーバーライドすることによってのみ、タグ値を変更します。たとえば、enforcement タグキーのタグ値 on に依存する IAM 条件があり、タグキーに off タグ値もあるとします。タグ値 enforcement: off を組織にバインドして、組織内のすべてのリソースに継承される安全なデフォルトを作成します。組織内の選択したリソースに対してのみ、タグ値 enforcement: on をバインドします。
次に、enforcement: on または enforcement: off の場合はリソースの、enforcement: default の場合はセーフケースの効果を持つ条件で、enforcement タグキーに対応するポリシーを記述します。enforcement タグキーがリソースから削除された場合、リソースは親リソースから enforcement のタグ値を継承できます。enforcement タグキーを持つ親リソースがない場合、リソースは組織リソースから enforcement: default を継承します。
セーフ デフォルトタグを使用すると便利ですが、意図しない動作を回避するために、リソースの移動やタグの削除を行う前に、タグと条件付きポリシーを確認することをおすすめします。
タグのキーと値の削除
タグ値を削除する前に、そのタグ値を使用しているすべてのリソース バインディングを削除する必要があります。
タグ値を削除から保護する
タグ保留をタグ値に適用することで、タグ値の保護レイヤを追加できます。タグ バインディングと同様に、タグホールドによりユーザーがタグ値を削除できなくなります。
一部のリソースでは、リソースに接続されたタグ値ごとにタグホールドが自動的に作成されます。タグ値を削除するには、このタグホールドを削除する必要があります。
次のステップ
- タグの使用方法の詳細については、タグの作成と管理ページをご覧ください。
- Compute Engine でタグを使用する方法については、リソースのタグの管理をご覧ください。
- ファイアウォール ポリシーにセキュアタグを使用する方法については、セキュアタグの作成と管理をご覧ください。