Support traffic access control
localvar opened this issue · 1 comments
localvar commented
In #58 , we wish to support service mesh interface. However, there are gaps between the concepts used by Easemesh and the concepts in SMI which are difficult to span.
But, it is possible to implement some SMI features in Easemesh by an alternative solution, and this issue is created to track the design and implementation of a feature to Traffic Access Control.
Differences between SMI Traffic Access Control
and Easemesh Traffic Access Control
are:
- For SMI Traffic Specs, Easemesh only support
HTTPRouteGroup
. - In SMI, traffic access control is enforced on the server-side (traffic target), Easemesh will enforce it on the client-side (traffic source).
- In SMI, access is controlled based on K8s service accounts; in Easemesh, access is controlled based on Easemesh services.
- Easemesh will not support the
namespace
of a traffic source or target in SMI
Below is an example spec of TrafficTarget
in Easemesh:
---
kind: HTTPRouteGroup
metadata:
name: the-routes
spec:
matches:
- name: metrics
pathRegex: "/metrics"
methods:
- GET
- name: everything
pathRegex: ".*"
methods: ["*"]
---
kind: TrafficTarget
metadata:
name: path-specific
spec:
destination:
kind: Service
name: order
rules:
- kind: HTTPRouteGroup
name: the-routes
matches:
- metrics
sources:
- kind: Service
name: monitor
zhao-kun commented
Closed due to easegress-io/easegress#308