Vault's product managers and the HashiCorp founders have, in the past, established a fairly clear difference in the target market and solutions between traditional Privileged Access Management, Secrets Management, and Data Protection.
Privileged Access Management or Privileged Identity Management, as a use case or solution, refers to delegation of access to human operators, e.g. when a Kubernetes administrator needs to temporarily get access to an Azure account to review logs.
The Secrets Management use case needs a system to broker access among various systems and the platforms on which they run, e.g. when a Kubernetes Pod needs to access an S3 service.
Last but, in my view, most important, the Data Protection use case needs a way to set and enforce policy for limiting access to data, typically using cryptography via encryption, or even Encryption as a Service.
Some examples of cases where HashiCorp representatives have shied away from HashiCorp replacing PAM:
Vault Identity Design Goals (Note that LDAP Sync is not on the table): https://www.hashicorp.com/resources/vault-identity-system
Vault vs Traditional PAM tools: https://www.hashicorp.com/resources/difference-between-vault-and-traditional-pam
That said, HashiCorp has recently begun to pay more attention to Vault's potential to meet a few of the needs of PAM and PIM systems.
The website vaultproject.io just added PIM as a first class use case, next to Secrets Management and Data Protection: https://www.vaultproject.io/use-cases/identity-based-access
I'd like to discuss a common PIM scenario, and how developers can, with relative simplicity adapt a system like Vault to accomplish this.
Example scenario: I need a developer, named Pedro, to use a read-only user on a host OS whose SSH server trusts an SSH Certificate Authority in Vault.
Pedro logs in to the Vault GUI or CLI via SSO, and his policy gets him a 15-minute SSH certificate from the Signed SSH Certificate Secrets Engine.
Now Pedro can use that fresh 15-minute SSH certificate to log in as the read-only user.
NOTE: We can also create a user, and give Vault an SSH key for that user, to control single use authentications to servers. Vault would then log every authentication to its audit log. The process is slightly different from this, as it does require the SSH server on the host OS to talk to Vault as part of the SSH server's login flow. The SSH server would ask Vault if Pedro's login is still valid.
sequenceDiagram
Admin ->> Vault: Set up SSH Certificate Secrets Engine Role
Admin ->> Vault: Create Vault Policy which gives access to the above
Admin ->> Vault: Associate Pedro's AD group with that Vault Policy.
Admin ->> Ansible: Give Public Key from Vault SSH Certificate Secrets Engine to Ansible
Ansible ->> RHEL OS: Add pedro user w/limited permissions
Ansible ->> RHEL OS: Add Public Key from Vault SSH Certificate Secrets Engine Role to SSH Server
Pedro ->> Vault: Log in with AD credentials
Vault ->> AD: Get Credential validity and memberships
Vault ->> Pedro: Vault Token
Varun ->> Vault: Request SSH Cert using Token
Vault ->> Pedro: âś“ SSH Cert for pedro userâś“
Pedro ->> Vault: Request DB credentials
Vault ->> Pedro: ❌Permission Denied❌
Pedro ->> RHEL OS: ssh pedro@RHELOS
RHEL OS ->> Pedro: âś“ SSH connectionâś“
Pedro ->> RHEL OS: ls
Pedro ->> RHEL OS: scp pedro@RHELOS:/home/varun/applog .
Pedro ->> RHEL OS: systemctl stop consul
RHEL OS ->> Pedro: ❌Permission Denied❌
Note:
Vault has some other specific PIM features.
Active Directory Secret Check-In/Check-Out: In the Active Directory secrets engine, users or applications can check out a service account for use, and its password will be rotated when it's checked back in.
Top comments (0)