Edge router policies are entities within the Ziti Controller which provide identities access to edge routers
And a service identity can be created via the command:
ziti edge create identity service <name> [flags]
It seems to me that I can grant a service access to an edge router once the above are done.
So I’m a little confused why we would need a edge service policy. Since according to the description, it is accomplishing the exact same thing as an edge router policy applying to a service identity.
Service edge router policies are entities within the Ziti Controller which provide services access to edge routers. They are similar to edge router policies except they determine via which edge routers a service can be used or provided
Edge Router Polices (ERPs) grant identities access to edge routers.
Service Edge Router Policies (SERPs) grant services access to edge routers.
In practice what that means is when an identity Foo is accessing service Bar, the edge routers Foo can use is the intersection of the edge routers that Foo has access to via ERPs and that Bar has access to via SERPs.
In general, most people don’t use SERPs. They’re mostly useful if you want to allocate a set of edge routers for service or set of services, maybe to help guarantee SLAs for that service.
Longer term we’d like to evolve SERPs so they affect the entire path and not just the entry points into the mesh. At that point, I suspect they’ll see more use.
Thank you for the reply. I still think you need clarification regarding the document. From the link talking about the types of identities , there are
User
Device
Service
In that sense a service is simply an identity. And an ERP, according to your reply, grants access to an identity. Therefore I can tie the service Bar to an edge router via ERP. There’s no need for me to use SERP.