タグ付けの概要

タグ・タイプ

Private Cloud Applianceは、次の2種類のタグをサポートしています:

「フリー・フォーム・タグ」が作成され、ユーザーによってリソースに適用されます。管理されていないメタデータが含まれます。
「定義済タグ」は、タグ付けの構造化アプローチを提供します。管理者はメタデータを作成および管理しますが、ユーザーはリソースにタグを適用する権限のみを持ち、場合によっては値を追加します。

タグ付け機能のほとんどには、定義済タグが必要です。これらは、適用されたメタデータが、リソースの管理、正確な情報の収集および特定の操作の自動化に対して信頼性が確保されます。定義済タグを使用すると、次のシナリオが可能になります:

コンパートメント内のすべてのリソースに適用されるデフォルト・タグの作成。
ユーザーがコンパートメントにリソースを正常に作成するために、リソースにタグを適用する必要があることを指定します。
定義済タグを使用して入力ミスを作成する場合は、タグを編集または削除して修正します。定義済のタグを削除すると、そのタグのキーと値はすべてのリソースから削除されます。
定義済の値のリストを定義済タグに関連付けます。
システム変数を使用して、定義済タグまたはタグのデフォルトの値を自動的に生成します。

フリー・フォーム・タグと定義済タグの両方をテナンシ内で同時に使用できます。次の表に、2つのタイプの機能比較を示します。

機能	フリーフォーム・タグ	定義されたタグ
階層	フリー・フォーム・タグはキーと値で構成されますが、ネームスペースに属しません。	定義済タグは、タグ・ネームスペース、キーおよび値で構成されます。
作成およびアプリケーション	フリー・フォーム・タグは、リソースの作成中または既存のリソースに適用できます。	タグ・ネームスペースおよびタグ・キー定義は、管理者によって事前に設定する必要があります。定義済タグは、リソースの作成時または既存のリソースに適用できます。
事前定義のキーと値	サポートされていません。	定義済タグを適用する場合、ユーザーはタグ・キーのリストから選択します。管理者は、タグ・キーに関連付ける事前定義済の値のリストを作成することもできます。リソースにタグを適用する場合、ユーザーはそのリストから値を選択する必要があります。
変数	サポートされていません。	変数は、定義されたタグの値を設定するために使用されます。ユーザーがタグを適用すると、変数は解決され、それが表すデータと置き換えられます。
大文字/小文字の区別	フリー・フォーム・タグのキーと値の両方で大文字と小文字が区別されます。	定義済タグでは、キーでは大文字と小文字は区別されず、タグ値のみが大文字と小文字が区別されます。

フリー・フォーム・タグを使用すると、ユーザーは、リソースのメタデータに関連する情報を迅速かつ簡単に含めることができます。ただし、次の制限事項に注意してください:

フリー・フォーム・タグを適用する場合、既存のフリー・フォーム・タグのリストを表示できないため、すでに使用されているタグと値が不明です。テナンシで使用されているフリー・フォーム・タグをリストすることはできません。 OCI CLIでは、一連のリソースをリストし、それらに適用されたフリー・フォーム・タグを表示できます。
フリー・フォーム・タグに基づいてリソースへのアクセスを制御することはできません。 IAMポリシー・ステートメントでは使用できません。
フリー・フォーム・タグでは、事前定義済のタグ値またはタグ変数を使用できません。

定義済タグによる分類

この項では、定義済タグの動作方法および必要な権限について説明します。

タグ・ネームスペースおよびキー

定義済タグにより、フリー・フォーム・タグより多くの機能やコントロールが提供されます。定義済のタグ・キーを作成する前に、まずそれに対して「タグ・ネームスペース」を設定します。タグ・ネームスペースは、「タグ・キー」のセットのコンテナと考えることができます。各ネームスペース内で、タグ・キーは一意である必要がありますが、タグ・キー名はネームスペース間で繰り返すことができます。タグ・キー定義を作成する場合は、値のタイプを選択する必要があります。これにより、タグを適用するユーザーが値を追加する方法も決まります:

ユーザーが値を入力できるように空のままにできます。
ユーザーが値から選択できるように値リストを作成できます。

定義済のタグをリソースに適用するには、まずタグ・ネームスペースを選択し、次にネームスペース内のタグ・キーを選択し、次に値を割り当てることができます。タグ・キーに空白値が含まれている場合、ユーザーは値を入力することも、空白のままにすることもできます。タグ・キーにリストが含まれている場合は、リストから値を選択する必要があります。

定義済タグでは、誰が定義済タグを適用できるかを制御できるポリシーがサポートされています。タグ・ネームスペースは、ポリシーを適用できるエンティティです。管理者は、各ネームスペースを使用できるユーザーのグループを制御できます。

定義済タグを使用するための権限

タグ・ネームスペースおよびキー定義の設定と管理は、管理者の責任です。タグ・ネームスペースの完全な管理権限が必要です。

リソースの定義済タグを適用、更新または削除するには、操作する必要があるタグ・ネームスペースに対するuseアクセス権がユーザーに付与されている必要があります。ユーザーは、タグを適用するリソースを更新する権限も持っている必要があります。多くのリソースでは、更新権限はuse動詞で付与されます。たとえば、CompartmentAでuseインスタンスを実行できるユーザーは、それらのインスタンスの定義済タグを適用、更新または削除することもできます。 use動詞で更新権限を含まないリソースの場合、manage動詞からの更新権限のみを付与するポリシー・ステートメントを作成できます。

次に、タグ付けに関連するポリシー・ステートメントの例を示します:

管理者は、タグ・ネームスペースおよびキーの定義を許可する必要があります。
```
Allow group TagAdmins to manage tag-namespaces in tenancy
```

ユーザーには、テナンシ内のすべてのネームスペースまたはサブセットからタグを適用する権限が付与されます。

Allow group GroupA to use tag-namespaces in tenancy

または

Allow group GroupA to use tag-namespaces in tenancy where target.tag-namespace.name='Operations'

または

Allow group GroupA to use tag-namespaces in tenancy where any {target.tag-namespace.name='Operations', target.tag-namespace.name='Support'}

ユーザーには、タグを適用するためにリソースを更新する権限が付与されます。

Allow group GroupA to use instance-family in compartment CompartmentA

または

Allow group GroupA to use vcns in compartment CompartmentA
Allow group GroupA to manage vcns in compartment CompartmentA where request.permission='VCN_UDPATE'

タグ管理機能

この項では、タグ・ネームスペースおよびキー定義を設定および管理する管理者が使用できる操作について説明します。

タグ定義の廃止と再アクティブ化

タグ・キー定義またはタグ・ネームスペース定義を廃止できます。

タグ・キー定義をリタイアすると、リソースに適用できなくなります。ただし、タグは適用されたリソースから削除されません。タグは、これらのリソースにメタデータとして存在し、検索、リスト、ソート、レポートなどの操作で廃止されたタグをコールできます。

廃止されたタグ・キー定義およびタグ・ネームスペース定義を再アクティブ化できます。

タグ・キーを再アクティブ化すると、リソースへの適用が再度可能になります。
タグ・ネームスペースを再アクティブ化すると、そのネームスペースに新しいタグ・キー定義を作成できます。ただし、ネームスペースで廃止されたタグ・キー定義を使用する場合は、各タグ・キー定義を明示的に再アクティブ化する必要があります。

タグ・ネームスペースの移動

タグ・ネームスペースを別のコンパートメントに移動できます。タグ・ネームスペースは、移動するときにアクティブまたはリタイアできます。タグ・ネームスペースを移動すると、そのタグ・キー定義がすべて移動されます。

この機能は、コンパートメント階層を再編成する必要がある場合や、廃止されたタグ・ネームスペースを含むコンパートメントを削除する必要がある場合に便利です。リソースを含むコンパートメントは削除できません。廃止されたタグ・ネームスペースは、廃止されても既存のリソースです。廃止されたタグ・ネームスペースを別のコンパートメントに移動すると、元の包含コンパートメントを削除できます。

タグ・ネームスペースを移動するには、両方のコンパートメントでmanage tag-namespacesを許可する必要があります。

タグ定義の削除

タグ・キー定義およびタグ・ネームスペースを削除できます。

タグ・キー定義を削除すると、テナンシ内のすべてのリソースからタグを削除するプロセスが開始されます。削除アクションは非同期であり、作業リクエストを開始します。削除操作を開始すると、タグの状態が削除に変更され、リソースからのタグの削除が開始されます。このプロセスは、タグ付けされたリソースの数によっては数時間かかる場合があります。すべてのタグが削除されると、状態は削除済に変わります。削除されたタグはリストアできません。タグの状態が「削除済」に変わったら、同じタグ名を再度使用できます。

タグ・キー定義を削除するには、まずこれを廃止する必要があります。タグ・ネームスペースを削除するには、まずタグ・ネームスペースを廃止する必要があります。タグ・キー定義を含むタグ・ネームスペースを廃止すると、ネームスペース内のすべてのタグ・キーが廃止され、タグ・キーを削除できます。タグ・ネームスペースを削除できるのは、そのすべてのタグ・キー定義が削除された後のみです。

事前定義済の値の使用

値リストを作成し、そのリストをタグ・キー定義に関連付けることができます。ユーザーがそのタグをリソースに適用する場合、事前定義済の値のリストから値を選択する必要があります。事前定義済の値リストを使用して、ユーザーがタグに適用できる値に制限を適用します。

OCI CLIおよび「コンピュートAPI」では、事前定義された値は「バリデータ」と呼ばれます。バリデータは定義済タグのパラメータで、JSON形式で事前定義済の値を指定するために使用されます。「コンピュートWeb UI」には「バリデータ」という語は記載されていませんが、同じ原則に従います。

既存のタグを更新して、事前定義済の値を使用できます。作成する事前定義済の値のすべてのリストには、少なくとも1つの値が含まれている必要があります。リストに重複する値または空白のエントリを含めることはできません。事前定義済の値では、タグを適用するユーザーは、タグの値をnullに設定できません。

定義済タグとデフォルト・タグで事前定義値を使用できます。デフォルト・タグと組み合せて、ユーザーは、デフォルト・タグが使用されるコンパートメント内に作成する各リソースの事前定義済リストからタグ値を選択する必要があります。これにより、新しいリソースに期待される値を持つメタデータが含まれ、信頼できます。

タグ変数の使用

変数を使用して、定義されたタグの値を設定できます。ユーザーがリソースにタグを追加すると、変数はそれが表すデータに解決されます。定義済タグおよびデフォルト・タグでタグ変数を使用できます。

次のケースについて検討します。

Operations.CostCenter="${iam.principal.name} at ${oci.datetime}"

操作はネームスペース、CostCenterはタグ・キー、タグ値には2つのタグ変数${iam.principal.name}と${oci.datetime}が含まれます。このタグをリソースに追加すると、変数はユーザー名に解決されます - タグを適用したプリンシパルの名前 - タグを追加したときのタイムスタンプ。

user-name at 2021-04-18T14:32:57.604Z

変数は、タグが特定のリソースに適用される時点でデータに置き換えられます。後でタグを編集した場合、変数は失われ、データのみが残ります。他のタグ値を編集するすべての方法で、タグ値を編集できます。

タグ変数を作成するには、特定の書式を使用する必要があります。次のタグ変数がサポートされています:

変数	説明
`${iam.principal.name}`	リソースにタグを適用するプリンシパルの名前。
`${iam.principal.type}`	リソースにタグを適用するプリンシパルのタイプ。
`${oci.datetime}`	タグが作成された日時。

タグのデフォルト

タグのデフォルトを使用すると、特定のコンパートメントの作成時にすべてのリソースに自動的に適用されるタグを指定できます。この機能を使用すると、リソースを作成するユーザーがタグ・ネームスペースにアクセスできる必要なく、リソースの作成時に適切なタグが適用されるようにできます。

タグのデフォルトを使用すると、テナンシ管理者は、ガバナンスおよびリソースの作成および管理が必要なユーザーに関連するユーザー間にセキュアな権限境界を作成できます。タグのデフォルトは、特定のコンパートメントに対して定義されます。デフォルト・タグは、子コンパートメントとその中に作成されたリソースにも適用されます。「コンピュートWeb UI」では、「コンパートメント詳細」ページでタグのデフォルトを管理します。

コンパートメントのタグのデフォルトを作成または編集するには、次の権限の組合せが付与されている必要があります:

タグのデフォルトを追加するコンパートメントに対するmanage tag-defaultsアクセス
タグ・ネームスペースが存在するコンパートメントに対するuse tag-namespacesアクセス
テナンシのinspect tag-namespacesアクセス

タグのデフォルトにはタグ値が含まれている必要があります。デフォルト値を使用する場合は、タグのデフォルトの一部として作成する必要があります。この値はすべてのリソースに適用されます。タグ変数の使用が許可されます。ユーザーが適用した値が必須であると指定した場合、リソースを作成するユーザーは、リソースの作成時にタグの値を入力する必要があります。ユーザーは、タグの値を入力せずにリソースを作成できません。

リソースの作成時とタグ・ネームスペースの使用の両方に適切な権限を持つユーザーが、リソースの作成時にタグのデフォルトをオーバーライドできます。これらの権限を持つユーザーは、後でリソースの作成に適用されたデフォルト・タグを変更することもできます。

コンパートメントごとに最大5つのタグのデフォルトを定義できます。タグのデフォルトがコンパートメントに作成されると、そのコンパートメントに作成された新しいリソースにデフォルト・タグが適用されます。コンパートメントの以前の既存のリソースは、遡及的にタグ付けされていません。タグのデフォルト値を変更しても、既存の出現箇所は更新されません。

タグのデフォルトをコンパートメントから削除しても、タグの既存のオカレンスはリソースから削除されません。タグ・キー定義を削除しても、そのタグ・キー定義に基づく既存のタグのデフォルトはコンパートメントから削除されません。コンパートメントのタグのデフォルトを削除するまで、コンパートメント当たり5つのタグのデフォルト制限に対してカウントされ続けます。

廃止されたタグは新規リソースに適用できません。したがって、タグのデフォルトで指定されたタグ・ネームスペースまたはタグ・キーが廃止された場合、新しいリソースの作成時に廃止されたタグは適用されません。ベスト・プラクティスとして、廃止されたタグを指定するタグのデフォルトを削除する必要があります。

タグ・ベースのアクセス制御

条件およびタグ変数のセットを使用して、リソースに適用されたタグに基づいてアクセスのスコープを設定するポリシーを記述できます。アクセスは、リクエストしているリソースに存在するタグ、またはリクエストのターゲット・リソースまたはコンパートメントに基づいて制御できます。タグ・ベースのアクセス制御により、コンパートメント、グループおよびリソースにまたがるタグを使用してアクセス・ポリシーを定義できるため、ポリシーに対する柔軟性が向上します。

注意:

組織で、タグを使用してアクセスを管理するポリシーを作成することを選択した場合は、タグを適用できるユーザーを管理する適切なコントロールが配置されていることを確認します。また、ポリシーが設定された後、グループ、ユーザーまたはリソースにタグを適用すると、リソースへのアクセスを推測できることに注意してください。

このようなポリシーを作成する前に、タグを運ぶ潜在的なすべてのリクエスタおよびターゲット・リソースを認識していることを確認してください。

リソースにタグを適用する前に、そのタグを含む所定のポリシーを認識し、リソースへのアクセス権を持つユーザーに影響を与える可能性があることを確認してください。

リクエストしているリソースに適用されるタグの値に基づいて、アクセスを制御できます。具体的には、リクエスト元のユーザーが属するグループに割り当てられているタグの値に基づいて、ユーザー・アクセスを付与するポリシー・ステートメントを記述できます。

また、ターゲット・リソースに適用されるタグの値またはターゲット・リソースが存在するコンパートメントに基づいてアクセスを制御することもできます。

ポリシー・ステートメントでタグを使用してアクセスのスコープを設定することで、単一のポリシー・ステートメントを介して複数のグループのアクセスを定義できます。元のポリシーを変更せずにタグを適用または削除することで、グループのアクセスを遅延したり、アクセスを取り消したりすることもできます。

「Oracle Private Cloud Applianceユーザーズ・ガイド」には、ポリシー構文でタグ変数と演算子を使用する方法の詳細な説明と例が示されています。 Identity and Access Managementの章の「ポリシー・ステートメントの作成」の項を参照してください。

注意事項および制限事項

この項では、リソース・タグに基づいて権限を制御するポリシーの書込みを開始する際に考慮する多くのアイテムについて説明します。

項目	説明
リソースをリストする権限は個別に付与する必要があります	ターゲット・リソースに適用されたタグに基づいてアクセスのスコープを設定するポリシーでは、リソースのリストを返すことができる権限を付与できません。したがって、リソースのリストを許可する権限は、追加のポリシー・ステートメントを使用して付与する必要があります。このアプローチでは、ユーザーが管理するリソースを表示できるが、検査する権限のみを制限するため、タグ・ベースのポリシーが改善されます。この制限を回避するために使用できるもう1つの方法は、アクセス権を付与するリソースを含むコンパートメントにタグ付けすることです。
ターゲット・リソースにタグを必要とするポリシーは、作成権限を付与できません	リソースのタグの値に基づいてアクセスのスコープを設定するポリシーを記述する場合は、ポリシーで作成権限を付与できないことに注意してください。たとえば、ターゲット・リソースがまだ作成されていないため、インスタンスの作成リクエストは失敗し、評価する適切なタグがありません。そのタグでインスタンスを使用および削除することは許可されますが、インスタンスの作成はできません。
ポリシー変数で使用されるタグ・ネームスペースおよびタグ・キー定義の文字の制限	タグ・ネームスペースおよびタグ・キー定義では、ポリシー変数で許可されるよりも広い文字セットがサポートされます。したがって、変数でタグ・ネームスペースおよびタグ・キー定義を使用するには、ポリシー変数でもサポートされている文字のみが含まれていることを確認してください。サポートされている文字 : `a-z, A-Z, 0-9, _, @, -, :` タグ・ネームスペースまたはタグ・キーにこれらの文字以外の文字がある場合、ポリシー変数では使用できません。タグ・ネームスペースおよびタグ・キーの名前を変更できないため、新しいタグ・ネームスペースおよびタグ・キー定義を作成する必要があります。
ケースに関する考慮事項	ポリシーでタグを操作する場合、タグ値は大/小文字が区別されないことに注意してください。
コンパートメント階層	ターゲット・コンパートメントに適用されるタグに基づいてアクセスを許可する条件を記述する場合、このポリシーでは、タグ付けされたコンパートメント内にネストされているすべてのコンパートメントへのアクセスも許可されることに注意してください。タグ付けされたコンパートメント内のすべてのサブコンパートメントは、タグ付けされたコンパートメント内のリソースであるため、ポリシーによってアクセス権が付与されます。
サポートされているサービス	すべてのサービスは、`request.principal.group`および`target.resource.compartment.tag`ポリシー変数をサポートしています。すべてのサービスが`target.resource.tag`ポリシー変数をサポートしているわけではありません。サポートされているサービスは次のとおりです: Compute、Networking、IAM、DNS、File Storage、Block Storage。

グループに適用されるタグの使用例

次の例は、ユーザー・グループに適用されたタグを使用して、コンパートメント内のリソースへのアクセスを管理する方法を示しています。

3つのコンパートメントがあるとします: ProjectA、ProjectBおよびProjectC。コンパートメントごとに、管理グループが設定されています: A-Admins、B-AdminsおよびC-Admins。各管理グループは、次のポリシーを介して自分のコンパートメントに対する完全なアクセス権を持ちます:

allow group A-Admins to manage all-resources in compartment ProjectA
allow group B-Admins to manage all-resources in compartment ProjectB
allow group C-Admins to manage all-resources in compartment ProjectC

組織では、ロールによって各グループにタグ付けするための次のタグ・ネームスペースおよびキーが設定されています: EmployeeGroup.Role。このタグの一部の値は、管理、開発者、テスト・エンジニアです。すべての管理グループにEmployeeGroup.Role='Admin'のタグが付けられます。

ここで、共有する3つのプロジェクトのメンバーのテスト・コンパートメントを設定します。既存の3つの管理グループすべてに対する管理アクセス権を付与します。これを実現するために、次のようなポリシーを記述できます:

allow any-group to manage all-resources in compartment Test where
request.principal.group.tag.EmployeeGroup.Role='Admin'

このポリシーでは、タグを持つ既存のすべての管理グループが、テスト・コンパートメントにアクセスできます。また、今後EmployeeGroup.Role='Admin'でタグ付けする新規または既存のグループは、ポリシー・ステートメントを更新せずにテスト・コンパートメントにアクセスできます。

ターゲット・リソース・コンパートメントに適用されるタグの使用例

この例では、組織プロジェクト・コンパートメントごとに2つの子コンパートメントが含まれています: テストと製品。テスト・エンジニアに、3つのプロジェクトすべてにわたってテスト・コンパートメントへのアクセス権を付与しようと考えています。これを行うには、タグResourceGroup.Role='Test'を作成し、これを各プロジェクト・コンパートメント内のテスト・コンパートメントに適用します。

グループTestersが3つすべてのテスト・コンパートメントのリソースにアクセスできるようにするには、次のようなポリシーを使用します:

allow group Testers to use all-resources in tenancy where
target.resource.compartment.tag.ResourceGroup.Role='Test'