<!-- If the issue is concerning a bug, please use dedicated template --> ### Summary While working on https://gitlab.com/sylva-projects/sylva-core/-/merge_requests/8616 for exercising Sylva's external OpenBao/Vault code path in CI, I found out this is borked. <!-- Summarize the issue encountered concisely. --> #### related references https://gitlab.com/sylva-projects/sylva-core/-/work_items/4129 <!-- Put here any RFE, issue, MR reference which could be related to this issue to have a better picture of the context --> ### Details I believe there are 7 issues: 1. A hard dependency on a disabled unit `vault-init`, which creates the `vault` namespace and internal-TLS secret for Sylva's **own** internally deployed Vault/OpenBao) and is [only enabled when `vault` unit is enabled](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1697-1698), which itself is only [enabled when `_internal.vault_unit: vault`](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1965-1966), i.e. **never** when using an external vault: ``` Error: exiting as condition "reason" equals "InstallFailed" in unit HelmRelease/sylva-units, message: Helm install failed for release sylva-units-preview/sylva-units with chart sylva-units@0.0.0-git-8fe7568a+118c8967fa57: execution error at (sylva-units/templates/units.yaml:306:16): unit 'harbor-init' is declared with a dependency on disabled unit 'vault-init' ``` 2. `vault-external` itself had the a [`vault-init: true` dependency](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1937), but it is only [enabled when `_internal.vault_unit: vault-external`](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1939-1940), which is the exact opposite of `vault-init`'s, so a dependency that could never be satisfied. 3. `vault-init` is the only thing that creates the `vault` Kubernetes namespace (via [`../namespace-defs/baseline-namespace`, targeted through its `targetNamespace: vault`](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/kustomize-units/vault-init/kustomization.yaml#L5)). <br/> Since `vault-init` is disabled in external vault mode, nothing creates that namespace, yet `vault-external`'s own resources ([`Secret`](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/kustomize-units/vault-external/ext-vault-creds.yaml#L6)) and `harbor-init`'s [`RandomSecret` CRs](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/kustomize-units/harbor-init/harbor-postgres-admin.yaml#L5) both target it unconditionally. So we need to create the namespace also through the `vault-external` branch. 4. `vault-external` has a dependency on `vault-config-operator` but its [own manifests never actually use `vault-config-operator`'s CRDs](https://gitlab.com/sylva-projects/sylva-core/-/tree/52bf44ea157a5d695800c30de3de88c3da89b4ca/kustomize-units/vault-external). I believe this is unneeded. 5. `openbao-set-service-label` unit (labeling pods with `variant: openbao`) is [enabled if `kyverno` is enabled](https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1792-1793), but it shouldn't be just that condition, since it's not needed for the external vault branch, it is only ever meaningful for the internally-deployed OpenBao instance. 6. `vault-external` creates the TLS CA `Secret/vault/vault-ca` conditionally (https://gitlab.com/sylva-projects/sylva-core/-/blob/52bf44ea157a5d695800c30de3de88c3da89b4ca/charts/sylva-units/values.yaml#L1955) and Kyverno policy `remove-tlsconfig-from-vault-crds` is supposed to strip `spec.connection.tLSConfig` CRs from `vault-config-operator` CRs that need to use an external Vault without TLS. However, there's no `kyverno` unit dependency anywhere. We may deploy the `vault-config-operator` CRs without their TLS config instead of having Kyverno delete that. 7. The [`workload-team-defs` chart resources are not ready to serve external OpenBao code path](https://gitlab.com/sylva-projects/sylva-elements/helm-charts/workload-team-defs/-/blob/main/values.yaml?ref_type=heads#L64-79), due to hardcoded Vault endpoint and no way to skip TLS. <!-- Explain what is the purpose of this issue -->