I’ve noticed that if I forward web connections via a bastion host + a client in a private subnet that has Vault access that something concerning occurs. if the deplooyment is destroyed and redeployed, my web browser can stay logged in, even after a day/week.
Steps to reproduce:
- deploy vault (I’m using an s3 backend)
- forward a web connection from a client in the private subnet
- login from safari with an admin token
- destroy infrastructure (but keep the s3 bucket)
- redeploy with all new hosts
- safari web browser is still logged in and able to browse secrets.
Do you have any clues as to how this might be possible and what steps I should be taking to prevent it?
Since that vault client in the private subnet is being destroyed, nothing should persist data to maintain the web session. The token must be embedded in my safari session, even after all that time, when I would have thought something like this shouldn’t really be possible.
The s3 bucket contains all secrets as well as current tokens. Therefore destroying the actual hosts makes no difference - they don’t store anything important themselves.
If you login you will be given a token (which would be stored as a cookie in a web browser or a local file using the CLI). At the same time details about that token are stored on the server side (in the s3 bucket), including how long the token is valid for, and what it can access.
As long as the client and server both have details about the valid token you’ll be able to access secrets. This is exactly how things are supposed to be working.
If you want to remove access you need to disable the token. All tokens can have a time limit before they are automatically revoked, or you can do that manually. Removing the token from the browser is also possible, but if the token isn’t revoked it doesn’t actually stop any access if you re-enter the same token details at a future point.
What are you wanting to be able to do, as currently everything is working as expected…?
1 Like
Thanks for that explanation! I can see how that would be beneficial in many scenarios, especially apps, I suppose I need to rethink how I should work with the options available.
I have read token create - Command | Vault by HashiCorp
and gone through hashicorp learn, but I think I still have gaps on applications of tokens for their various use cases.
I can see how an admin token with just an explicit-max-ttl is probably not a good idea.
So if we login with a token, and the web browser stores a cookie, does that cookie contain the actual same token as well? or just a reference to a session (like some kind of accessor id)?
Perhaps also other limits get applied restricting the use once you are logged in?
Or could someone lift that cookie and use it elsewhere?
I suppose what I was wondering was, if I provide an admin token for myself and I want to have access for say 30 days (explicit-max-ttl), what would best practice be for me to have obfuscated the initial token once I’ve initially logged in and used it?
- Should I set a short ttl (10mins) for its first use, requiring an immediate auto renewal? Does renewal work if set a use limit of 1 for initial login?
- Perhaps a “-period” of 1 week, so that if I dont renew in that time, it becomes invalid?
- or should I consider other options?
-What happens when that 30 days is up?
-Should I also have some other set of TTLs for a higher level admin token, used rarely to recreate other admin tokens?
If the TTL’s are not set correctly on that, then I could have to use the root token, which from my understanding should probably be deleted in production once the right workflow is proven.
Thankyou for any pointers on good workflows here!
When you say “admin token” are you meaning root token? If so, it is best practice to remove the root token as soon as possible and instead use tokens only from other auth methods (e.g. AppRole or OIDC) which have more limited permissions.
With regards to the token, yes if you get the token (e.g. from your cookies) you can use it elsewhere - a token is a secret that must be kept secure. You can apply limits to try to reduce the impact or chance of a loss, such as limited permissions, CIDR limits, short durations or number of usages.
If you set up a TTL and either don’t allow renewal, allow renewal but have already used it up (i.e. are at the max TTL value) or don’t renew the token will expire and no longer be valid.
For a person I’d suggest that 30 days is quite a long time. For a more privileged set of permissions I’d even suggest having a pretty short TTL as you can renew it if needed or just create a new one using something like OIDC auth.
If you no longer need a token you should revoke it rather than letting it expire some time later, both because it will reduce the impact on the Vault server (more active tokens needs more CPU, memory and storage to handle) and to remove the possibility of a leaked token being misused.
Ok thankyou @stuart-c.
I’ve probably established an anti pattern because I avoided OIDC until I could find a provider where MFA could be available available freely. Are there any where it is possible?
Initially I tried Auth0, but then found no MFA so I avoided it.
When I said admin token, I meant I created a policy for an admin user that has all the abilities that are required for alteration. I’m not using the root token, except if the admin token expires after a long duration, but I definitely need to improve that.
How are you currently authorising people?
You could for example use GitHub authentication which can have MFA
I thought that once you have a token from github thats it, it didn’t look like MFA, but I would love to be wrong…