You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not clear from the docs that we are trusting the network on step 4 of the token request flow. We are subject to MitM attacks on the response from the vault-controller back to the init-container. The wrapped token can be unwrapped by an untrusted 3rd party so we must set a timeout or raise an alarm so it can be tracked in the vault audit logs.
The text was updated successfully, but these errors were encountered:
Regarding the timeout issue: Vault has the NumUses seting in TokenCreateRequest structure. Setting this to 1 allows to be more alertful for wrapped token steals.
I wlse see the easy solution to avoid this problem at all: public-key cryptography, be it RSA or whatever.
Vault-init could generate a keypair providing the public key to vault-controller, so controller was able to answer with encrypted message.
Also the Vault transit backend can be used for the same purpose, but it seems harder to implement, since correct policies need to be set up first.
It's not clear from the docs that we are trusting the network on step 4 of the token request flow. We are subject to MitM attacks on the response from the vault-controller back to the init-container. The wrapped token can be unwrapped by an untrusted 3rd party so we must set a timeout or raise an alarm so it can be tracked in the vault audit logs.
The text was updated successfully, but these errors were encountered: