FAQ

What's the difference between Vault and traditional privilege access management (PAM)?

Co-founder Armon Dadgar gives a concise explanation about HashiCorp Vault vs. traditional PAM.

Speakers

  • Armon Dadgar
    Armon DadgarCo-founder & CTO, HashiCorp

Transcript

The difference between Vault and traditional privilege access management really comes out of what problems they were created to originally solve.

When we consider traditional privilege access management systems, they really came out of trying to solve the problem of: I have a set of operators—these are database administrators, these are sysadmins—that need access to things in my infrastructure.

If I'm a DBA, I need to connect to a database or if I'm an operator, I need to log into a machine to administer these systems. And I don't necessarily wanna give this group of folks, my operators, all the credentials to all of these systems.

Instead, I use a traditional privilege access system, vault the credentials there, and now, as a DBA, if I want to get access to it, I log in to the PAM tool, I get the database password, and then I connect to it. And, oftentimes, these tools will even do things like session recording and session brokering. So, I'm connecting through the PAM tool and it's recording what I'm doing in that environment, so that if I do something malicious, there's an audit trail to it.

Then when you look at something like Vault and the problem it was trying to solve, it's born in the data center itself and it's looking at: * If I have a low-trust or a zero-trust network, how do my applications (let's say web servers) connect to my databases? Because they need credentials. In that case, our web server needs a database username and password. * Or, how does my web server connect to a cloud and use read and write data from S3? It needs an API token.

Traditionally, if we look at what happened in the data center, we were relatively sloppy with secret management. Credentials were in plaintext, hardcoded in the app. They were in config files. They were in config management. They were in version control. They're all over the place.

But we trusted our applications because they were part of a high-trust network. As we go to the low-trust or zero-trust network, we can't be as sloppy.

We need to centrally manage those credentials, encrypt them, access control, and only give them out as needed in the least privileged way. Vault's focus has really always been on applications and how they get access to endpoints and systems versus traditional privilege access management, which looks at 'how do people get access?'

These are two very different problems. On one side, we're looking at people identity and tying into single sign-on systems like active directory, and the rate of access is very low. We might be running a single instance of privilege access management that's doing a few requests a minute. Versus if you look at a system like Vault, you have thousands of applications that aren't tied into something like an active directory. They need a notion of service identity. They're integrating into AWS, integrating into Azure to get that sense of identity, and they might be doing thousands of requests per second.

And so that's a system that we might need to be highly available, distributed globally, and fine-tuned to application access patterns versus doing relatively infrequent low-scale privilege access management. This ends up being a pretty key distinguisher, in terms of 'what's the focus area' and 'what are the systems optimizing for?'

More resources like this one