Set vault paths as variables

Currenty Sylva leverages hardcoded vault path naming for kubernetes authentication and the secret store: kubernetes and secret. If we want to use an external vault, instead of deploying a vault in the mngmt cluster, this default naming may raise collision issue with existing path on the external vault. These names must thus be set as variables.

Note: the oidc path is not planned to be configurable since an external vault shall not use OIDC authentication, cf. !4463.

This MR:

• introduces the object .Values.security.vault.paths
• modifies the CRD vault in the unit vault accordingly
• modifies all units using the vault server, namely to generate/read passwords.

related references

This MR is needed to address the issue #2262.

This MR depends on !4329 (merged).

Test coverage

CI deployment with default values. Actually, the login_test urls have not been modified and, thus, expects the default path names

CAPO deployment with specific path names, e.g. mysecret and mykubernetes:

...$ vault secrets list -tls-skip-verify
Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_8d5efa01    per-token private secret storage
identity/     identity     identity_f8c89e00     identity store
mysecret/     kv           kv_8b260703           Management Cluster Secrets
sys/          system       system_47655966       system endpoints used for control, policy and debugging

...$ vault auth list -tls-skip-verify
Path             Type          Accessor                    Description                Version
----             ----          --------                    -----------                -------
mykubernetes/    kubernetes    auth_kubernetes_cebabe98    kubernetes backend         n/a
oidc/            oidc          auth_oidc_f3931f77          n/a                        n/a
token/           token         auth_token_5b94e86c         token based credentials    n/a

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	capd, capo, capm3
🚀	Bootstrap Provider	kubeadm (alias kadm), rke2
🐧	Node OS	ubuntu, suse
🛠️	Deployment Options	light-deploy, dev-sources, ha, misc, maxsurge-0, logging
🎬	Pipeline Scenarios	Available scenario list and description

• 🎬 preview ☁️ capd 🚀 kadm 🐧 ubuntu

• 🎬 preview ☁️ capo 🚀 rke2 🐧 suse

• 🎬 preview ☁️ capm3 🚀 rke2 🐧 ubuntu

• ☁️ capd 🚀 kadm 🛠️ light-deploy 🐧 ubuntu

• ☁️ capd 🚀 rke2 🛠️ light-deploy 🐧 suse

• ☁️ capo 🚀 rke2 🐧 suse

• ☁️ capo 🚀 kadm 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capo 🚀 kadm 🎬 wkld-k8s-upgrade 🐧 ubuntu

• ☁️ capo 🚀 rke2 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 suse

• ☁️ capo 🚀 rke2 🎬 sylva-upgrade-from-1.3.x 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🐧 suse

• ☁️ capm3 🚀 kadm 🐧 ubuntu

• ☁️ capm3 🚀 kadm 🎬 rolling-update-no-wkld 🛠️ ha,misc 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 wkld-k8s-upgrade 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 ubuntu

• ☁️ capm3 🚀 rke2 🎬 sylva-upgrade-from-1.4.x 🛠️ ha 🐧 suse

• ☁️ capm3 🚀 kadm 🎬 rolling-update 🛠️ ha 🐧 suse

Global config for deployment pipelines

• autorun pipelines
• allow failure on pipelines
• record sylvactl events

Notes:

• Enabling autorun will make deployment pipelines to be run automatically without human interaction
• Disabling allow failure will make deployment pipelines mandatory for pipeline success.
• if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Closes #2389 (closed)