Cloud Services

ModernOps

Tag Schema admin guide
Published On May 16, 2024 - 1:59 PM

Tag Schema admin guide

Understand Tag Schema as a Kyndryl Modern Operations Applications feature that allows you to set policies governing the use of tags.
The Tag Schema Common Actions Service is a Kyndryl Modern Operations Applications feature that allows you to set policies governing the use of tags in the Kyndryl Modern Operations Applications to help you organize your reports, and monitor and enforce compliance. The tag schema service supports both internal and external (provider side) tags.
The service ensures that tags applied at the provider and updates or modifies them as needed to comply with the tag schema defined in the Kyndryl Modern Operations Applications. You can also use your own tools, other services or the provider’s native portal for tag management while still being able to track against a central tag schema to ensure compliance.
The highest level is the tagging strategy, which represents how you want to manage tagging across your system. The tagging strategy consists of one or more tag schemas, which allow you to place rules on how tags are created in your system. Each tag schema consists of one or more tag definitions and one set of schema conditions.
Schema conditions are the conditions under which the tag schema is enforced. The tag definitions consist of the key and value for the tag, and what
key:value
conditions are allowed by the tag schema. This system allows you to set up rules for your tags that are enforced under any set of conditions that you want to set up.
You can use a tag schema, for example, to ensure that a set of basic tags are consistent across your enterprise, ensuring that you can access and monitor your environment with confidence. You can, for example, set rules to ensure that a standard set of tags is attached to everything in your system including the existence of those tags (make them mandatory), the type of those tags (such as string), and what values those tags are allowed to have.
You can create a standardized tag schema across the Kyndryl Modern Operations Applications and your service providers. The schema allows apps to apply tags that are considered standard to their application specific workflows, such as the
order_id
tag that Enterprise Marketplace will always set. This system allows you to enforce control and governance for usage of tagging across the Kyndryl Modern Operations Applications within an application's user interface (UI).
There are two types of tags:
  • Provider tags: Tags that are persisted at the provider
  • Internal tags: Tags that are specific to your environment
Providers will have their own tag schema guidelines. You can create a tag schema to enforce these rules to ensure that the tags in the Kyndryl Modern Operations Applications will meet the rules that the provider has set for their tags.
The system also allows you to manage dynamically generated tag values, allowing your users to create tags while enforcing their required characteristics.
Any app, integration, or automation that supports dynamic resource groups (such as Governance Console today), can use the defined tag schema for dynamic resource member relationships to use the defined policy for other application console governance use cases.
Tag Schema uses provider Asset Ingestion Accounts.
You can make tag definitions dependent on the value of other tag definitions. For example, you might want to provide a list of campus locations in a region when a user selects that region or apply the tag 'confidential' to anything from a particular department. This is referred to as being 'determined by' and 'determines.' Any number of tag definitions can be nested in this way.

Types of tag policies

In the Kyndryl Modern Operations Applications, the following types of tag schemas are available:
  • Global Tag Schemas:
    Global tag schemas are schemas that are applied across your entire enterprise. While you can define multiple global tag schemas, you can only have one active at a time. You can define multiple global tag schemas for version so you can work on the schema without affecting your enterprise. For global tag schemas, you cannot alter the schema conditions. This schema type always covers everything in your system.
  • Non-Global Tag Schemas:
    Groups within your organization can also define their own tag schemas. This cannot override anything in the global tag schema, but can introduce new rules that tags must adhere to that are unique to that group. Non-Global tag schemas can for example be used at the department level, for specific regions, or any other division within your organization.

User roles and tag schemas

You can use the following user roles to manage tag schemas:
Role
Tag Schema Viewer
Tag Schema Admin
View global tag schemas
Yes
Yes
Create, modify, and delete global tag schemas
No
Yes
View global tag schema conditions
Yes
Yes
Create, modify, and delete global tag schema conditions
No
No
View tag definitions
Yes
Yes
Create, modify, and delete tag definitions
No
Yes
View tag definition details
Yes
Yes

Integration with Cost & Asset Management

In support of Cost & Asset Management (CAM), tag schemas offer the following capabilities:
  • Ability to create dynamic resource groups from tags defined by tag schemas:
    CAM can use tag schema APIs to retrieve tags defined using your tagging strategy, and then classify and categorize those tags into the appropriate groups using the Dynamic Resource Group feature.
  • Ability to create a tag compliance report:
    CAM can use the tag schema APIs to retrieve the defined tag schema. After CAM discovers the resources and their tags, it can correlate the defined tag schema with the tags existing on the resource, and then check those tags to make sure that they adhere to the tag schema.
  • The tag compliance report for the resources checks for the mandatory tag schema definitions and the conditions within the tag schema definition such as provider, account, category, and so on.

Other use cases

The tag schemas also provide the following functions:
  • Enterprise Marketplace can reference the tag schema to understand what tags should be assigned to which resources
  • The Kyndryl Modern Operations Applications can apply corrections to tags on resources to bring them into compliance with the tag schema
  • AIOps can use the tag schemas to apply both provider and user (internal) tags as needed
User tags are internal use only and cannot be pushed to providers.

Related tag definitions

You can make tag definitions dependent on the value of other tag definitions. For example, you might want to provide a list of campus locations when a user selects a specific region or apply the tag 'confidential' to anything from a particular department. These are divided into enabling tags, which determine something about the enabled tag in a parent-child relationship.
An enabling tag can be linked to multiple enabled tags. An enabled tag can also be an enabling tag for other tags. There is no limit to how many layers of enabling and enabled tags that you can create.
For some example scenarios of tag definition dependencies, see Tag definition scenarios.

Types of relationships supported

The following types of enabled and enabling relationships are supported in the Kyndryl Modern Operations Applications.
Resulting type of tag definition
Possible values for “Mandatory”
Related/Enabled value?
Supported
Use case for creating this tag definition
Enabling
Yes
This works as a “parent” in a hierarchy of tags. Other tags can have related values defined to this tag
Yes
Tag is mandatory for all services for all accounts at all providers
Enabling
Conditional
Undefined
Yes
Tag is mandatory for some services and accounts at some providers
Enabling
No
Undefined
Yes
Optional to exist at provider
Enabling
No
Undefined
No
Tags Definitions MUST have either provider, accounts, service types defined, or be related to another tag definition that defines these conditions
Enabled
Yes
Yes (must be related if this is a child in a hierarchy)
Yes (filter only to provider, accounts, service types from parent tag)
  • Tag is mandatory, is enabled based on a specific value from another tag
  • Needs to exist at all services for all accounts and at all providers
  • Tag is enabled by another tag definition, the provider/account conditions are managed at the enabling tag definition
  • Problem with chained refs where parent does not have any conditions
  • Children might or might not have conditions
  • If parents have provider/account/service types defined, children cannot supersede that
Enabled
Conditional
Yes
Yes
  • Could be mandatory, is enabled based on a specific value from another tag
  • Provider, accounts, service types from the child CANNOT be a superset of the parent
  • Provider, accounts, service types from the child CAN be a subset of the parent’s
Enabled
No
Yes
Yes
Optional to exist at provider, is enabled based on a specific value from another tag
Enabled
undefined
Yes
Yes
  • May or may not be mandatory, enabled by some other tag definition and derives conditions from the enabling tag definition
  • Provider, accounts, service types from the child CAN be a null set
Do you have two minutes for a quick survey?
Take Survey