-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Add globbing support to the PKI backend's allowed_domains list #2517
Conversation
@justintime32 I think for now I'd prefer not to make these changes to email addresses, unless you have a particular use-case in mind. Both the operational and threat model are different for email vs. DNS and I don't see a need for it so would prefer to avoid expanding its scope. |
Hey @jefferai - I don't have a use case for email domain globbing. I'll go ahead and revert that part of the change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good to go after that change.
builtin/logical/pki/cert_util.go
Outdated
@@ -330,8 +331,8 @@ func validateNames(req *logical.Request, names []string, role *roleEntry) string | |||
} | |||
} | |||
|
|||
if strings.HasSuffix(sanitizedName, "."+req.DisplayName) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this use case is also not needed. It's difficult to reason about a use-case where you would want to make a token display name a globbing CN.
Done! |
@jefferai any other thoughts? |
No, just haven't gotten back to this yet. |
Hi @spectrumjade , I've taken a while to get back to this because every time I look at it something about it eats away at me and makes me really uncomfortable, mostly for two reasons:
I want to go a slightly different direction instead: adding an explicit role parameter This is much less magic, is explicit to the user, and makes it easier to reason about the right thing to do in the BareDomain/Subdomain checking code. It's a little extra work but not much. Hopefully it's understandable why I want to go this way. |
@jefferai What do you think about instead adding an |
I think that will be very confusing, honestly. If we're going to add a parameter in either case, what does it buy you over simply explicitly enabling globbing of the existing fields with a bool? |
Reading through the code closer, I think I was misunderstanding the scope of |
@michaelansel what it matches basically depends on what flags you have toggled as acceptable things to match (bare domain, subdomains, etc.). But yeah, it doesn't remove hostnames or anything. |
Hey @jefferai I think that's a fine approach. I'm preparing the change now. One thought I have, I think we should require that |
@spectrumjade That can be worked around by using |
@jefferai Oops, I missed your comment before adding the new commit. Do you think one of those options would be better than the current approach (requiring Could you elaborate on the |
I don't like the idea of requiring bare domains to be allowed just to enable globbing, because then you are...allowing bare domains, which you may not want to do. Why not just require any glob check to have an asterisk in it? Then if there isn't an asterisk, you treat it like a non-globbed domain (must match the allowed subdomains/bare domains settings). That way you can easily mix and match bare domains and allowed globs but control their acceptability separately. |
in the allowed_name.
@jefferai I've implemented the wildcard check and removed the |
I like it. Super simple, super understandable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks good to me. The only think I would like to see is a few unit tests to cover the new globbing use case.
@spectrumjade Can you add some unit tests? |
@spectrumjade we're looking to release 0.7.1 next week, so please keep that in mind if you want to see this in that release! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good to me, as soon as there is a unit test I'd say this is ready to go!
@@ -361,6 +362,13 @@ func validateNames(req *logical.Request, names []string, role *roleEntry) string | |||
break | |||
} | |||
} | |||
|
|||
if role.AllowGlobDomains && | |||
strings.Contains(currDomain, "*") && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need the strings.Contains(currDomain, "*")
check here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Read back on the conversation on the PR and understood how not having this check would implicitly allow bare domain. Ignore my previous comment.
Thanks for all of your work on this! |
This change adds simple glob support to the "allowed_domains" list in the PKI backend. This is useful if you would like role policies to allow more flexible name patterns without allowing any name or any subdomain.
It uses an asterisk as the glob character, which I think works for this use case because an asterisk cannot be used in a DNS domain name and in a certificate the wildcard can only be in one specific place (a single wildcard can be present in the left-most name position, and it must be the only component of the dot boundary). A PKI policy of "*.domain.com" will still allow the explicit name "*.domain.com". It will also allow anything ending in ".domain.com", however this is consistent with threat modeling around the DNS hierarchy.