I’m new to Vault and have been reading through tons of great docs and such but I seem to keep running into a central theme that is bothering me. Whether it is a Vault Agent storing a token in a “sink” file or some other workflow that relies on for example having to obtain a secret-id for an AppRole from a file or here’s the case that really gives me pause, setting up transit auto-unseal.
Let’s just take the transit auto-unseal case as the best example. I need to give this “main” vault instance access to a token that gives it permission to read the “key” from the transit secret engine setup in the “other” vault instance, in order to unseal itself auto-magically 
of course I am not putting the token in the vault config file seal stanza, I want to set the VAULT_TOKEN env var as part of the startup command (systemd etc…), okay great, makes sense so far.
now, I can setup an AppRole at the “transit” cluster but then I need to provide a secret-id to my clusters when they want to start or, as many tutorials suggest, I can use a periodic token and set VAULT_TOKEN to that token value at start
okay, great, great but what if…
the root password is compromised on one of these “main” vault clusters?
in that case the smart attacker can quickly obtain the secret-id and role-id or the value of that periodic token and it’s pretty much game over - unseal key compromised.
the gist I am staring to get from more reading is basically:
well, if root is compromised, you have much bigger problems already anyways,
it is not Vault’s job to protect your root password.
…and that’s fair I think.
I just want to be sure that the “gist” I am getting is basically correct/
Thanks!