Accessing external services with Istio

Almost every blog post or lecture explaining how Istio service meshes route traffic takes the time to go over how sidecar containers capture outgoing traffic - how that traffic is routed to another service with another sidecar. However, in the real world, a large amount of network traffic passes through the boundaries of the service mesh itself. That traffic might be from a public facing app that receives traffic from the internet, an internal service that needs to connect to a legacy application running outside the mesh, or a workload that consumes an external, third party API.

In this post, we’ll take a look at the different methods by which a workload inside an Istio mesh can access external services. We’ll be following the structure of our earlier posts about Istio and Backyards (now Cisco Service Mesh Manager). These cover Istio’s basics first, then go into detail about how Backyards (now Cisco Service Mesh Manager) can help configure and visualize the features we discuss.

Check out Backyards in action on your own clusters!

Register for a free version

Want to know more? Get in touch with us, or delve into the details of the latest release.

Or just take a look at some of the Istio features that Backyards automates and simplifies for you, and which we’ve already blogged about.

External Services 🔗︎

Istio uses sidecars to manage outbound traffic origination from an Istio-enabled pod. Previously, we wrote an in-depth post about reducing sidecar resource consumption. This time we are going to explore something a little different, accessing external services from the mesh. If you’re a regular reader of this blog, you might have already guessed that we’ll be talking about another Istio custom resource: ServiceEntry. But let’s not get ahead of ourselves. A workload on an Istio mesh can access external services in three different ways:

1. Allow sidecar to passthrough traffic for undiscovered services.
2. Restrict access to services that are configured in Istio’s registry; an external service can be added to this registry through ServiceEntries.
3. Completely bypass the sidecar (can only be configured for a specific IP address range).

While the third option might seem tempting and it may be a viable option for a high performance application, we discourage it for use with regular workloads. According, we’re not going to discuss that option in this blog post, only the first two.

Passthrough cluster 🔗︎

A default Istio installation usually comes with this set up. Istio’s outbound traffic policy mode is set to ALLOW_ANY. In this mode, all trafic originating from the cluster to any external service is permitted. This eases application development as well as the migration of existing applications to the mesh.

BlackHole cluster 🔗︎

REGISTRY_ONLY outbound traffic policy mode is the complete opposite of Passthrough. All unknown traffic to external services that originates from inside the cluster is blocked. From a security and operations point of view, it is critical to restrict external traffic to known services only. This mitigates a significant security vulnerability, preventing applications from attempting to communicate with services they should not be allowed to. Since all external traffic is blocked in this mode, known external services need to be defined and monitored. In the next section, we’ll talk about how Istio accomplishes this.

Backyards is able to display traffic to external services from BlackHole and Passthrough clusters – which are not part of your platform – by capturing augmented metrics.

The ServiceEntry custom resource 🔗︎

ServiceEntry is a way of extending Istio’s service registry, so that existing auto-discovered services can access other services whether they are undiscovered internal services or services completely external to the mesh (e.g., web APIs).

The following example describes an external API accessed by internal applications over HTTP using DNS for hostname resolution.

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin.org
  namespace: backyards-demo
spec:
  hosts:
  - httpbin.org
  - www.httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  exportTo:
  - "."
  resolution: DNS
  location: MESH_EXTERNAL

Let’s break this down a little.

Note, not all fields are shown here. You can find the full specifications here.

While we’re going to stick to this simple example, you should bear in mind that a ServiceEntry can be used in a variety of more advantageous ways. You can use ServiceEntry to span an Istio mesh over multiple clusters or use it for locality aware failure domain-based routing.

Note. If you are interested in multi-cluster Istio service meshes we’ve already written a post on how to do it the easy way. Check out also locality load balancing with Istio.

Try it out! 🔗︎

Create a cluster 🔗︎

For this demo we’ll need a Kubernetes cluster.

For this example, I created a Kubernetes cluster on AWS, using Banzai Cloud’s lightweight, CNCF-certified Kubernetes distribution, PKE, via the Pipeline platform. If you’d like to do likewise, go ahead and create your cluster on any of the several cloud providers we support or on-premise, using Pipeline (for free).

Install Backyards 🔗︎

The easiest way of installing Backyards (now Cisco Service Mesh Manager), and a demo application on a brand new cluster, is to use the Backyards CLI.

Register for the free version and install the CLI.

Allow sidecar to passthrough traffic for undiscovered services 🔗︎

This method is much easier. All it requires is that you change the default policy for outbound traffic to passthrough.

$ backyards istio outbound-traffic-policy allowed

Calling external service from a notification’s deployment 🔗︎

First, we modify the deployed demo application.

$ kubectl -n backyards-demo set env deployment/notifications-v1 'REQUESTS=http://httpbin.org/get#1'
deployment.extensions/notifications-v1 env updated

The Backyards UI will show passthrough traffic to httpbin.org.

The Backyards UI should open automatically if you execute backyards install -a --run-demo, but, as an alternative, you can always open it with backyards dashboard.

Restrict outbound traffic explicitly to the known endpoints 🔗︎

$ backyards istio outbound-traffic-policy restricted

If this policy succeeds, it will prevent calls to httpbin.org.

Create a service entry for an external service 🔗︎

The following command creates an external service endpoint for httpbin.org, a simple HTTP Request & Response Service.

$ kubectl apply -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin.org
  namespace: backyards-demo
spec:
  hosts:
  - httpbin.org
  - www.httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL
EOF

So far, we’ve restricted external traffic only to a known service. Hostname based matching for the new entry will allow traffic to flow to the external service. This can be observed taking place on the Backyards UI.

Since the httpbin.org service is now known to Istio, we can do the all of our usual nifty things with it.

• Apply timeout
• Circuit breaking
• Traffic Routing
• Fault injection
• etc.

Cleanup 🔗︎

To remove the demo application, Backyards, and Istio from your cluster, you only need to apply one command, which takes care of removing these components in the correct order:

$ backyards uninstall -a

Takeaway 🔗︎

It is recommended that you make a ServiceEntry for services external to the mesh. This way you can improve the security of your mesh by only allowing calls to external services, essentially a whitelist. The Backyards (now Cisco Service Mesh Manager) UI visualizes traffic to external services and therefore helps you easily track external connections, allowing you to determine if they are working properly. In an upcoming release we’ll make it even easier to manage external services, just like we already do for our other supported features.

Contact us if you’d like to use Backyards in production.

About Backyards 🔗︎

Banzai Cloud’s Backyards (now Cisco Service Mesh Manager) is a multi and hybrid-cloud enabled service mesh platform for constructing modern applications. Built on Kubernetes, our Istio operator and the Banzai Cloud Pipeline platform gives you flexibility, portability, and consistency across on-premise datacenters and on five cloud environments. Use our simple, yet extremely powerful UI and CLI, and experience automated canary releases, traffic shifting, routing, secure service communication, in-depth observability and more, for yourself.