Limit Vault PKI cert common name to user

Vault
1

Attempting to use Vault PKI engine for user-based certificates, where the common name would be userX@domain.com, and users would auth via LDAP to issue the cert. This functionally works using a PKI role with allow_glob_domains = true and allowed_domains = *@domain.com.

How can we restrict this so LDAP user1 can only issue user1@domain.com, and LDAP user2 can only issue user2@domain.com?

Options seem to be:

  1. One role per user where allowed_domains = userX@domain.com. Poor solution, but could technically work if we develop a process to precreate roles for users. (hundreds to thousands)
  2. Sentinel policy to evaluate common_name against user identity. Seems possible if common_name can be read from the data, but not yet tested, and obviously requires Vault Enterprise.

Ideally this would be a natively supported use case in the role options, or by supporting templating in allowed_parameters. As far as I can tell, ACL templating is still only supported in path statements. If it was supported in allowed_parameters, something like this should work:

ā€œcommon_nameā€ = ["{{identity.entity.aliases.auth_ldap_a123b4c5.name}}@domain.com"]

Are there other options here? Do people use Vault PKI for user-based certificates?

2 Likes
2

I was actually attempting to do something similar and ran into the same problem. In my case, Iā€™m using host-based certificates, and I want a host to be able to issue a certificate with same common name as its own as a way of renewing its own certificate without needing additional authentication.

I tried the same type of policy that you highlighted, only to learn that templating only works in paths:

# This does not work
path "pki_int/issue/example-dot-com" {
    capabilities = [ "create", "update" ]
    allowed_parameters = {
        common_name = [ "{{identity.entity.aliases.auth_cert_5f595bf8.name}}" ]
    }
}

I would also like to avoid solution 1 since I donā€™t want to have a role for every single user, and am using non-Enterprise.

As far as I see it, there are two ways to enable these kind of uses cases. Iā€™m not sure which is more work because I havenā€™t looked at Vaultā€™s source yet:

  1. Allow templating in the policies outside of the path, or at least just in allowed_parameters.
  2. Add a field to the role similar to allowed domains that can reference the identity of the invoking user, similar to how you would with a template.

In the mean time, if youā€™ve found any work-arounds, Iā€™d be curious to hear about them. Iā€™m still evaluating vault, so I may abandon certificates for the time being and use something else for authentication.

1 Like
3

Oh, good news, something I missed when searching the first time: it looks like thereā€™s already some effort to enable some form of templating / referencing identity in the allowed domains of a cert role:

Hereā€™s hoping!

4

Hi! I have the exact same requirement and blocking problem. I just opened another topic here on it: Vault PKI role to limit CN/SANs to requesting user's identity

Did you ever find a solution/workaround? Even with domain templating it appears itā€™s impossible to actually limit PKI issuing to a userā€™s identity when using email