osm
osm copied to clipboard
openservicemesh
Allow mTLS at egress
Phase 1 could simply be a boolean on egress that applies mTLS with the existing mesh certificate. The onus would be on users to distribute the root certs appropriately.
Phase 2 could be providing another public key for validation.
@steeling could you please describe in detail the motivation for this issue and what is being requested here. Does this pertain to egress (pod to external) traffic or something else?
Yes this is for pod to external traffic, to meet security requirements around mTLS
Yes this is for pod to external traffic, to meet security requirements around mTLS
mTLS is supported with Egress, though the TLS origination for external traffic must happen within the application code.
(emphasis mine)
mTLS is supported with Egress, though the TLS origination for external traffic must happen within the application code.
I think we can do better than this. Automatic mTLS on egress is a much better user-experience IMO.
(emphasis mine)
mTLS is supported with Egress, though the TLS origination for external traffic must happen within the application code.
I think we can do better than this. Automatic mTLS on egress is a much better user-experience IMO.
Enabling provisioning user TLS certificates is an option that can enable this. However, note that this mechanism was intentionally not supported as a design choice in an effort to keep the behavior simple without the added complexity of needing to deal with custom certificates. If users are requesting for this feature, we can consider extending the current capability.
Why do we need to provision user certificates? If the user provisions OSM with an intermediate CA, wouldn't sibling CAs (i.e. certs derived from the same root as the intermediate) automatically be trusted?
Why do we need to provision user certificates? If the user provisions OSM with an intermediate CA, wouldn't sibling CAs (i.e. certs derived from the same root as the intermediate) automatically be trusted?
That would work. What I meant is that for mTLS to an external destination not managed by OSM, customers will likely want to bring their own cert or not use self-signed certs, as the intermediary/root cert for the external destination is not derived from a cert issued by OSM. If we are talking about one-way TLS (not mTLS), it's simpler in terms of configuration.
@steeling could you kindly add more details describing the scenario you are requesting support for. A few additional lines describing the scenario and existing limitations will help add clarity.
Yes this is for pod to external traffic, to meet security requirements around mTLS
mTLS is supported with Egress, though the TLS origination for external traffic must happen within the application code.
correction: s/mTLS/TLS
@shashankram I see what you're saying; self-signed Tresor certificates wouldn't work, but the cert-manager or Vault provider pointing to an intermediate CA should. That way, all the service certs would be derived from that intermediate and be able to talk to the external destinations
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] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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.