The DSM WebAPI client disabled TLS certificate verification for all
HTTPS connections (InsecureSkipVerify: true), then sent the configured
DSM account and password to the endpoint. An attacker able to intercept,
redirect, or impersonate the DSM HTTPS endpoint could therefore obtain
the DSM credentials stored in the CSI client config / Kubernetes secret
(CWE-295 Improper Certificate Validation, OWASP A3:2017 Sensitive Data Exposure)
TLS certificate verification is now enabled by default. The client trusts
the system CA pool, so certificates signed by a public CA work without
extra configuration. Three optional client-info fields are added:
- tlsCACert: PEM CA cert to trust (for DSM self-signed certs);
merged with the system CA pool.
- tlsServerName: override the name checked during verification,
e.g. when connecting by IP.
- insecureSkipVerify: explicit opt-out that restores the old behavior;
logs a warning on every connection.
The new fields are propagated through all DSM construction sites
(service, synocli, and the HA GetAnotherController path).
BREAKING CHANGE: deployments using `https: true` against a DSM with a
self-signed certificate (the DSM default) will fail to connect after
upgrade until they set `tlsCACert`, `tlsServerName`, or (discouraged)
`insecureSkipVerify: true`.
Adds TLS tests covering default-reject, valid-CA accept, wrong-CA reject,
insecureSkipVerify opt-in, and the tlsServerName DNS-SAN scenarios.
Instead of checking the existence of chroot target directory runtime, only enable chroot on the node daemon. This way the service will fail early if the chroot doesn't exist, instead of printing an error during runtime.
benzheng
chihyuwuandbenzheng
Yordi Pauptit
Yordi PauptitandGitHub
Yordi Pauptit
Sami HaahtinenandSami Haahtinen
Ruslan Timofieiev
GautierLeblanc
inductor
haochengkuo