Feature: Custom Trust Domains

[steeling]

We have received feature requests from customers that require custom trust domains for their services. This means that certificates issued should have a common name of the format:

<identity-name>.<namespace>.<custom-trust-domain>

Additionally, we should add the DNS entry with the custom trust domain in k8s.GetHostnamesForService.

With the new MRC, we can build this in such a way that we can migrate from one trust domain to another with 0 downtime. To do so, we will add a new immutable field to the MRC, "trustDomain".

This issue will track the sub-issues for implementation:

• [ ] Decouple service identity from common name, by stripping the trust domain from service identity
• [ ] Add the trust domain field to the MRC, and plumb through to the Getter described in the step above.
• [ ] Add a validation that the trust domain field cannot change to the validating webhook
• [ ] Add the required business logic to actually use the new trust domain

[steeling]

Brief proposal https://docs.google.com/document/d/1nLI4PcfB7-hdPvJipQwQ9dw28f8G7p77iqv3VzsCRFI/edit#

[phillipgibson]

@steeling is this work related to integration with customer's existing PKI infrastructure to have OSM, or cert-manager, issue and sign certs from the same chain?

[steeling]

Kind of. That is actually already possible although the service certs won’t have the custom trust domain.

This is for users that use a PKI with a requirement that all certs have a specific trust domain

[github-actions[bot]]

Added default label size/needed. Please consider re-labeling this issue appropriately.

[jsturtevant]

Synced with @steeling, this work is complete but dependent on cert-rotation work to be released

[keithmattix]

@steeling If the work for this is complete, can we close this? I think we've captured cert-rotation work elsewhere