[infamousjoeg]

That was my first thought, too.

"But... there's a root account... creating another account... which is typically a privileged action. What's protecting that? Is that root account being rotated, too?"

[Flenser]

the master key is split into shards. See under "Why" here: https://www.vaultproject.io/docs/concepts/seal.html

[infamousjoeg]

Sure, the master key is split into shards...

I'm talking about the account creating the database user. Let's take MSSQL, for example. The equivalent to a root account there is `sa`. So, Vault will have control of the `sa` account in order to create leased database users.

If I'm a malicious actor inside the environment, what's stopping me from compromising the `sa` account and mimicking dynamic secrets? I'd need to be comparing Vault logs with Database logs constantly to ensure it was legit.

It's just madness, if you ask me.

[mjlee]

That's protected by Shamir's Secret Sharing the root encryption key, which adds a fairly robust layer of security. It means that (unless you store the key parts in an HSM/Cloud KMS) there's a trade off of having a manual step to get the unencrypted key in to vault's memory.

[drablyechoes]

You can also set up vault to encrypt each shard of the root key with the GPG pubkey for each administrator before dumping them to output. This way, plaintext shards of the root key never even touch the disk or otherwise come into view of anybody other than the intended recipient.