Well if you’re using consul and your consul is secured, then you don’t need any tokens. the consul operator raft snapshot can save the backup without any extra parameters.
For raft you do need to set your TOKEN but then nobody should have access to the Vault command line. You could wrap the token so at least it isn’t in clear text (or use the transit engine). The rest of it is normal cron steps.
hm, that sounds like what I feared.
No, no consul just the integrated raft storage backend.
But the snapshot itself is encrypted, right?
So there “SHOULD” be a token that can do nothing else but create a snapshot, is there?
From my understanding I would have to create a policy that can read everything,
I certainly don’t want to have a token floating around that can just READ all our secrets.
On the other hand, triggering the creation of an encrypted snapshot wouldn’t be a big security risk (what could happen? denial of service when triggered too rapidly?)
So why should I need a token for snapshotting at all?
That’s misleading question. The backup is NOT encrypted, however you’re backing up data that is encrypted, so the “consul wrapper” is open, but the data that is inside of that wrapper (written by Vault) is encrypted with Vault’s encryption key (which exists either in shard keys or in the auto-unseal key if you’re using auto-unseal) and nowhere else. So is it encrypted? No, and yes.
You can “secure” your consul by creating ACLs and then having to have tokens created and used (consul tokens, not vault tokens). To me, this is extra layer of security that isn’t needed [ in my case ]. My consul servers are inaccessable from anywhere else but the Vault instance, even if I store the snapshots in S3, and the S3 is public, that snapshot is not going to do anyone any good unless they get a hold of my master key, which isn’t included in the snapshot.
My vote is to secure consul for access, and not to enable ACLs, no tokens needed.
thanks aram for your explanations,
but I don’t want to use consul (if I can avoid it) and stay with the integrated raft storage since it’s less complex, one service less to care for.
I’ve not confirmed yet but you should be able to use the command vault read sys/storage/raft/snapshot or the equivalent API endpoint to pull a snapshot.
As @aram mentioned you’d need to have a token setup with access for this (should just need access to the API endpoint only and not the secrets) but you’d want to restrict access to the Vault instances as it would be trivial for anybody with access to pull a backup and anybody with access to the unseal shards to decrypt the content.
The other/better option, if you’re an enterprise customer, is to use the built-in auto-snapshot feature which addresses several of the challenges associated with this.