ssh secrets engine identity templating for allowed_domains

[nvx]

Is your feature request related to a problem? Please describe.
The PKI secrets engine allows identity templating in the allowed_domains, and the SSH secrets engine allows identity for the allowed_users field. Unfortunately the SSH secrets engine does not allow identity templating for the allowed_domains field yet.

The use case for this is similar to the existing PKI allowed_domains templating, or SSH secrets engine allowed_users templating to allow a generic role to fill data from auth identity information.

Describe the solution you'd like
Allowing identity templating in the SSH secrets engine allowed_domains field. This should be disabled by default with a new flag allowed_domains_template on the SSH role to enable this behaviour. This matches the behaviour and naming of the existing functionality in PKI and SSH secrets engines.

This should also allow partial matching, eg allowed_domains = "{{ identity.entity.name }}.example.com" (related to #10388)

Describe alternatives you've considered
Creating a role or policy for every system can be used instead, but this requires more configuration and increases the likelihood of human error and increases management overhead so is a less than ideal solution.

Explain any additional use-cases
A system can have the hostname in identity information (eg, an AppRole auth secret_id could be created with metadata including the hostname). This can allow policies to enable that system to obtain a signed SSH server certificate automatically. This is analogous to an existing use-case that is already met with the PKI secrets engine allowing a host to obtain certificates for its hostname.

Additional context
SSH secrets engine create role docs: https://www.vaultproject.io/api/secret/ssh#create-role
PKI secrets engine create role docs: https://www.vaultproject.io/api-docs/secret/pki#create-update-role

[pmmukh]

Hi @nvx ! Thanks for submitting this issue! We discussed this internally, and this is certainly a change that seems valid to us. I think implementing this along the lines of how allowed_domains is templated in the PKI secrets engine as you've suggested is the way we want to go too. We may not get around to implementing this soon, but I'm marking it as open for contributions, so you or anyone else is free to take a stab at this meanwhile!

[nvx]

Hi @nvx ! Thanks for submitting this issue! We discussed this internally, and this is certainly a change that seems valid to us. I think implementing this along the lines of how allowed_domains is templated in the PKI secrets engine as you've suggested is the way we want to go too. We may not get around to implementing this soon, but I'm marking it as open for contributions, so you or anyone else is free to take a stab at this meanwhile!

Sounds good. I'm going to focus on updating PR #7277 first, but once that's merged I'll definitely move on to this one next!

[pmmukh]

sounds great, and thanks!! :)

[git-noise]

Hello,
This looks indeed promising and would allow for greater security and finer control on signed-key issuance. Is it still on your todo @nvx?

Many thanks,
Best,

[f4z3r]

Hi guys, I looked at this issue, and it turns out this is already possible to due a feature/bug. Essentially enabling allowed_users_template will enable templating for users when signing user certificates, but also for domains when signing host certificates. I guess this is not intended.

In the coming days, I will push a PR that adds the allowed_domains_template field, enables templating for domains, and fixes the issue that allowed_users_template only enables templating for users.

[schultz-is]

Thanks to @f4z3r this is now implemented by #16056 . Thanks for the feature request @nvx !