Skip to main content

Controlling unexpected egress

Scenario​

While exploring the service map, you notice that shippingservice is talking to an unknown service 247.173.190.239. This is unexpected, to say the least, and almost certainly undesired, so you decide to investigate the behavior a bit before putting a stop to it.

Run this command to kick this incident off:

kubectl label -n glasnostic-online-boutique pod -l app=shippingservice ENABLE_CACHE_SHIPPING=true

Examining the situation​

  1. Ensure you are in the Home view.
  2. Look at the service map. Within a few seconds, you should see a line running from shippingservice to 247-173-190-239 1. This looks wrong on many levels, but we want to examine it before we shut it down.
  3. Click the unknown endpoint, then click the Metrics tab to inspect what is going on.

Unknown endpoint selected

You see that this behavior started just a few minutes ago and doesn’t amount to more than a trickle. Nevertheless, this is definitely not anything the application is supposed to do.

Take control​

To stop this behavior, we’ll simply apply a zero-request policy to deny the interaction.

  1. Name the view "Unexpected shipping service egress".
  2. Click Set Policy for requests (R), enter "0" and click Set or hit Return.
  3. Activate the new policy by clicking Commit and then Push on the next page.

Denied requests

  1. After a few seconds you can confirm that interactions along this particular route are now denied.

Image

Summary​

We discovered an unexpected interaction from shippingservice to an unknown endpoint and examined a bit of its history and characteristics before putting an end to it, then confirmed the interaction was in fact denied.

By doing so we have prevented a suspicious egress from a specific source to a specific destination. But what if we wanted to ensure that all unexpected interactions are denied automatically?