You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 11, 2023. It is now read-only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In preparation for custom trust domains, I am beginning the process of decoupling the equality between certificate.CommonName, and identity.ServiceIdentity (they will remain tightly coupled, but not strictly equal)
There's a bunch of places in the code that currently relies on CertificateCommonName, particularly with respect to proxies, proxy maps (registries), and xdsLog.
In these cases I prefer using either the UUID, when mapping directly to the proxy OR a new "proxy name" comprised of the uuid and service identity for the xdsLog to maintain the usefulness of having both the identity and uuid.
This PR also removes some dead code as a result of the above changes.
I understand what this PR is doing, but couldn't understand how this change helps #4754. Could you describe in the commit message why this decoupling is necessary?
Thanks
I understand what this PR is doing, but couldn't understand how this change helps #4754. Could you describe in the commit message why this decoupling is necessary?
Thanks
Good question! That’s definitely not obvious on first pass
A proxy’s CN can change with rotated trust domains, so we want to keep these mappings stable
After we decouple service identity and from common name, we can no longer derive the CN without access to the cert manager instance, and knowing which trust domain to use
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
None yet
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In preparation for custom trust domains, I am beginning the process of decoupling the equality between certificate.CommonName, and identity.ServiceIdentity (they will remain tightly coupled, but not strictly equal)
There's a bunch of places in the code that currently relies on CertificateCommonName, particularly with respect to proxies, proxy maps (registries), and xdsLog.
In these cases I prefer using either the UUID, when mapping directly to the proxy OR a new "proxy name" comprised of the uuid and service identity for the xdsLog to maintain the usefulness of having both the identity and uuid.
This PR also removes some dead code as a result of the above changes.