Golden Blueprint

"Golden Cluster Blueprints" capability is an extension of Default (System) Blueprints and can be used to create/enforce a baseline set of add-ons/policies. Users can use it as a base blueprint for any new custom blueprint/versions or deploy Golden Blueprints to clusters.

Golden Blueprints offers the following benefits:

• Makes it easier to create and manage Custom BPs (Ex: Removes the need for Org/Infra Admins to create a net new custom BP from the scratch with a default BP as the base in cases where a specific add-on or two need to be included additionally for certain projects)
• Ensure that certain baseline applications are deployed and policies applied at all times for clusters to stay in compliance

Important

Custom Blueprints cannot override configurations specified in the Golden blueprint. This includes policies across different services, installation profiles across different services, and other key settings.

The below matrix presents a breakdown of actions like creation, updating, and deletion of golden blueprint(s) across multiple deployment methods: Interactive UI, Declarative RCTL commands, API-driven automation, and Terraform.

Action	UI	CLI	API	Terraform
Create	Yes	Yes	Yes	Yes
Edit/Update	Yes	Yes	Yes	Yes
Delete	Yes	Yes	Yes	Yes

---

Scoping

Other than the default cluster blueprints, which is common across all projects, all golden blueprints are scoped to a Project. If required, blueprints can be shared with selected or all projects.

Default Blueprint

The Default Blueprints available out of the box are the following:

• default-aks (specific to AKS)
• default-gke (specific to GKE)
• default
• default-openshift (specific to OpenShift)
• default-upstream (specific to upstream)
• minimal.

The default blueprint carries core services such as Prometheus, log aggregation and more needed to run enterprise Kubernetes workloads while the minimal blueprint contains the bare-bones necessary components to get a cluster up and running and is better for either dev/test situations, or if you want to completely use your own custom services and add-ons.

Each Default Blueprint has different group of system add-ons with multiple versions. Users can pick any of these Default Blueprint and customize to create a new Blueprint version

Golden Blueprint

A custom blueprint can also inherit from a golden blueprint. This is extremely useful when an admin wants to set a specific set of rules that need to be enforced across a fleet of clusters i.e. a golden path but then for certain cluster types or a smaller group of clusters, needs to potentially enable other services, add more policies, etc. This is also useful to enforce compliance and security as configurations in a golden blueprint cannot be overridden or deleted by the custom blueprint.

Important

Any installation profile, service, and policies specified in a golden blueprint cannot be overridden or deleted in the custom blueprint.

---

Step 1: Create or Update Golden Blueprint

As an Admin in the Web Console,

Creating a Golden Blueprint

• Navigate to the Project and click on Blueprints under Infrastructure
• Click on New blueprint
• Provide a name and description
• Select the Type Golden Blueprint and click Save

Updating a Golden Blueprint

• Navigate to the Project and click on Blueprints under Infrastructure
• Click on your blueprint
• Click on New Version and use the wizard to provide details
• Provide a version number/name

---

Step 2: New Version and Enabling Key Services, Add-Ons, and Configurations

• Click on New Version and use the wizard to provide details
• Provide a version number/name
• Select the required Base Blueprint (System Blueprints) and its version from the drop-down

• Next, let's see the optional functionality that can be enabled in terms of add-ons and services. If you do not want to enable any of this, you can click save changes.

Enabling Drift Detection (Optional)

• Enable Webhook and select a drift action

Blueprint sync operations determine the status of the web-hook, considering settings at the blueprint, project, or organization levels. The order of assessment for the enable/disable configuration of the drift web-hook follows the pattern outlined in the table provided below.

Organization	Project	Blueprint	Expected Behaviour
Enabled	Enabled	Enabled	Drift web-hook enabled on all clusters in the org
Enabled	Disabled	Enabled/Disabled	Drift web-hook disabled on all clusters in the project, but enabled on all clusters in different projects under the same org
Disabled	Enabled/Disabled	Enabled/Disabled	Drift web-hook disabled on all clusters in the org

Important

In alignment with the end of support for PSPs in Kubernetes, turnkey support for PSPs has been deprecated. New Blueprints will no longer support the use of PSP. Existing PSP configurations configured through Blueprints will be maintained but cannot be updated. PSP addons are therefore marked as ready instantly on any Blueprint updates

Enabling Namespace Syncing (Optional)

• Enable Namespace sync under Namespace configuration

---

Adding customized add-ons (Optional)

Next you can select which custom software add-ons you want to have as part of your blueprint allowing you to bring your own software or customizations as necessary. Refer to the custom add-on documentation for more info on how to create a custom add-on.

In order to use these custom add-ons in a blueprint:

• Click Configure Add-Ons.

• Next search for the add-ons you want to use. You can search by name or search by label to reference a group of add-ons with the given label. Refer to to the custom add-on documentation for more info on how to create and use add on labels.

• Next, you can select all from the search results or use the plus button to add the individual add-on. A few key things to note on this step:

  1) When the add-on is selected, if not in the list already the latest version will be selected.

  2) When you select all, add-ons which do not have a version/are not fully initialized will not be added to the list.

  3) If the add-on is already in the blueprint, the next time you update, it will still have the given version you selected.

• If you need to change a version or specify a dependency on another add-on for any given particular add-on, you can do so by going to the individual add-on and making your modification.

• Enable the Critical option for the required add-ons. This ensures that the deployment of these add-ons is mandatory, prioritizing them during cluster provisioning. For more details on add-on criticality, refer to this page.

• Click the reset button to reset the list of add-ons selected if you want to start over.
• Click SAVE CHANGES to save your changes.

Enabling Managed System Add-Ons (Optional)

• Enable/disable managed system addons from the existing list (i.e. Ingress Controller).
• Enable the Critical option for the required add-ons. This ensures that the deployment of these add-ons is mandatory, prioritizing them during cluster provisioning. For more details on add-on criticality, refer to this page.

Enabling Managed Services (Optional)

Optionally Rafay managed services can be enabled including:

• Policy Management powered by OPA Gatekeeper: This enables OPA Gatekeeper on any cluster the blueprint is deployed to. Select policies from the list to enforce on the required cluster.
• Network Policy powered by Cilium: Toggling the enable network visibility and policy installs Cilium on the cluster and allows admins to create and enforce Cilium network policies for namespace isolation and L3/L4 segmentation. Optionally, you can select cluster-wide policies to enforce by default as well as specifying a custom installation profile in case you want to change certain Cilium installation parameters.
• Cost Management: Toggling the enable button here enables cost management to enforce chargeback rules and get visibility into overall cost metrics and usage on a given cluster.

If necessary, enable Critical option to make these service(s) mandatory for cluster deployment. Refer to Critical Add-Ons for more information.

Step 3: Save Configuration

• Click Save Changes.

Below is an example of a golden blueprint called "demo-golden-blueprint"

Step 3: Saving Changes

• Click save changes to save the configuration.

---

View Versions

The entire history of blueprint versions is maintained on the Controller. Admins can view details about the versions of cluster blueprints using the eye icon

Use the enable/disable icon to turn on the required golden blueprint version(s) to list out during the cluster provisioning. This option helps to disallow the users from using blueprint versions that might contain vulnerable/deprecated Add-On versions

Disabling affects the clusters using this specific blueprint version. Click Yes to proceed

Once a version is disabled, the cluster deployed with that specific BP version is highlighted in red with an Update button. Use this button to update with the required blueprint and version

---

View All Cluster Blueprints

Admins can view all custom cluster blueprints.

• Navigate to the Project
• Click on Blueprints under Infrastructure

This will display both the "default blueprints" and any custom/golden cluster blueprints that have been created.

Below is an illustrative example of custom and golden blueprint(s). The Type column shows the type of the custom BP, either custom (or) golden

---

Actions

Users can share, edit, or delete golden blueprint(s) from the Blueprints list page if they are not inherited from another project. This can be accomplished using the respective icons, as depicted below.

Share Blueprints

Various consequences arise when a blueprint is shared across projects, contingent on the drift action enablement at the Organization, Project, and Blueprint levels. The following matrix illustrates the process of sharing blueprints, taking into account the drift action enablement:

Parent Project	Blueprint	Child Project	Expected Behaviour
Enabled	Enabled	Enabled	Drift web-hook will be enabled on all clusters in parent and child projects
Enabled	Enabled	Disabled	The drift web-hook will be enabled on all clusters in parent projects and disabled on all clusters in the child projects
Enabled	Disabled	Enabled	The drift web-hook will be disabled in both parent project and child project
Enabled	Disabled	Disabled	The drift web-hook will be disabled in parent project and disabled in child project
Disabled	Enabled	Enabled	The drift web-hook will be disabled in parent project and enabled in child project
Disabled	Enabled	Disabled	The drift web-hook will be disabled in both parent project and child project
Disabled	Disabled	Enabled	The drift web-hook will be disabled in both parent project and child project
Disabled	Disabled	Disabled	The drift web-hook will be disabled in both parent and child project

---

Apply Custom/Golden Blueprint

Once a golden cluster blueprint has been created and published, it can either be used as the base blueprint for Custom BPs or applied directly during the initial provisioning of clusters or to existing clusters.

New Clusters

While creating a new cluster, select the golden blueprint from the dropdown. An illustrative example is shown below.

---

Existing Clusters

• Click on options (gear icon on the far right) for an existing cluster
• Select "Update Blueprint" from the options
• Select the "blueprint" and "version" from the dropdown
• Click Save and Publish

This will update the cluster blueprint on the target cluster. Once all the required resources are operational on the cluster, the blueprint update/sync will be complete.

---

Nodes Architecture

To use the golden blueprint on ARM64 based clusters, the below criteria must be met:

1. Uncheck the managed addons that are selected by default on creating a golden blueprint with a minimal blueprint as base
2. When creating a custom blueprint with a golden blueprint as base, create a golden blueprint as mentioned in point 1 and uncheck the managed addons selected by default for custom blueprint

Customizations are not allowed. Provisioning fails if you enable any customizations or deploy other blueprints (other than minimal) on ARM64 based clusters

Below is an illustrative example of a failed scenario

---