3 ms·
You're looking at a bad example. Good backup encryption generates a local AES key on a ramdisk, encrypts the backup with that, decrypts the AES key with a publi
by tetha 8y ago
You're looking at a bad example. Good backup encryption generates a local AES key on a ramdisk, encrypts the backup with that, decrypts the AES key with a public key and stores the result. This makes it cryptographically hard to access the backups. The host never has access to the private key to decrypt the AES key to encrypt the backup into a usable form. There's no vault involved there because public keys aren't security relevant.
On the other hand, we're running a lot of mutual TLS authentication via CAs in vault. Vault has the private key of these CAs, and authenticated hosts can request signed client certificates for these CA chains. In this case, vault enforces certificate parameters, TTLs, CLR and other things. You could keep requesting certs, but once I revoke the vault authentication you stole, you're done once the certificate expires within 3 days.
And on top of that - yes, it's possible to escalate to vault using local credentials for vault. However, that's a very different threat level. Botnets won't abuse your vault instance. Heck, script kiddies wouldn't know how to abuse your vault instance after getting shell access.
If someone can RCE into a box, and find your vault integration, and abuse your vault integration, you're in for a ride and usually, vault won't be your problem at this point.