feat: added support for WAL-G SSH_PASSWORD #1165
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The original omission of SSH_PASSWORD in #549 was motivated by general SSH best practices, which primarily apply to interactive, internet-exposed SSH usage. In the Spilo + WAL-G context, this assumption does not necessarily hold.
In Kubernetes-based, GitOps-managed deployments, both SSH identities and SSH passwords are ultimately stored as Kubernetes Secrets and therefore have the same protection level inside the cluster (RBAC, etcd encryption at rest, namespace isolation). From that perspective, there is no inherent security difference between the two once they are mounted into a pod.
Moreover, in many GitOps setups, SSH keys are generated outside the cluster and stored (encrypted) in Git, then decrypted by Flux or CI at deploy time. In contrast, an SSH_PASSWORD can be generated directly inside the cluster using standard secret generators, never leaving the cluster boundary at all. For those environments, this can reduce secret sprawl and external handling of long-lived credentials, which is a concrete and practical security improvement.
This PR does not argue that password-based SSH is universally preferable. It simply acknowledges that:
When used as intended (cluster-local SSH, restricted network access, non-root users), enabling SSH_PASSWORD does not meaningfully weaken the security model, while significantly improving deployment flexibility and GitOps ergonomics.
For environments where SSH is exposed outside the cluster, SSH key or certificate-based authentication remains the recommended option.
closes #788 and #819