Egress blog part 2

.spelling

@@ -254,6 +254,7 @@ istio.io
 istio.io.
 Istiofied
 IstioMesh
+istio-identity
 istio-mixer
 istio-system
 jason

content/blog/2019/egress-traffic-control-in-istio-part-1/index.md

@@ -9,12 +9,14 @@ keywords: [traffic-management,egress,security]
 
 This is part 1 in a new series about secure control of egress traffic in Istio that I am going to publish.
 In this installment, I explain why you should apply egress traffic control to your cluster, the attacks
-involving egress traffic you want to prevent, and the requirements for your system to do so.
+involving egress traffic you want to prevent, and the requirements for a system for egress traffic control
+to do so.
 Once you agree that you should control the egress traffic coming from your cluster, the following questions arise:
-What requirements does a system have for secure control of egress traffic? Which is the best solution to fulfill
+What is required from a system for secure control of egress traffic? Which is the best solution to fulfill
 these requirements? (spoiler: Istio in my opinion)
-Future installments will describe the implementation of the secure control of egress traffic in Istio and
-compare it with other solutions.
+Future installments will describe
+[the implementation of the secure control of egress traffic in Istio](/blog/2019/egress-traffic-control-in-istio-part-2/)
+and compare it with other solutions.
 
 The most important security aspect for a service mesh is probably ingress traffic. You definitely must prevent attackers
 from penetrating the cluster though ingress APIs. Having said that, securing
@@ -161,8 +163,9 @@ all of these requirements, in particular it is transparent, DNS-aware, and Kuber
 
 ## Summary
 
-I hope that you are convinced that controlling egress traffic is important for the security of your cluster. In the
-next blogs in this series I will describe the Istio way to perform secure control of egress traffic and compare it with
-alternative solutions such as
+I hope that you are convinced that controlling egress traffic is important for the security of your cluster. In [the
+part 2 of this series](/blog/2019/egress-traffic-control-in-istio-part-2/) I describe the Istio way to perform secure
+control of egress traffic.
+Next, I will compare it with alternative solutions such as
 [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) and legacy
 egress proxies/firewalls.

content/blog/2019/egress-traffic-control-in-istio-part-2/index.md

@@ -0,0 +1,101 @@
+---
+title: Secure Control of Egress Traffic in Istio, part 2
+subtitle: Use Istio Egress Traffic Control to prevent attacks involving egress traffic
+description: Use Istio Egress Traffic Control to prevent attacks involving egress traffic.
+publishdate: 2019-05-29
+attribution: Vadim Eisenberg (IBM)
+keywords: [traffic-management,egress,security]
+---
+
+This is part 2 in a new series about secure control of egress traffic in Istio.
+In [the first part in the series](/blog/2019/egress-traffic-control-in-istio-part-1/), I presented the attacks involving
+egress traffic and the requirements we collected for an egress traffic control system.
+In this installment, I describe the Istio way for controlling egress traffic securely and show how Istio prevents the
+attacks.
+
+## Egress traffic control by Istio
+
+To implement secure egress traffic control in Istio, you must
+[direct TLS traffic to external services through an egress gateway](/docs/tasks/traffic-management/egress/egress-gateway/#egress-gateway-for-https-traffic).
+(To support wildcard domains, you must create
+[a custom version of an egress gateway](/docs/tasks/traffic-management/egress/wildcard-egress-hosts/)). Alternatively, you
+can [direct HTTP traffic through an egress gateway](/docs/tasks/traffic-management/egress/egress-gateway/#egress-gateway-for-http-traffic)
+and [let the egress gateway perform TLS origination](/docs/tasks/traffic-management/egress/egress-gateway-tls-origination/#perform-tls-origination-with-an-egress-gateway).
+
+In all cases you have to apply some
+[additional security mechanisms](/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations),
+like [Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) or an L3
+firewall that will enforce that traffic from the cluster to the outside is allowed for the egress gateway only. See
+[an example for Kubernetes Network Policies configuration](/docs/tasks/traffic-management/egress/egress-gateway/#apply-kubernetes-network-policies).
+
+You must also increase the security measures applied to the Istio control plane and the
+egress gateway by running them on nodes separate from the application nodes, in a separate namespace, monitoring them
+more thoroughly, etc. After all, if the attackers are able to attack Istio Mixer or the egress gateway, they could
+violate any policy.
+
+Once you direct egress traffic through an egress gateway and apply the additional security mechanisms,
+you can securely monitor the traffic and define security policies on it.
+If the application sends HTTP requests and the egress gateway performs TLS origination, you can monitor HTTP
+information, e.g. HTTP methods, headers and URL paths, and you can
+[define policies](/blog/2018/egress-monitoring-access-control) based on the HTTP information. If the application
+performs TLS origination, for TLS traffic you can
+[monitor SNI and the service account](/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/) of the
+source pod, and define policies based on them.
+
+The following diagram shows Istio's security architecture, augmented with L3 firewall (part of the
+[additional security mechanisms](/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)
+provided outside of Istio by the cluster/cloud provider).
+The L3 firewall can have a trivial configuration that would allow incoming traffic into Istio ingress gateway pods only and
+outgoing traffic from Istio egress gateway pods only. Note that the Istio proxy of the egress gateway performs
+policy enforcement and reporting in the same way as the sidecar proxies in the application pods.
+
+{{< image width="80%" link="./SecurityArchitectureWithL3Firewalls.svg" caption="Istio Security Architecture with Egress Gateway and L3 Firewall" >}}
+
+Now let's examine possible attacks and let me show you how the secure control of egress traffic in Istio prevents them.
+
+## Possible attacks and their prevention
+
+Consider the following security policy with regard to egress traffic:
+
+1. Application A is allowed to access `*.ibm.com` (all the external services with URL matching `*.ibm.com`,
+  e.g. `www.ibm.com`)
+1. Application B is allowed to access `mongo1.composedb.com`
+1. All egress traffic must be monitored
+
+Now consider a scenario in which one of application A's pods is compromised. Suppose the attackers have the
+following goals:
+
+1. Application A will try to access `*.ibm.com` unmonitored
+1. Application A will try to access `mongo1.composedb.com`
+
+Note that application A is allowed to access `*.ibm.com`, so the attacker is able to access it. There is no way
+to prevent such access since there is no way to distinguish, at least initially, between the original and the
+compromised versions of application A. However, you want to monitor any access to external services to be able to
+detect suspicious traffic, for example by applying anomaly detection tools on logs of the egress traffic.
+The attackers, on the contrary, want to access external services unmonitored, so the attack will not be detected.
+The second goal of the attackers is to access `mongo1.composedb.com`, which is forbidden for application A. Istio
+must enforce the policy that forbids access of application A to `mongo1.composedb.com` and must prevent the attack.
+
+Now let's see which attacks the attackers will try to perform to achieve their goals and how Istio secure egress traffic
+control will prevent each kind of attack. The attackers may try to:
+
+1. **Bypass** the container's sidecar proxy and access external services directly. This attack is prevented by a
+   Kubernetes Network Policy or by an L3 firewall that allow egress traffic to exit the mesh only from the egress
+   gateway.
+1. **Compromise** the egress gateway and force it to send fake information to the monitoring system or to disable
+   enforcement of the security policies.
+   This attack is prevented by applying the special security measures to the egress gateway pods.
+1. Since the previous attacks are prevented, the attackers have no other option but to direct the traffic through the
+   egress gateway. The traffic will be monitored by the egress gateway, so the goal of the attackers to access
+   external services unmonitored cannot be achieved. The attackers may want to try to achieve their second goal, that is
+   to access `mongo1.composedb.com`. To achieve it, they may try to **impersonate** as application B since
+   application B is allowed to access `mongo1.composedb.com`. This attack, fortunately, is prevented by Istio's [strong
+   identity support](/docs/concepts/security/#istio-identity).
+
+## Summary
+
+I hope that I managed to convince you that Istio can serve as an effective tool for preventing attacks involving egress
+traffic. In the next blog post in this series I compare control of egress traffic in Istio with alternative
+solutions such as
+[Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) and legacy
+egress proxies/firewalls.