> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tagging Rules at a Glance SkyLine Air

> Explains a tagging-rules.yaml for Kubernetes governance with required labels, alternate label mappings, controlled vocabularies, resource kinds to scan, excluded namespaces, and an enforcement workflow.

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.

```yaml theme={null}
# tagging-rules.yaml
# Required tags that must be present on all resources
required_tags:
  - owner
  - environment
  - cost-center
  - application
  - tier

# Alternative Kubernetes label keys (checked in addition to the canonical keys above)
label_mappings:
  owner:
    - app.kubernetes.io/owner
    - owner
  environment:
    - app.kubernetes.io/env
    - environment
    - env
  cost-center:
    - app.kubernetes.io/cost-center
    - cost-center
    - costcenter
  application:
    - app.kubernetes.io/name
    - app
    - application
  tier:
    - app.kubernetes.io/tier
    - tier
  compliance:
    - compliance-level
    - compliance

# Airline booking context cost centers
cost_centers:
  - booking-engine     # Core booking logic
  - payment            # Payment processing
  - inventory          # Flight/hotel inventory
  - customer-service   # Support tools
  - analytics          # Data/analytics
  - platform           # Shared infrastructure

# Valid environments
environments:
  - dev
  - staging
  - prod

# Valid tiers
tiers:
  - frontend
  - backend
  - database
  - cache
  - messaging

# Compliance levels
compliance_levels:
  - pci-dss    # Payment Card Industry
  - sox        # Sarbanes-Oxley
  - standard   # No special compliance

# Resource types to scan
resource_types:
  - Deployment
  - Service
  - ConfigMap
  - PersistentVolumeClaim
  - Ingress
  - Pod

# Namespaces to exclude from scanning (system namespaces)
excluded_namespaces:
  - kube-system
  - kube-public
  - kube-node-lease
  - local-path-storage
```

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

| Section | Purpose | Example / Notes |
| - | - | - |
| `required_tags` | Minimal set of labels enforced on workloads | `owner`, `environment`, `cost-center`, `application`, `tier` |
| `label_mappings` | Alternate keys that satisfy a canonical tag | `environment` → `app.kubernetes.io/env`, `env` |
| `cost_centers` | Business units for FinOps attribution | `booking-engine`, `payment`, `platform` |
| `environments` | Allowed environment values | `dev`, `staging`, `prod` |
| `tiers` | Workload tier vocabulary | `frontend`, `backend`, `database` |
| `compliance_levels` | Compliance categories for audits | `pci-dss`, `sox`, `standard` |
| `resource_types` | Kinds to scan for labels | `Deployment`, `Service`, `Pod` |
| `excluded_namespaces` | Namespaces to ignore in scans | `kube-system`, `kube-public` |

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`.

2. 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`.

3. 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.

4. `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

* [Kubernetes Concepts — Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
* [Kubernetes API Resource Kinds](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/)
* [FinOps Foundation](https://www.finops.org/) — best practices for cloud cost management

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](https://learn.kodekloud.com/user/courses/building-kubernetes-finops-ai-agent/module/9dfbe96e-9d91-4914-b44b-d2b2d7345966/lesson/5826fab2-5ad5-4503-9148-e062fa0e0475)**


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.