Google Cloud リソース階層は、リソースをツリー構造に整理する方法です。この階層は大規模なリソース管理に役立ちますが、組織構造、リージョン、ワークロード タイプ、コストセンターなど、一部のビジネス ディメンションをモデル化しているだけです。階層では複数のビジネス ディメンションを一緒にレイヤ化することはできません。
タグを使用すると、リソースのアノテーションを作成できます。場合によっては、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでポリシーの許可や拒否を行えます。リソース階層全体にわたるきめ細かい管理のために、タグとポリシーの条件付き適用を使用できます。
タグとラベル
ラベルは、リソースのアノテーションを作成する別個の方法です。次の表に、タグとラベルの違いをいくつか示します。
| タグ | ラベル | |
|---|---|---|
| リソース構造 | タグキー、タグ値、タグ バインディングはすべて個別のリソース | リソース自体ではなく、リソースのメタデータ |
| 定義 | 組織レベルまたはプロジェクト レベルで定義する | 各リソースによって定義される |
| アクセス制御 | タグの管理と取り付けには、Identity and Access Management(IAM)ロールが必要 | ラベルの取り付けには、サービス リソースに応じて異なる IAM のロールが必要です |
| 取り付けの前提条件 | タグがリソースに取り付け可能になる前にタグキーとタグ値を定義する必要があります | 取り付けの前提条件なし |
| 継承 | タグ バインディングは、 Google Cloud 階層内のリソースの子に継承されます | リソースの子には継承されない |
| 削除の要件 | タグのバインディングが存在しない場合を除き、タグを削除できない | リソースからいつでも削除可能 |
| 命名の要件 | タグ値とタグキーの要件 | ラベルの要件 |
| Key-Value 名の長さ | 最大 256 文字 | 最大 63 文字 |
| 許可ポリシーと拒否ポリシーのサポート | タグは、許可ポリシーの条件と拒否ポリシーの条件で参照できます。 | 許可ポリシーと拒否ポリシーのサポートなし |
| 組織のポリシーのサポート | 一部のリソースのタグは、組織のポリシーの条件付き制約で参照できます。 | 組織のポリシーのサポートなし |
| Cloud Billing の統合 | チャージバック、監査、その他の費用割り当て分析を実行し、Cloud Billing の費用データを BigQuery にエクスポートする | Cloud Billing でラベルごとにリソースをフィルタリングし、BigQuery に Cloud Billing データをエクスポートする |
ラベルの詳細については、ラベルの作成と管理をご覧ください。
セマンティック タグ
セマンティック タグは、OpenTelemetry(OTel)規約に裏付けられた強力で標準化されたセマンティクスを使用して、リソースに意味のあるメタデータを提供する Key-Value ペアです。
App Hub リソースでセマンティック タグを使用できます。App Hub でサービスとワークロードの属性を設定すると、App Hub はそれらを基盤となる直接のリソースの読み取り専用のシステム セマンティック タグとして自動的に複製します。
システム セマンティック タグは読み取り専用です。Tags API または Google Cloud コンソールを使用して、これらのシステムタグを直接編集または削除することはできません。タグ管理は App Hub 内で行われます。
App Hub で複製されたセマンティック タグ
App Hub を使用すると、サービスまたはワークロードに設定された [Environment] 属性と [Criticality] 属性が、専用の Namespace google:AppHub の読み取り専用のシステム セマンティックタグとして自動的に複製されます。
サポートされているシステムタグは次のとおりです。
google:AppHub/environment: App Hub から派生した値(PRODUCTIONやSTAGINGなど)。google:AppHub/criticality: App Hub から派生した値(MISSION_CRITICALやHIGHなど)。
App Hub のコンテキストをシステムタグとして公開することで、 Google Cloud コンソールなどのダウンストリーム サービスは、信頼できるメタデータを使用して、手動構成に関連するリスクを回避しながら、ガバナンスとセキュリティのポリシーを適用できます。
セマンティック タグの管理の詳細については、セマンティック タグの表示と管理をご覧ください。
セマンティック カタログ
セマンティック カタログには、使用可能なセマンティクスのリストと、OpenTelemetry(OTel)のバックエンド属性へのマッピングが用意されています。このカタログは、 Google Cloud コンソールで閲覧できます。また、API を使用して詳細を表示することもできます。
カタログへのアクセスについて詳しくは、セマンティック カタログを表示するをご覧ください。
| セマンティクスのキー | OTel 属性のキー | セマンティクスの値 | OTel 属性値 |
|---|---|---|---|
ENVIRONMENT |
deployment.environment.name |
PRODUCTION |
production |
STAGING |
staging |
||
TEST |
test |
||
DEVELOPMENT |
development |
||
CRITICALITY |
service.criticality |
MISSION_CRITICAL |
critical |
HIGH |
high |
||
MEDIUM |
medium |
||
LOW |
low |
セマンティック タグの制限事項
セマンティック タグには次の制限があります。
- カスタム バインディング: Tags API を使用して、
ENVIRONMENTまたはCRITICALITYセマンティック タグをリソースまたは Resource Manager ノード(プロジェクト、フォルダ、組織)に直接バインドすることはできません。 - ユーザー定義のセマンティクス: 既存のタグをセマンティック タグに昇格させることはできません。
- 直接リソースのみ: 同期は、App Hub に登録されている直接リソースにのみ適用されます。サービスまたはワークロード内のネストされたリソースや間接リソース(MIG 内の個々の VM など)には伝播されません。
タグの作成
タグは Key-Value ペアとして構成されます。タグキー リソースは、組織リソースまたはプロジェクト リソースの下に作成できます。タグ値はキーに関連付けられるリソースです(たとえば、値 production と development を持つタグキー environment)。
タグの管理
管理者は、タグを作成、更新、削除、およびリソースに添付する権限を持つユーザーを制限することにより、タグの使用を制御できます。個々のタグを選択して、編集(値の追加や削除など)や説明の更新を行うことができます。これにより、タグをきめ細かく制御できます。
タグには、タグに関する情報を取得するときに表示される説明を付けることができます。説明は、リソースにタグを付加するユーザーがタグの目的を理解するのに役立ちます。
親プロジェクトまたは組織では、各タグキーは一意である必要があります。これにより、各タグ値がリソースにバインドされると、タグキーとの一意のペアが作成されます。
ポリシーとタグ
タグと IAM の条件を組み合わせて使用すると、次のことができます。
タグ値を作成したら、タグ値をリソースにバインドできます。その後、タグキーがリソースにバインドされているかどうかに基づいてリソースを識別する 条件付きの IAM ポリシーを作成できます。タグと IAM 条件の使用については、タグと条件付きアクセスをご覧ください。
タグの変更による影響
タグを使用して条件付きでアクセスを許可または拒否する場合や、組織のポリシーのスコープを設定する場合、リソースへのタグのバインドまたはバインド解除を行うと、これらのポリシーの影響が変更される可能性があります。
たとえば、開発に使用される Compute Engine インスタンスのみを管理する必要がある開発者のグループがあるとします。
- タグ定義: 値
devとprodを持つタグキー123456789012/envがあります。 - 条件付きアクセス: 開発者グループに Compute インスタンス管理者ロール(
roles/compute.instanceAdmin)を付与します。リソースにタグenv: devがある場合にのみアクセスを許可する条件をロール バインディングに追加します。 - 変更の影響:
- タグのバインド: タグ
env: devをインスタンスに適用します。条件付きロール バインディングにより、デベロッパーはインスタンスを管理できるようになりました。 - タグのバインド解除: 後で、同じインスタンスが本番環境に昇格されます。
env: devタグのバインドを解除し、env: prodタグをバインドします。条件付きロール バインディングでは、デベロッパーにこのインスタンスの管理権限が付与されなくなりました。
- タグのバインド: タグ
通常、タグの変更は 2 分以内に有効になります。ただし、変更がシステム全体に反映されるまでに最大 7 分かかることがあります。この伝播遅延は、アクセス権の付与または取り消しの速さ、またはタグのバインディングまたはバインディング解除後に組織のポリシーが有効になる速さに影響します。
組織のポリシーを使用した必須タグの適用
カスタムの組織のポリシーを使用して、リソースに必須タグを適用できます。必須タグを適用すると、組織のタグ付けポリシーに準拠するリソースのみを作成できます。つまり、リソースは、ポリシーで指定された必須タグキーのタグ値に関連付けられます。詳細については、タグを適用するカスタム制約を設定するをご覧ください。
必須タグの適用は、次のリソースタイプでサポートされています。
- Resource Manager のプロジェクトとフォルダ
- Filestore インスタンス
- AlloyDB for PostgreSQL クラスタとバックアップ リソース
- Workflows ワークフロー
- Compute Engine リソース:
- インスタンス
- ディスク
- 外部 VPN ゲートウェイ
- VPN ゲートウェイ
- ターゲット VPN ゲートウェイ
- VPN トンネル
- 相互接続
- 相互接続のアタッチメント
- バックエンド サービス
- リージョン バックエンド サービス
- バックエンド バケット
- VPC リソース:
- ネットワーク
- サブネットワーク
- ファイアウォール ルール
- ルート
タグの継承
タグ値がリソースに付加されると、デフォルトで、そのリソースのすべての子孫が同じタグ値を継承します。継承されたタグ値は、子孫リソースでオーバーライドできます。継承されたタグ値をオーバーライドするには、別のタグ値を子孫リソースにバインドします。異なるタグ値には、継承されたタグ値と同じタグキーを使用する必要があります。
たとえば、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 でタグを使用する方法については、リソースのタグの管理をご覧ください。
- ファイアウォール ポリシーにセキュアタグを使用する方法については、セキュアタグの作成と管理をご覧ください。