Improve Harbor security on workload cluster with random admin password and TLS

What does this MR do and why?

This MR improves the security posture of the Harbor deployment on workload clusters by applying the same approach previously implemented for NeuVector (see related MR).

Main changes:

• Use a randomly generated password for the admin account instead of a static or predictable value.
• Configure TLS using provided certificates, avoiding the use of auto-generated certificates.

These changes align Harbor’s security configuration with current best practices and ensure consistency with the security model already applied to other components in the platform.

Related reference(s)

• Harbor deployment on workload cluster: #858 (closed)

• NeuVector deployment on workload cluster (reference implementation): #1462 (closed)

Issue #903 (closed)

Test coverage

Automated tests were added using hurl to validate the new security behavior:

• Authentication test verifying that login with the default admin password returns 401 Unauthorized, ensuring that a random password is effectively used.

Before password policy changes: CI test is failing (as expected): https://gitlab.com/sylva-projects/sylva-core/-/jobs/13166289443#L104 Test case: !6972 (diffs)

error: Assert status code
  --> ./tools/login-test/login-workload/harbor-wkld.hurl:42:6
   |
   | POST https://{{rancher_url}}/k8s/clusters/{{workload_cluster_id}}/api/v1/namespaces/harbor/services/http:harbor-core:80/proxy/c/login
   | ...
42 | HTTP 401
   |      ^^^ actual value is <200>
   |
Failure ./tools/login-test/login-workload/harbor-wkld.hurl (8 request(s) in 825 ms)

After password policy changes:

CI test is ok: https://gitlab.com/sylva-projects/sylva-core/-/jobs/13319935099#L105

$ hurl_files=$(ls ./tools/login-test/login-workload/*.hurl) # collapsed multi-line command
Success ./tools/login-test/login-workload/rancher-wkld.hurl (5 request(s) in 561 ms)
Success ./tools/login-test/login-workload/harbor-wkld.hurl (6 request(s) in 2093 ms)

Manual verification included:

• Deployment of Harbor with the updated configuration.
• Validation that Harbor is configured to use provided TLS certificates instead of auto-generated ones.
• Confirmation that Harbor services start correctly and remain accessible over HTTPS.
• Basic functional checks (login and registry access) to ensure no regression in normal usage.

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, okd, ck8s
🐧	Node OS	ubuntu, suse, na, leapmicro
🛠️	Deployment Options	light-deploy, dev-sources, ha, misc, maxsurge-0, logging, no-logging, cilium
🎬	Pipeline Scenarios	Available scenario list and description
🟢	Enabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by mgmt: or wkld: to be applied only to a specific cluster type
🔴	Disabled units	Any available units name, by default apply to management and workload cluster. Can be prefixed by mgmt: or wkld: to be applied only to a specific cluster type
🏗️	Target platform	Can be used to select specific deployment environment (i.e real-bmh for capm3 )

• ☁️ capo 🚀 kadm 🐧 ubuntu 🟢 harbor

• ☁️ capm3 🚀 rke2 🐧 suse 🟢 harbor

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.