Tokens should support restricting by IP

[icebourg]

Currently, you can restrict tokens by use count and by time, but I would love to add another element and restrict tokens by cidr block as well. (similar to how you can restrict a user-id by cidr block) I can see this being generically useful for a to of organizations.

I would be willing to implement it and submit a pull request as it's a feature I would use right away as an additional layer of safety, but before I go to the trouble, I wanted to check to see if there are and reservations.

I figure it would be closely modeled after the cidr_block implementation for user-id. (#10)

[jefferai]

It's a good suggestion, and I'm going to add it to our roadmap. I can't promise when/if it will show up but we will definitely discuss it.

One thing that will have to be thought about is how to deal with cases where you are behind a load balancer; PROXY support and/or X-Forwarded-For might be good approaches here.

Thanks for filing!

[certifiedloud]

This would be security through obscurity at best. At worst it tempts the Vault administrator to rely on IP filtering, which is bad because IP addresses are trivially spoofed.

[jefferai]

@certifiedloud There's nothing wrong with defense in depth.

[certifiedloud]

I'm not saying that obscurity has no place in a security model. But in this case it is implied that the attacker already has a token, so this layer of obscurity is pretty thin. Is it worth the time to implement?

[icebourg]

I'm certainly not asking you to spend time implementing it, @certifiedloud. Or use it. :) It's just one more primitive that can be used by Vault administrators to customize their Vault to their specific security needs. Just as not every use case will benefit from limited use tokens, or time-limited tokens, no doubt not every case will benefit from IP restricted tokens.

[jefferai]

@certifiedloud It's basically the same concept as channel-binding. Is it enough on its own? No. But it helps.

You are making an assumption that an attacker can successfully spoof an IP. But this is not necessarily a correct assumption. An unprivileged user that happens to find a Vault token lying around may not have either the knowledge or ability to spoof an IP, but this could help prevent them from using the token. Sometimes it's enough to remove temptation to keep a user from trying something nasty.

Defense in depth has been the ideal at every company I've worked for, including HC. I think it's a totally valid concept and I'm happy enabling features that allow other companies to implement it.

[tasdienes]

I'll second the request

[narayan8291]

@jefferai @icebourg This would make VAULT more secure in a infrastructure similar to ours where we use VAULT majorly to replace secrets in application code. These server-side applications sit on physical machines and the code sits in our git repo.

Right now, any user can grab this token and make a curl request to get the secret value even when the token was not provisioned for that user/group. (This is the case where developers hardcode tokens in app code)

Since we have SSH restrictions in place for users/groups and if we have IP based restriction then it would not be possible for a user to get the secret value with the token since it was not provisioned to the user and also the user has no access to ssh into the designated server.

Any ETA on this feature ?

[jefferai]

No ETA currently.

[joaquinrinaudo-olx]

I'll third this request. This would help adding a second layer of defense.

[dgonzalez]

We really need that. We are actually struggling on how to deliver the first set of credentials to obtain the token and the only valid outcome was an IP lockdown so only production servers can access secrets with a certain token.

I would back it up as well.

[rakesh-eltropy]

We also need it. Any ETA of this feature ?

[jefferai]

None currently.

[apuravchauhan]

I am also confused about how an IP whitelisting can solve this problem since, IPs can be spoofed in header. The way I am thinking to solve is not to have this token hardcoded in the client code but to keep them in some file at location X where the client code is deployed. The client can read this file to get the initial token.
Also Vault admins can add a script where these initial tokens can easily be rotated and old ones invalidated

[icebourg]

I'm still confused by the thought that adding an additional layer of security reduces the security of Vault. Sure there are plenty of use cases that something like this may not help. Especially if you are in a data center that has no protections for arp poisoning or if your load balancer doesn't overwrite XFF headers. But naive Vault administrators could just as easily do something dumb like place their Vault tokens in web accessible directories or a hundred other dumb things.

But there are plenty of valid use cases this could enable to help harden security. Let me give you one example we would probably use in our organization. We have an web-facing application that will one day talk to Vault. Imagine this application has a heart bleed type vulnerability discovered and it leaks its Vault token. Without an IP restriction, all you need to do is find some other vulnerability somewhere else to use the token you stole. Maybe you pop a developer's box and use it over our VPN. Maybe you pop our billing system somewhere else. I don't know. You get the idea.

But if on provisioning that token we restricted it to the IP address of the instance, you would then need to pop that specific box to use our token to do nefarious things. Maybe you can. And maybe you can't. But it won't be good enough to pop a developer box, you need to pop the application box and at that point if you can do that, the heart bleed leak of Vault tokens likely wouldn't have mattered. Either way, it's a primitive that will help us reduce attack surfaces.

The more ways we can do things like this, the better security we have in infrastructure that is set up to take advantage of it. I can definitely imagine a number of scenarios where this would be useless but I can think of a number of situations where this would be really useful to me.

[jefferai]

@icebourg I'm confused by it too.

[ArcticSnowman]

Something to add to this... it be great if this IP was available for the database backends to use in their 'CREATE USER' and 'GRANT' statements, so that IP can be used to improve the security of the generated users on the DBs..

[mikerwilson]

+1 on wanting the ability to restrict tokens to specific CIDRs as another layer of client-validation. Yes, IPs can be spoofed, but it requires yet another step. I expect to have thousands of issued tokens and would like to be able to ensure a specific token is being used only from its intended target machine.