The Makefile default build target includes bin/synocli, but the
Dockerfile builder stage never copies synocli/ into the build context,
so building the image fails with
"stat /go/src/synok8scsiplugin/synocli: directory not found".
Copy synocli/ so the in-image make behaves the same as in a full
checkout.
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.
- Add DSME 1.0 or above to the supported Synology NAS list (PAS7700)
- Add NVMe/TCP StorageClass example from deploy/example/storageclass-nvme.yaml
- Document 'nvme' in the protocol parameter: creates NVMe namespaces on DSM
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.
The tool executor is capable of running given tools in chroot either by automatically locating the tools in path using the `env` command or directly if the path is known.
This removes the need for the shell script to wrap commands and reduces number of needed external binaries on the node.
Fixes a condition where the default node.startup is automatic and a node
reboots iscsid will attempt to create sessions for all of the targets.
Instead we want the CSI to control when sessions get created.