# Auto Inject Project Name in Cluster Labels

In our [July 2023](https://docs.rafay.co/releasenotes/2023/june/) release, we added support automatic injection of **project name** as a **cluster label**. In Kubernetes, labels are key/value pairs that are attached to objects such as Pods, nodes etc.

Support for labels in Kubernetes ends at a node level. We extended the "label" construct to **clusters** over two years back as **cluster labels**. Cluster labels are critical for **multi cluster workflows** and have been the backbone of several unique and differentiated features in the Rafay Kubernetes Operations Platform.

In this release, we have automated the **injection** of the "name of the project" as a cluster label to all clusters in the project. Read on to understand some of the use cases that are enabled by this feature.

Note: In a separate blog, we will describe how **cluster labels** power various multi cluster workflows and operations.

## Background

Many of our customers deploy and operate **100s** of Kubernetes clusters spanning different cloud providers, regions and accounts with their [Rafay Org](https://docs.rafay.co/security/rbac/orgs/) acting as their unified, single pane of glass. All these customers utilize **[cluster blueprints](https://docs.rafay.co/blueprints/overview/)** as a way to keep their cluster fleet consistent and standardized.

The cluster blueprints frequently consist of commercial software add-ons such as Datadog, New Relic etc that require the use of "License or API Keys" for these add-ons to connect to their API backends or SaaS service. These customers use **[cluster overrides](https://docs.rafay.co/blueprints/overrides/)** as a means to **dynamically inject** values into the Kubernetes manifests (e.g. values.yaml file) for the add-ons in their cluster blueprint.

### Challenge

Our customers treat Kubernetes clusters as **ephemeral**. They frequently add/remove clusters in their **projects**. So, when a new Kubernetes cluster is provisioned or imported into a project, they also need to make sure that the organization's standardized cluster blueprint is applied to the new cluster. It can be impractical for admins to **manually** manage cluster overrides for **every new cluster**.

### Solution

All clusters in a project will now have a **cluster label** automatically injected with the **project's name**. In the example shown below, the cluster in the project called **apple**. As you can see, a cluster label **rafay.dev/projectName=apple** has been injected as one of the cluster labels.

It is recommended that administrators **templatize** their cluster overrides to **dynamically associate** custom values based on a project name in the cluster label. In the example below, the administrator has specified that the cluster override will be used **cluster labels** that match the configured project name. In this example, the "k8sgpt" add-on's **custom values.yaml** file will be automatically mapped to the specified OpenAI API Key for ALL clusters in the project completely eliminating any manual, administrative tasks.

In this example, when the new cluster is provisioned in the "apple" project, the cluster blueprint is automatically applied with the configured "k8sgpt" cluster add-on which has the necessary values.yaml file with the OpenAI API Key to authenticate with the OpenAI service. Zero manual intervention is required on part of the administrator.