gradual mTLS rollout

[michelleN]

When service mesh is rolled out to a brownfield a service may need to be mTLS-optional.
If two existing services A-B are enabled for mTLS, there will be before and after mTLS is enabled. Not all pods will be mTLS ready at the same time. This will result in some old pods connecting to new mTLS pods and most likely 503 errors.
To prevent that we need mTLS-optional for a period of time, where if mTLS does not work we switch to non-mTLS.

What about traffic split, where one group is mTLS the other is not?

[asridharan]

@michelleN could you add some description to this issue. Want to understand the feature we want to implement.

[draychev]

Given the non-triviality of this task, I propose we postpone implementation until after we release v1 of OSM. This would mean that v1 of OSM would cause downtime when deployed to a brownfield setup.

[steeling]

Related issues

• Allow a way to not enforce client side routes to simplify gradual migration of applications into the mesh #2012
• disable mTLS using a flag #1001
• Support capability to incrementally migrate legacy services to a service mesh #2172

[github-actions]

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

[keithmattix]

I think this is definitely a feature we should implement in the next couple of releases

[github-actions]

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]

Issue closed due to inactivity.