Configuration Promotion

Configuration Promotion Caveats and Advisory

TSB configuration mostly consists of a number of Kubernetes Objects, e.g. Tenant is an object of api.tsb.tetrate.io/v2 Kind and so on. As such, the main recommendation is to treat TSB configuration just like any other k8s resouce definition, i.e.

• define resources declaratively.
• use GitOps for resource application.
• use kustomize or similar tools for config templating and rendering.

The main caveat when it comes to applying resources from one TSB installation to another is the way TSB stores configuration data when calculating and evaluating NGAC access rules, cluster/service parametrs etc. Service Bridge uses the persistent storage (e.g. Postgres) as the Source of Truth and chooses the resource fully-qualified name as the primary key. As such, "promoting" a configuration between two independent (not sharing the same persistent state) TSB installations MUST take into account the configuration resource naming to avoid primary key conflicts. In other words, to reliably promote configuration between independent instances, one should:

• Name all TSB resources in both instances exactly the same, including the resource path (i.e. Clusters of the same name in one instance must belong to the same Tenant as in the other and so on).
• Avoid imperative configuration changes (e.g. adding a Cluster via UI/CLI in one environment and not the other), rather using declarative definitions.
• Always have a fresh persistent storage backup to be able to quickly roll back in case of data model conflicts.