Research/Investigate Tag Inheritance for Cost Reporting

[AErmie]

As part of leveraging the FinOps Toolkit for cost reporting (see: Implementation of FinOps Toolkit / Cost Reporting), we need to look into applying and using tag inheritance.

This will ensure that tags applied at a Subscription level, will also be applied at the Resource Group level, and subsequently at the Resource level. This will enable us to be able to filter cost data by these tags.

[!NOTE] The required permissions could pose a challenge, where we need to engage with the ADMS and/or Hosting team.

We may be able to accomplish this at-scale using an Azure Policy.

Acceptance Criteria

Generated by Zenhub AI

• [ ] Scenario: Tag inheritance is enabled for cost reporting

  • Given tag inheritance is applied at Subscription level
  • When tags are applied at Subscription level
  • Then tags should be inherited by Resource Group and Resource levels

• [x] Scenario: Cost data can be filtered by tags after tag inheritance is enabled

  • Given tag inheritance is enabled for cost reporting
  • When filtering cost data by specific tags
  • Then the cost data should display only resources with those tags applied

• [ ] Scenario: Required permissions are addressed for tag inheritance implementation

  • Given required permissions for tag inheritance
  • When engaging with the ADMS and/or Hosting team
  • Then the necessary permissions should be obtained to proceed with tag inheritance implementation

[AErmie]

Manually applied the "Inherit a tag from the subscription" policy in FORGE to the Landing Zone root level.

[!NOTE] Reference documentation:

• Assign policy definitions for tag compliance
• InheritTag_AddOrReplace_FromSubscription.json

Within that policy assignment, we can specify exactly which tag(s) we want it to inherit (it's not an all-or-none approach). So I tested with just the account_coding tag.

Since there were existing resources, I had to manually created/trigger a Remediation Task (as the automatic one didn't work for some reason). The task ran fairly quickly, and as you can see, remediated appropriately The failed resources are VM extensions, as the VM apparently needs to be running for the tag to be applied (to the extension, not the VM itself).

[AErmie]

Created a custom Policy Initiative (aka "policy set"), while including 3 instances of the built-in Inherit a tag from the subscription policy (one per desired tag to inherit, namely account_coding, billing_group, and ministry_name).

While the Policy Initiative was successfully created, along with 3 instances of the built-in policy, even though the individual policy definition associations within the initiative specified different parameter values, the end result was that each instance only used the first parameter defined (ie. the value for InheritTag-Account-Coding which is account_coding).

"policyDefinitions": [
      {
        "policyDefinitionReferenceId": "Inherit the Account Coding tag from the subscription",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/b27a0cbd-a167-4dfa-ae64-4337be671140",
        "parameters": {
          "tagName": {
              "value": "[parameters('InheritTag-Account-Coding')]"
          }
        },
        "groupNames": []
      },
      {
        "policyDefinitionReferenceId": "Inherit the Billing Group tag from the subscription",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/b27a0cbd-a167-4dfa-ae64-4337be671140",
        "parameters": {
          "tagName": {
              "value": "[parameters('InheritTag-Billing-Group')]"
          }
        },
        "groupNames": []
      },
      {
        "policyDefinitionReferenceId": "Inherit the Ministry Name tag from the subscription",
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/b27a0cbd-a167-4dfa-ae64-4337be671140",
        "parameters": {
          "tagName": {
              "value": "[parameters('InheritTag-Ministry-Name')]"
          }
        },
        "groupNames": []
      }
    ]

This may be to referencing the same policy definition ID (ie. /providers/Microsoft.Authorization/policyDefinitions/b27a0cbd-a167-4dfa-ae64-4337be671140), and we may therefore need to create 3 custom policy definitions instead.