Skip to main content
Hello and welcome back. Before we change the prompt, let’s quickly re-examine our tagging-rules.yaml. Below I’ll walk through the file structure, why each section matters for Kubernetes tagging and governance, and how to keep the configuration maintainable and agent-friendly. Open config/tagging-rules.yaml and you’ll see several logical sections: required tags, label mappings, allowed values (cost centers, environments, tiers, compliance levels), resource types, and excluded namespaces. Here is a consolidated, production-ready example of the YAML configuration used in an airline booking context:
Quick reference: file sections and purpose Required tags
  • The required_tags list defines canonical metadata every application resource should include. Your agent/tooling should validate these and flag or remediate resources missing any required tag. This drives consistent ownership, cost allocation, and environment separation across clusters.
Label mappings
  • label_mappings lets multiple teams keep their existing labels while your agent normalizes them to canonical tags. This reduces churn and redeploy work by interpreting app.kubernetes.io/name, app, and application as the same canonical application tag.
Label mappings reduce operational friction: allow teams to use commonly adopted label keys while your tooling maps them to a single canonical tag for policy checks, billing, and search.
Slack channel nuance
  • We added slack-channel as a required tag. Many teams use either slack-channel or slack_channel; the difference between a dash (-) and an underscore (_) matters in Kubernetes label keys. Include both variants in label_mappings to avoid forcing label changes across existing resources.
Kubernetes label keys are exact strings. If you expect multiple naming conventions (dash vs underscore), explicitly map each variant in label_mappings to prevent false negatives during validation.
Allowed values and resource control
  • Use lists such as cost_centers, environments, tiers, and compliance_levels to constrain allowed values. This makes automated checks and reporting deterministic (e.g., cost allocation by cost-center or environment-based promotion pipelines).
  • resource_types defines which Kubernetes kinds the agent should inspect or enforce tags for. Narrow this list to reduce noise and resource usage.
  • excluded_namespaces prevents the agent from touching system or irrelevant namespaces (for example, kube-system), improving performance and avoiding unintended modifications.
Why YAML (not JSON)
  • YAML is more human-friendly for configuration: it handles comments, is easier to read, and is forgiving for adding/removing lists—helpful for operational configs like tagging rules.
  • JSON is stricter and can be used where required, but for day-to-day governance config files, YAML improves maintainability and reduces accidental schema breakage.
Helpful links and references That is a quick relook into what tagging-rules.yaml should contain and why. Next, we’ll go into the prompting section.

Watch Video