Privileged Identity Management (PIM) with HashiCorp Vault SSH Certificates

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.