In permissive traffic mode (allow-all) only pods with services can communicate; not individual pods w/ service #2064
Comments
|
This may get resolved with #2035 |
This isn't related to the routes refactor as much as more having to do with how certificates are issued to proxies. I discussed with @michelleN a proposed solution for this without needing to hack with synthetic services. I'll try to prototype a solution for this. |
|
I did a POC where client proxies can connect to services without needing the client to be a service. The idea is to refactor how certificates are provisioned via SDS such that clients certificates are not based on a service reference. This will obviate the need to create a synthetic service for the client inside the controller. The ability to not rely on synthetic service depends on #2034, which removes the need to lookup routes/traffic policies based on a service. |
|
Moving this to v0.8 since this depends on routesV2 (https://github.com/openservicemesh/osm/issues?q=is%3Aissue+is%3Aopen+label%3A%22routes+v2%22) to work end-to-end. |
This change adds support to allow downstream clients without services to connect to upstream services while removing the need for synethetic services completely. At a high level, this is accomplished by assigning client proxies certificates based on their identities (service account) instead of services associated with the proxies. This is possible because the certificates for a proxy does not have any service metadata in them. Some XDS tls_context related utility structs and helpers have been made generic enough to not depend on the SDS secret being associated with a service. Resolves openservicemesh#2064 Signed-off-by: Shashank Ram <shashr2204@gmail.com>
This change adds support to allow downstream clients without services to connect to upstream services while removing the need for synthetic services completely. At a high level, this is accomplished by assigning client proxies certificates based on their identities (service account) instead of services associated with the proxies. This is possible because the certificates for a proxy does not have any service metadata in them. Some XDS tls_context related utility structs and helpers have been made generic enough to not depend on the SDS secret being associated with a service. Resolves openservicemesh#2064 Signed-off-by: Shashank Ram <shashr2204@gmail.com>
While in SMI-mode (not permissive traffic mode) with #1932 we added the ability for have a pod, not backed by a service to make calls to other pods -- as long as there are TrafficTarget policies permitting the 2 service accounts to communicate.
On the other hand, in permissive traffic mode, a pod without a backing service is not able to communicate w/ other pods.
This is well illustrate by this PR #1570, which fails in CI for permissive traffic mode.
Bug description:
Affected area (please mark with X where applicable):
Expected behavior:
-- Pods without a backing service, in permissive traffic policy mode, should be able to cURL bookstore -- this PR should pass CI: #1570
Steps to reproduce the bug (as precisely as possible):
-- See #1570
How was OSM installed?:
Anything else we need to know?:
Environment:
osm version): v0.5 and earlierkubectl version): n/aThe text was updated successfully, but these errors were encountered: