Skip to main content
Welcome back. This lesson walks through the tagging-rules.yaml used by SkyLine Air and explains its structure, purpose, and how it supports governance of Kubernetes resources. Treat this file as the organization’s single source of truth for labeling: required tags, alternative keys teams may already use, allowed values for business concepts (cost centers, environments, tiers, compliance), which Kubernetes resource kinds to scan, and which namespaces to skip. Below is the tagging-rules.yaml example we’ll use throughout this article. It captures the minimal required tags, mappings for alternative label keys, allowed vocabularies for FinOps and compliance, resource kinds to scan, and excluded namespaces.
This YAML balances enforcement and adoption: it enforces a minimal set of required tags while accepting common alternative label keys so teams aren’t forced into disruptive relabel operations. Use this as a governance contract for cost allocation, ownership routing, and automated audits.
Overview: what each top-level key means and why it matters
  • required_tags
    Canonical labels that must exist on every business workload to enable accurate ownership, routing, and cost allocation: owner, environment, cost-center, application, and tier.
  • label_mappings
    Maps canonical tag names to the alternate Kubernetes label keys teams may already be using (for example, env vs app.kubernetes.io/env). The validator should treat any mapped key as equivalent to the canonical one so you can govern heterogeneous clusters without forcing immediate relabeling.
  • cost_centers
    A controlled vocabulary of business units that FinOps and billing systems use to attribute spend. Examples here: booking-engine, payment, inventory, customer-service, analytics, platform.
  • environments, tiers, and compliance_levels
    Lists of allowed values for environment, workload tier, and compliance. These are used for validation and audits to ensure labels conform to organizational policy.
  • resource_types
    Which Kubernetes object kinds the scanner should examine for labels. Typical choices include Deployment, Service, ConfigMap, PersistentVolumeClaim, Ingress, and Pod.
  • excluded_namespaces
    Namespaces skipped by the scanner (usually platform or system namespaces such as kube-system and provisioner namespaces). This reduces noise and false positives during audits.
Quick reference table: top-level keys Detailed guidance and considerations
  1. Enforcing required_tags
  • Purpose: Guarantees every tracked resource includes the minimal metadata needed for ownership, incident routing, and cost attribution.
  • Implementation note: Validators should check both the canonical key (e.g., environment) and any mapped alternatives defined in label_mappings.
  1. Using label_mappings to avoid disruption
  • Benefit: Allows gradual convergence to canonical keys. Treat mapped keys as equivalent during scans and reports.
  • Example behavior: If a Deployment has env: prod but not environment: prod, the validator should accept it once env is listed under label_mappings.environment.
  1. Controlled vocabularies (cost_centers, environments, tiers, compliance_levels)
  • Purpose: Reduces ambiguity during audits and makes automated policies (e.g., cost reports, compliance checks) reliable.
  • Enforcement tip: Use these lists as a whitelist—flag values not present for review rather than auto-failing immediately to allow remediation windows.
  1. resource_types — what to scan
  • Pick kinds that matter to your cost and security posture. Commonly scanned kinds are Deployment, Service, Pod, etc.
  • Avoid scanning every possible kind by default; scanning fewer, high-value kinds reduces noise and speeds validation.
Excluding namespaces reduces noise, but be careful: excluding a namespace that contains business workloads will hide noncompliant resources from the auditor. Regularly review excluded_namespaces and document the rationale for each excluded entry.
Why this approach improves adoption and governance
  • Minimal (non-negotiable) tags deliver immediate value for cost allocation and routing.
  • label_mappings supports incremental adoption by accepting common, pre-existing label keys.
  • Controlled value lists (cost centers, environments, tiers, compliance) enable reliable automation, audits, and FinOps reporting.
Suggested enforcement workflow
  1. Start in audit-only mode: run the scanner to produce a report of missing/invalid labels across resource_types.
  2. Share findings with teams and allow an agreed remediation period.
  3. Move to enforcement mode (fail CI/policy checks) after remediation windows expire.
  4. Periodically review and update label_mappings to capture new common label patterns.
Next steps — applying tagging-rules.yaml in your cluster
  • Deploy a scanner/validator that reads this YAML and:
    • Resolves canonical tags using label_mappings.
    • Validates values against cost_centers, environments, tiers, and compliance_levels.
    • Scans only the resource_types and ignores excluded_namespaces.
  • Run in audit mode first, then move to gating policy enforcement (e.g., admission controller, CI checks).
Links and references See you in the next hands-on lesson, where we’ll deploy SkyLine Air manifests (payment gateway, inventory, analytics, platform services) and validate tagging compliance end-to-end.

Watch Video