Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SSH Secrets engine: allowed_users templating strict regex #10388

Closed
adongy opened this issue Nov 12, 2020 · 2 comments
Closed

SSH Secrets engine: allowed_users templating strict regex #10388

adongy opened this issue Nov 12, 2020 · 2 comments

Comments

@adongy
Copy link
Contributor

adongy commented Nov 12, 2020

Is your feature request related to a problem? Please describe.

Hi, reading the documentation on the SSH secrets engine, we can leverage identity templating in the allowed_users part : https://www.vaultproject.io/api-docs/secret/ssh#allowed_users_template

After testing it, it turns out the templating detection uses a pretty strict regexp

matched, _ := regexp.MatchString(`^{{.+?}}$`, principal)

The surrounding ^$ makes it so that I can't use templating in the middle of the principal.

Concrete examples:

This is valid and will perform as expected:

allowed_users = "{{ identity.entity.name }}"

This is valid, but will not apply templating (and Vault will expect the exact value to be a valid principal)

allowed_users = "username-{{ identity.entity.name }}"

Describe the solution you'd like

I believe the strict regexp was useful when the allowed_users_template did not exist in the initial PR #7548 but operators have to explicitly opt in to the templating now.

I would like to relax the regexp so that I can use the feature more flexibly.

This would fit my expectations of how templating works in other parts of Vault, for example paths in policies where the templating can be anywhere https://www.vaultproject.io/docs/concepts/policies#templated-policies

Describe alternatives you've considered

Documentation on the values where the templating actually happens could be a compromise if we won't relax the regexp.

Explain any additional use-cases

My current system uses more information than the username as a principal to identify connecting users (for example, you could differentiate users from service accounts). In this case, having surrounding info on the principal can be useful.

Additional context

Original PR #7548

Thanks,

@phihos
Copy link
Contributor

phihos commented Feb 10, 2021

A (rather stupid) workaround if you can choose the username freely:

{{ identity.entity.name }}-username-{{ identity.entity.name }}

It works because the regex checks for {{ at the front and }} at the back. Having multiple template sections works just fine.
So this is an indicator, that just removing ^ and $ should fix this.

@pmmukh
Copy link
Contributor

pmmukh commented Oct 19, 2021

Fixed by #10886

@pmmukh pmmukh closed this as completed Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants