TLS auth method and PKI secret

Vault
1

Hello,

This is my first post here as a Vault novice so please let me know if you need more informations.

I am trying to use vault to issue pki certificates that can be used by hosts to authenticate to vault. Basically, it is matching the restrictions on PKI secret engine with TLS auth method restrictions in order to apply proper policy on the tokens.

These certificates are only used for this purpose and not for web tls. The issue I face is that I can’t wrap my head around the proper way to do it.

First, should I have several pki secrets engines and auth endpoints or several roles on one secret engine and corresponding roles to an auth TLS endpoint ?
From what I have read on this topic, am i right to think the first option is better for maintenance, audit and single responsability principle ?

Then, the problem I struggle the most with is the following. What attributes, SANs or metadata should I use so that the secret engine is able to issue certificates including them and the auth endpoint is able to restrict access plus allowing ACL templating ?

I first thought of metadata extensions but only the auth method is aware of these attributes and the pki secret engine isn’t able to include them.

EDIT: I’ll be a bit more precise with an example :
Let’s say I want to issue a certificate for a host host1. This host should also access other secrets like kv etc. host1will use its certificate to auth to vault with TLS auth method.

If i have a kv2 secret engine at /secret/kv2/host1/ specific for all bearers of a certificate with the host1 criteria, which cert attributes should i use in order to allow acl templating as I will have a lot of different use cases to handle.

Thanks for your time.

2

I would disagree:

  • Maintenance is made harder if you have to maintain a diverse set of configurations
  • Audit is made harder if you have to audit a diverse set of configurations
  • I view “handing out certificates for the correct names only to the correct people” as a single responsibility, unless the organizational structure is so devolved, that this is for some reason not feasible … in which case I think you’ll run into lots of problems determining who is allowed to write what in Vault policy configuration text.

Looking at the feature overlap of both, there appears to be exactly one option that is viable - the Common Name part of the Distinguished Name, so that throws extension attributes and SANs in the bin right away.

Also, IMO, ACL templating is not all that flexible, and you should not pin your hopes on it for most use-cases. It’s really only useful for giving a single identity (so, 1 host) access to a private sub-path containing its own name.

1 Like
3

Thank you for your response.

I will try to limit endpoints then. It makes sense.

For the feature overlap, I am a bit confused because if I read the api documentation

  1. Common Name seems to work

  2. Alternative Names, DNS SANs, IP SANs and URI SANs have allowed_X but it really means allow_X ?
    Is this the meaning behind :

No authorization checking is performed except to verify that the given values are valid XXX

If I understand correctly the restrictions are about formatting and not values.

What if i need more than one attribute ? I can have only one common name so at the hand of the day, as you mentionned, the configuration is rather manual because all cases have to be handled specifically.

I was hoping to have attributes OIDs or SANs on a certificate and template acl with them and all bearers of certificates with the same attributes authentiticating at the right endpoint could have access to the same things. Somehow like this : Add certificate extensions as metadata · Issue #13347 · hashicorp/vault · GitHub