Allow users to provide a CA bundle for configuring the mutatingWebhookConfiguration in OSM

[snehachhabria]

Please describe the Improvement and/or Feature Request Extend OSM, whereby a user is allowed to provide or bring their own CA bundle for the mwhc in OSM. This can be enabled/disabled using a feature flag.

In the scenario when a user brings their own CA bundle the lifecycle and management of the mwhc is the responsibility of the mesh owner.

Scope (please mark with X where applicable)

• New Functionality [X]
• Install [X]
• SMI Traffic Access Policy [ ]
• SMI Traffic Specs Policy [ ]
• SMI Traffic Split Policy [ ]
• Permissive Traffic Policy [ ]
• Ingress [ ]
• Egress [ ]
• Envoy Control Plane [ ]
• CLI Tool [ ]
• Metrics [ ]
• Certificate Management [ ]
• Sidecar Injection [ ]
• Logging [ ]
• Debugging [ ]
• Tests [ ]
• CI System [ ]
• Project Release [ ]

Possible use cases Provides ore flexibility for the creation and management of the mwhc

[draychev]

This is a prerequisite for #507

[phillipgibson]

I have some more information from customers I believe is related to this issue. We're seeing a growing need for customers to have a need for certificates issued in the mesh to have the common name and SAN share the same domain as their current PKI infrastructure Eg .com. Is this issue targeting the same use case?

[steeling]

No this would be separate. We can create a new issue for custom trust domains, I don't believe that's currently captured

[phillipgibson]

Ok I'll create an issue outlining the use case.

[github-actions[bot]]

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

[steeling]

So right now custom trust domains leave an awkward story with respect to the webhooks, which require a certificate SAN of <service>.<namespace>.svc

So this would alleviate that issue for customers that may need to integrate with their own PKI.

[jaellio]

So right now custom trust domains leave an awkward story with respect to the webhooks, which require a certificate SAN of <service>.<namespace>.svc

So this would alleviate that issue for customers that may need to integrate with their own PKI.

Hey @steeling! I'm trying to get a better understanding of this issue. Could you share some documentation about Kubernetes webhooks requirements for certificate SANs? Should custom certs be allowed for all webhooks? Could you elaborate on the awkward story here with respect to custom trust domains?

[steeling]

K8s requires that the SAN is of the form <service>.<namespace>.<svc>

This is a problem for users who are integrated with a PKI setup where they are required to leverage a custom trust domain. Enabling a "Bring your own Control plane certs", would allow these certs to not go through their custom PKI setup.

Alternatively we could have some flags or something that allows 2 cert managers, 1 for a PKI, and maybe one that leverages tresor, although I'm not sure which customers would prefer. The former would allow users to leverage whatever cert requirements they may have, but brings the overhead of managing the lifespan of the cert, while tresor could leverage auto rotation.

[steeling]

https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#configure-admission-webhooks-on-the-fly

[keithmattix]

@jaellio Does the current cert-rotation work enable this? My guess is no

[github-actions[bot]]

This issue will be closed due to a long period of inactivity. If you would like this issue to remain open then please comment or update.

[github-actions[bot]]

Issue closed due to inactivity.