Introducing Vault Advisor

Transcript

One of the groups at HashiCorp is what we call HashiCorp Research. And the goal with HashiCorp Research is for us to look 12, 18, 24 months out ahead and try and understand—what are the next generation of problems users of our tools are facing? And one of the problems we started looking at a while ago was looking at Vault and understanding—are people configuring it correctly? And if they are configuring it correctly, Can we do a more intelligent analysis of the usage of the system to help them refine that configuration?

This line of thinking is what led us ultimately to Vault Advisor, which is a tool we recently announced, looking at—how do we consider the workflow for a system like Vault, or any security system? And understand there is this key gap, which is, as a security person, I’m tasked with configuring a system like Vault before any user is able to use it. By definition, a system like Vault doesn’t allow access that is not authorized, so I, as a security professional or Vault administrator, have to first authorize access.

The guesswork of Vault administration

This creates this interesting challenge: Before there is any real usage of the tool, I have to guess how will this thing be used. I have to reason about the access patterns. What are the secrets the customer might need? How will the application interact with Vault?

In general, what we do is make an informed guess. We are making a best guess as to what the access pattern will look like. So we start with that guess and we model that as a Vault policy. We write our policies in such a way to say, “Great, the web server has access to these credentials, and Armon has access to these credentials. And we’re installing those policies into Vault in advance of either the web server or Armon actually using it.”

What ends up happening is we’ve installed those policies, and now those things show up. Web servers start interacting, they request credentials, users like me log in and fetch credentials out of the system, and so now I start to interact with it. And what this does is it ends up generating an audit trail. So with Vault, we have rich auditing around who is doing what, and this generates a whole trail of, “At this time, Armon accessed secret X, and at this time, Armon accessed secret Y.”

An intelligent advisor

But what we’re missing is some way to close that loop. As a security person, in advance, I modeled, This is how I think the system will be used, and then as a user, I leveraged the system, but there’s no closing of that feedback. And that was our goal with Vault Advisor: Could we automatically consume that audit log of who is doing what and then look at the way the system is configured to find opportunities to do a few different things?

One opportunity is—can we look at reducing the risk by automatically removing access? For example, maybe I’m granted access to 500 credentials but I only use five of them. If my account is compromised or the subject of a phishing scheme or some other unforeseen security breach takes place, instead of me being able to get access to 500 credentials that I don’t need, what we want to do is have Vault Advisor detect that I only need five and rewrite the policy so that only those five are accessible to me. In this way, we can reduce the surface area of attack.

The other type of analysis we can do is look at those configurations and say, “Is there a way to simplify them? Can I give you the same level of access that you need but with a dramatically simpler configuration of the system?” The role of Vault Advisor is to inspect how the system is being used, inspect how it’s configured, and be an intelligent advisor in terms of, How can we rewrite those configurations to achieve either lower attack surface or lower complexity of configuration?

This is still an early project for us. There is a lot of interesting work and research to be done there, but we’re excited to be able to share it with the community more broadly.