Controlling unexpected egress
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
- Ensure you are in the Home view.
- Look at the service map. Within a few seconds, you should see a line running from
247-173-190-239 1. This looks wrong on many levels, but we want to examine it before we shut it down.
- Click the unknown endpoint, then click the Metrics tab to inspect what is going on.
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.
To stop this behavior, we’ll simply apply a zero-request policy to deny the interaction.
- Name the view "Unexpected shipping service egress".
- Click Set Policy for requests (R), enter "0" and click Set or hit Return.
- Activate the new policy by clicking Commit and then Push on the next page.
- After a few seconds you can confirm that interactions along this particular route are now denied.
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?