[Bug]: external cluster name and secret selectors flow unsanitized into filesystem paths #11043

When the instance manager dumps connection material for an external cluster, several spec-controlled strings are used directly as filesystem path components without validation.

In pkg/management/external/utils.go, dumpSecretKeyRefToFile and createPgPassFile build their target directory as filepath.Join(getExternalSecretsPath(), serverName), where getExternalSecretsPath() resolves to /controller/external and serverName comes from ExternalCluster.GetServerName() (the external cluster name, or barmanObjectStore.serverName). The file basename is <secret name>_<secret key>, so selector.Name and selector.Key are joined unsanitized as well. A value containing .. therefore escapes the intended directory: filepath.Join collapses the traversal, and the code then creates the directory and writes the file. The pgpass write path in createPgPassFile is reachable the same way and uses a truncating atomic write, so all of these inputs need covering, not only the external cluster name.

The validating webhook does not check the shape of the name today (validateExternalCluster), and the CRD field carries no pattern constraint.

This is not a privilege escalation: anyone able to create or update a Cluster already controls the resulting Pod and the volumes it writes to, so the reachable targets are volumes they already own and PostgreSQL already writes to. It is still a robustness gap. A free-form string flowing into filepath.Join is exactly the kind of input that should be validated regardless of who can reach it, and constraining it also documents in the API that the value is filesystem-bound.

The name is only ever used as a string-equality lookup key, so rejecting a path separator or a .. component is non-breaking. A positive allowlist (such as a DNS-1123 pattern) would not be, since existing clusters may use names a strict pattern would reject.

Reported by @r0binak.

Version

trunk (main)