ServiceEntry Best Practices?

If we wish to use the block-by-default config for egress traffic, are there any best practices for how to use ServiceEntries?

In particular, we have multiple different teams making multiple different apps, each with their own set of external services that they need to access.

Where do you typically place ServiceEntry manifest files? In some global list of ServiceEntries shared by all apps across all teams?

I see a few possible issues

  1. Two different apps from two different teams might reference the same external service, so if both teams need the same ServiceEntry, they need to add just one instance of it to a global list of ServiceEntries, since there can’t be duplicate ServiceEntries to the same host
  2. The two apps might need different configurations of the ServiceEntry, in which case they would need to have the “global” one support both use cases (e.g. accessing it on different ports, or maybe one only needs access to a specific subdomain of the host)
  3. If one app no longer needs to access the external service, it can’t remove it from the “global” list because there might be other apps that are now using it.

Any helpful tips or best practices are highly appreciated!


@adinunzio84 Did you ever get anywhere with this? I think these questions are important concepts to be answered by the community.

@blaketastic2 haven’t seen anything that could help with this yet, and since we aren’t blocking egress traffic by default anymore, we haven’t really put any extra effort into figuring this stuff out.

Hoping that there are some good answers to these eventually though, since I imagine we will ultimately end up with block-by-default egress traffic with ServiceEntries.

Hi @adinunzio84,
We recently published an open source solution to automate the configuration of service entries in a cluster:

You can also see the blog about this here:

Hope this helps,
Reuven (CTO and Co-Founder @ Tufin)

edit: updated github repo to its new home on istio-ecosystem


Thanks @Reuven_Harrison!