<!-- If the issue is concerning a bug, please use dedicated template --> ### Summary Trying to deploy `openbao` unit in a workload cluster (following GitOps workflow with `SylvaWorkloadCluster.spec.enabledUnits` set to: ```yaml vault: true vault-init: true vault-operator: true openbao-set-service-label: true openbao: true external-secrets-operator: true ``` for its dependencies to be activated also, but same would happen with the kustomize overlay CLI workflow) did not install it. <!-- Summarize the issue encountered concisely. --> #### related references <!-- Put here any RFE, issue, MR reference which could be related to this issue to have a better picture of the context --> ### Details This came to light after @gcarreto reported on Slack an issue with `openbao` unit deployed in a workload cluster, using Sylva version in d549da21e067af578505641f11ccae5a6e1cd5aa. <br/> On workload clusters, every Flux Kustomization inherits `.unit_kustomization_spec_default.targetNamespace: sylva-system` (set [here](https://gitlab.com/sylva-projects/sylva-core/-/blob/a178b995005910ffb633ad6eb73d7f63cf9c346f/charts/sylva-units/workload-cluster.values.yaml#L36)). But Flux's `ks.spec.targetNamespace` overrides the namespace baked into a unit's kustomize manifests. <br/> The `openbao`, `openbao-set-service-label` & `vault-secrets` units set their namespace only inside the manifests (and kustomize namespace transformer) and do not declare `ks.spec.targetNamespace` (unlike their siblings `vault-init` and `vault-operator`, which do), so on a workload cluster their resources are forced into `sylva-system` instead of `vault`, while `vault-init` still (correctly) creats the TLS secret `Vault.vault.banzaicloud.com` CR expects (`.spec.existingTlsSecretName`) in `vault` ns. <br/> This results in a namespace split that brakes the chain: - Vault CR lands in `sylva-system`, so the operator looks for `Secret/vault-internal-tls` there and can never find it, with vault-operator reporting: ```shell {"level":"info","ts":"2026-06-30T10:32:12Z","logger":"controller_vault","msg":"Reconciling Vault","Request.Namespace":"sylva-system","Request.Name":"vault"} {"level":"error","ts":"2026-06-30T10:32:12Z","msg":"Reconciler error","controller":"vault-controller","object":{"name":"vault","namespace":"sylva-system"},"namespace":"sylva-system","name":"vault","reconcileID":"65d865e0-b29d-42c5-8a69-c5e3176557d2","error":"failed to get tls secret for vault: Secret \"vault-internal-tls\" not found","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:474\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:421\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func1.1\n\t/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.22.4/pkg/internal/controller/controller.go:296"} ``` - the `openbao-set-service-label` Kyverno Policy lands in `sylva-system`, not `vault` namespace, so it can never set the `vault-active` label, which cases the `Service/vault` to have no endpoints, hence HA peers can't reach the leader to join raft: ```shell node-admin@swct-team-a--rke2-flavour-validation-cp-8458665201-spvdw:~$ kubectl get pods -n vault NAME READY STATUS RESTARTS AGE vault-0 2/2 Running 0 111m vault-1 0/2 CrashLoopBackOff 63 (53s ago) 110m vault-configurer-5d8868f759-5phpd 1/1 Running 0 111m vault-operator-774756dd94-gg67f 1/1 Running 0 112m node-admin@swct-team-a--rke2-flavour-validation-cp-8458665201-spvdw:~$ kubectl get pod -n vault -l variant=openbao --show-labels NAME READY STATUS RESTARTS AGE LABELS vault-0 2/2 Running 0 132m app.kubernetes.io/name=vault,apps.kubernetes.io/pod-index=0,controller-revision-hash=vault-56667c454b,example.com/log-format=json,openbao-active=true,openbao-initialized=true,openbao-perf-standby=false,openbao-sealed=false,openbao-version=2.5.5,statefulset.kubernetes.io/pod-name=vault-0,variant=openbao,vault_cr=vault vault-1 0/2 CrashLoopBackOff 75 (7s ago) 132m app.kubernetes.io/name=vault,apps.kubernetes.io/pod-index=1,controller-revision-hash=vault-56667c454b,example.com/log-format=json,openbao-active=false,openbao-initialized=false,openbao-perf-standby=false,openbao-sealed=true,openbao-version=2.5.5,statefulset.kubernetes.io/pod-name=vault-1,variant=openbao,vault_cr=vault node-admin@swct-team-a--rke2-flavour-validation-cp-8458665201-spvdw:~$ kubectl get endpoints vault -n vault NAME ENDPOINTS AGE vault <none> 133m ``` Setting below s-u values in a ConfigMap consumed inside `SylvaWorkloadCluster.spec.valuesFrom` allowed for deploying the workload cluster. ```yaml units: openbao: kustomization_spec: targetNamespace: vault openbao-set-service-label: kustomization_spec: targetNamespace: vault vault-secrets: kustomization_spec: targetNamespace: vault ``` <!-- Explain what is the purpose of this issue -->