On each server, we could create SSH keys to access the backup server. Those keys can stay there, and regenerated as needed. Only the public key is interesting for us.

rOPS Salt development

Add to _modules/credentials.py a method to WRITE a secret, and perhaps something in a new _states/credentials.py too. It then needs rights to write instead of just read.

Salt state

ssh_key_backups:
  cmd.run:
    - name: ssh-keygen -t ed22519 -f /path/to/key
    - creates: /path/to/key.pub

ssh_key_backups_publish_to_vault:
  credentials.write:
    - name: backups/servers/{{ grains["id"] }}
    - data_from_file:
        public: /path/to/key.pub
    - onchanges:
        cmd: ssh_key_backups

Then the backup server will be able to generate a SSH key listing secrets in ops/secrets/backups/servers (need rights to) and reading each one.

Alternatively, that file could also be generated by a script called in Makefile:

#!/bin/sh

:>authorized_keys
for secret_path in $(vault kv list ops/secrets/backups/servers)
do
    vault kv get ops/secrets/backups/servers/$secret_path | jq ...data...public... >> authorized_keys
done

Not sure if that information is important in the repository, as it's machine-to-machine automation and communication. We would have more nodes and etcd or Consul available, that would be a good etcd/consul candidate, as it's not a secret neither.