[Do not merge] Identity templating for PKI roles allowed_domains and allowed_uri_sans

[jdollard]

This PR expands upon PR 6558. It adds support for identity templating in the allowed_domains and uri_sans options of PKI engine roles.

Sample role configuration that leverages this templating functionality:
vault write pki/roles/foo
allowed_domains='{{identity.entity.aliases.auth_userpass_d908e1ec.name}}.foo.com'
allowed_uri_sans='spiffe://foo.com/{{identity.entity.aliases.auth_userpass_d908e1ec.name}}'
allow_subdomains=true

[hashicorp-cla]

All committers have signed the CLA.

[jefferai]

The same larger questions as in the previous PR are relevant here too

[jdollard]

The same larger questions as in the previous PR are relevant here too

@jefferai - It'd be great to get your input here on what changes would make this acceptable to merge. In the previous PR you'd mentioned the larger questions of "which parameters such templating should be activated (existing, new, or both), and whether by default or not"

Regarding what parameters should have templating activated on them - right now this PR adds support for allowed_domains and allowed_uri_sans. I picked these two parameters because there's a clear need for template support for both; I need it for my use case, as did others in the parent PR. I'd be happy with either adding more fields as the need arrises in the future, or adding more at this point if you've got an opinion on where else it's needed.

With regards to if templating should be enabled by default or not - this PR adds support by default, and doesn't give users a way of disabling template support. The current approach is simple, but does introduce a small performance penalty. The bigger concern may be if the template starting delimiter "{{" appears within a string that's not intended to be a template. I believe '{' is allowed in the local portion of an e-mail address, so this may be a real concern (although perhaps unlikely to happen in practice). This could be addresses by adding another parameter to PKI roles that specifies a list of fields that should have templating applied ("enable_templating"). By default it would be empty. Would that address your concern?

[jefferai]

No, this is something that the Vault team needs to discuss and figure out the way forward...not just something that works for pki but the overall approach for templated parameters across all plugins.

[bheiskell-datto]

@jefferai, has the Vault team had time to discuss an overall strategy for templated parameters?

[dustin-decker]

My company has had strong need for this for a long time now. We have considered forking the PKI plugin to enable this functionality. 🙏

[carnei-ro]

Looking forward for this

[ncabatoff]

Thank you for working on this feature, it is clearly in high demand. We're sorry it took so long to come to a consensus internally on how to proceed, but we finally have. As you may be aware, there are currently 2 open PRs trying to implement identity templating for PKI, of which yours is one: #7216 and #8509. It would be great if you would coordinate amongst yourselves to see who has the time and inclination to move forward with the proposal.

The proposal:

• Add a boolean role option allowed_domains_template to control whether the allowed_domains option will be interpreted as possibly containing an identity template that should be expanded. This will provide consistency with what was done in the ssh secrets engine with the allowed_users_template parameter (identity propagation in ssh secrets engine #7547 #7548).
• This looks a bit like what Add option allowed_domains_template enabling identity templating for issuing PKI certs #8509 is doing, but in Add option allowed_domains_template enabling identity templating for issuing PKI certs #8509 allowed_domains_template is a string that is given as an alternative to allowed_domains, rather than a toggle that controls how allowed_domains is interpreted.

Other requirements:

• There need to be tests that exercise the new behaviour; there may be other tests as well, but there should be at least one that actually exercises the full behaviour, i.e. create a role with allowed_domains_template=true, then try to generate certs with that role that rely on the expanded template and cover both the happy path (e.g. CN in the cert request matches expanded allowed_domains) and the less happy paths. TestBackend_URI_SANs is a decent example of the pattern we have in mind.
• Use the framework method PopulateIdentityTemplate.

Not a strict requirement but a suggestion: limit the PR to allowed_domains. #7216 includes templating for allowed_uri_sans. This isn't a deal breaker, but the more narrowly focused the PR, the easier it will be to get it approved. We would prefer to see allowed_uri_sans handled in a separate PR (in the same way, with a new allowed_uri_sans_template role option.)

[heatherezell]

Due to PR age and inactivity and the do-not-merge label, I'm going to close this PR. Please feel free to re-open it when all of the concerns are able to be addressed. Thanks!