feat(router/atc): extend route.snis to support wildcard for the leftmost or rightmost character with traditional-compatible flavor

[catbro666]

Summary

• Change the element type of route.snis from sni to wildcard_host.
• Change the router accordingly to support wildcard snis because the sni is involved in route matching.

Note this is to be a hidden feature intentionally so we don't document it.

Additional Notes:

• The expressions flavor doesn't support mTLS (mtls-auth plugin and tls-handshake-modifier plugin) theoretically. The reason is the current mTLS implementation is based on the route.snis, but at the ssl phase it is not yet known which route will match. As a workaround, it collects the sni set on routes that are associated with mtls plugins in advance. But for the expressions flavor, things are different. All the fields that were involved in route matching have been merged into the field expression. Without actually evaluating, we can't know in general if a sni will match a certain route. But again, you can't get all the parameters required for evaluation at the ssl phase. The correct solution is decoupling the mTLS logic from the routes entity by binding it to the snis entity, as we’ve discussed in https://konghq.atlassian.net/browse/KAG-3757
• We don't distinguish the priority of plain-only-snis and contain-wildcard-snis for the traditional-compatible flavor because there are no reserved bits available. See https://github.com/Kong/kong/blob/master/kong/router/transform.lua#L515-L528

Checklist

• The Pull Request has tests
• A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

https://konghq.atlassian.net/browse/KAG-3832

[chronolaw]

Should we schedule a short offline meeting to discuss this PR? I am not very clear about the requirement.

Another thing, we are planing a big refactoring of router (#12667), perhaps you should take a look at it.

[chronolaw]

Convert to draft because we still have some discussions.

[chronolaw]

We should also add compatible check code for hybrid mode, See #12814

[catbro666]

We should also add compatible check code for hybrid mode, See #12814

typedefs.sni and typedefs.wildcard_host are both of type string, just the validation functions are different. And validate_wildcard_host is stricter than validate_sni (which means those strings can pass validate_wildcard_host will certainly pass validate_sni), so I think there is no need to add the compatible check code.

[chronolaw]

We should also add compatible check code for hybrid mode, See #12814

typedefs.sni and typedefs.wildcard_host are both of type string, just the validation functions are different. And validate_wildcard_host is stricter than validate_sni (which means those strings can pass validate_wildcard_host will certainly pass validate_sni), so I think there is no need to add the compatible check code.

No, atc-router in kong gateway lower than 3.7 does not understand wildcard sni, it only support sni == a.com.
If atc-router with flavor traditional_compatible get a expression sni == *.com it can not work as we wish.

[catbro666]

We should also add compatible check code for hybrid mode, See #12814

typedefs.sni and typedefs.wildcard_host are both of type string, just the validation functions are different. And validate_wildcard_host is stricter than validate_sni (which means those strings can pass validate_wildcard_host will certainly pass validate_sni), so I think there is no need to add the compatible check code.

No, atc-router in kong gateway lower than 3.7 does not understand wildcard sni, it only support sni == a.com. If atc-router with flavor traditional_compatible get a expression sni == *.com it can not work as we wish.

Ah right. utils.normalize_ip does this limitation. Will add the compatible check code, Thanks!

[chronolaw]

Should we add back the change log file to tell the user that we have this new feature?

[catbro666]

Should we add back the change log file to tell the user that we have this new feature?

Confirmed with @dndx that this would be a hidden feature so we don't document it.

[chronolaw]

Great job!

[catbro666]

@chronolaw Thanks for the efforts in the review!

[jschmid1]

I have nothing further to add, thanks to the thorough reviews by my peers before me.

Changes have been made.

[ms2008]

@dndx Can you please review this again?

[team-gateway-bot]

Cherry-pick failed for master, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally.

git remote add upstream https://github.com/kong/kong-ee
git fetch upstream master
git worktree add -d .worktree/cherry-pick-12809-to-master-to-upstream upstream/master
cd .worktree/cherry-pick-12809-to-master-to-upstream
git checkout -b cherry-pick-12809-to-master-to-upstream
ancref=$(git merge-base 00d1c3ff8afddb1b9c2600701d00c7655ef9f828 96e5d056cfe371b927473fff73308407e61bdc01)
git cherry-pick -x $ancref..96e5d056cfe371b927473fff73308407e61bdc01

[bungle]

@dndx damn it, I pushed rebase and merge instead of squash and merge. @catbro666 let's stop having PRs on review stage with unclean commits. See: https://github.com/Kong/kong/commits/master/