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)