Draft: Propagate ca.crt(ca-key-pair) from mgmt-cluster to wkld-cluster(OS) (!4545) · Merge requests · Sylva-projects / sylva-core

What does this MR do and why?

This MR is part of ongoing work related to issue (#1892 (closed)) and it tries to cover the gap highlighted in the comments in the discussion(!4362 (comment 2512023220)) where we are trying to put CA cert from ca-key-pair Secret from cert-manager namespace of management cluster into the workload cluster nodes OS trusted CA path.

This MR is basically introducing a kustomization unit called copy-ca-to-wkld-cluster-hostos which deploys Daemonset and a configmap in the target workload cluster. In this process the configmap which holds cert data (i.e ca.crt content from cert-manager in mgmt-cluster) is used with hostPath mount option in Daemonset and get copied to CA trusted path of OS.

There is also a kyverno policy mutation rule which continuously watches the ca-key-pair secret for any update and patches the kustomization unit copy-ca-to-wkld-cluster-hostos with updated cert data and a checksum data which in turn annotate Daemonset spec's template section and updates configmap data with new ca.crt and restarts pods of Daemonset in target workload cluster which eventually places updated cert at trusted path. The following picture shows the process

Depending on OS type certs are placed at different path as can be seen from picture

This automated mechanism of placing certs in OS of workload cluster(via Daemonset and configmap) chosen to avoid any unplanned node-rolling update as discussed in comments(!4362 (comment 2512023220))

This automated process of placing cert at trusted path would only come into picture when additional_ca (introduced by MR sylva-projects/sylva-elements/helm-charts/sylva-capi-cluster!677 (merged)) is not supplied. If additional_ca is supplied then the kustomization unit copy-ca-to-wkld-cluster-hostos won't get enabled and the cert content provided under additional_ca will appear in trusted CA path of OS.

copy-ca-to-wkld-cluster-hostos:
    enabled: '{{ empty .Values.cluster.additional_ca }}'

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`, `no-logging`
🎬	Pipeline Scenarios	Available scenario list and description

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.

Edited Jun 02, 2025 by Amit Kumar

Draft: Propagate ca.crt(ca-key-pair) from mgmt-cluster to wkld-cluster(OS)

What does this MR do and why?

Global config for deployment pipelines

Merge request reports