mirror of https://github.com/istio/istio.io.git
Egress blog part 3 (#4637)
* a skeleton version * add full content * fix internal links to previous egress examples * make the structure flat decrease the indentation level of two subsections * replace subtitle and description with content relevant for part 3 * add referencing the third part from the first and the second parts * secure egress traffic control -> secure control of egress traffic * Update content/blog/2019/egress-traffic-control-in-istio-part-3/index.md Co-Authored-By: Rigs Caballero <grca@google.com> * remove "new from Co-Authored-By: Rigs Caballero <grca@google.com> * such as Kubernetes Network Policies -> such as using Kubernetes Network Policies Co-Authored-By: Rigs Caballero <grca@google.com> * proxies/firewalls -> proxies and firewalls Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence of reminding the requirements Co-Authored-By: Rigs Caballero <grca@google.com> * support for -> support of Co-Authored-By: Rigs Caballero <grca@google.com> * remove by Istio, support for -> support of Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about the two alternative solutions Co-Authored-By: Rigs Caballero <grca@google.com> * cannot satisfy -> the requirements they can't satisfy Co-Authored-By: Rigs Caballero <grca@google.com> * remove the dot from subtitle since Hugo complains about it * add mentioning the alternative solutions before presenting them * The most natural solution -> Kubernetes provides a native solution * rewrite the sentence about cluster operators and network policies Co-Authored-By: Rigs Caballero <grca@google.com> * can be identified -> cluster operators can identify Co-Authored-By: Rigs Caballero <grca@google.com> * stress the relation between IP ranges and not being DNS-aware * the requirement is satisfied -> network policies satisfy the requirement * rewrite the sentence about K8s network policies and requirements 3 and 4 * remove passive voice in the sentence about the fifth requirement and k8s network policies Co-Authored-By: Rigs Caballero <grca@google.com> * and to interfere -> and interfere, the node - the said node Co-Authored-By: Rigs Caballero <grca@google.com> * Add "lastly", remove passive voice from the k8s network policies and the sixth requirement Co-Authored-By: Rigs Caballero <grca@google.com> * add "in summary" to the last sentence about k8s network policies Co-Authored-By: Rigs Caballero <grca@google.com> * another approach -> the second alternative, add the to Kubernetes network policies, add "Using ... lets you" Co-Authored-By: Rigs Caballero <grca@google.com> * are configured -> configure Co-Authored-By: Rigs Caballero <grca@google.com> * remove passive voice, use operators as subjects Co-Authored-By: Rigs Caballero <grca@google.com> * not known to proxies -> proxies do not know about them Co-Authored-By: Rigs Caballero <grca@google.com> * they -> egress proxies, source specified by -> Kubernetes artifacts specifies the source Co-Authored-By: Rigs Caballero <grca@google.com> * add "in summary" to the last sentence about egress proxies Co-Authored-By: Rigs Caballero <grca@google.com> * but not -> but can't satisfy Co-Authored-By: Rigs Caballero <grca@google.com> * connect two sentences about not specifying the requirements and why they do not specify the requirements Co-Authored-By: Rigs Caballero <grca@google.com> * fix the subtitle and description that were mistakenly reverted * use lower case for network policies * remove redundant white space * remove a redundant empty line * remove a leftover and fix lines arrangement * hop with two proxies, the egress gateway -> hop with one or two proxies in the egress gateway * pay attention to performance overhead and measure it * remove "because they are DNS-aware" since they are by definiton DNS-aware * requirements 3 and 4 -> the third and the fourth requirements * proxy/firewall -> proxy or firewall * have to -> must * for authentication only without encrypting -> for authentication only, without encrypting * remove comma in "in the egress gateway, should not have a large impact" * remove "so I hope the overhead of egress traffic control in Istio will be reduced in the future" since it is implied for the fact that we are working to reduce it * use colon instead of "namely" Co-Authored-By: Rigs Caballero <grca@google.com> * split a long sentence Co-Authored-By: Rigs Caballero <grca@google.com> * do not -> don't, remove "to" after "or" Co-Authored-By: Rigs Caballero <grca@google.com> * tamper-proof -> resilient to tampering Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about Istio's additional features Co-Authored-By: Rigs Caballero <grca@google.com> * it allows defining -> define Co-Authored-By: Rigs Caballero <grca@google.com> * Is intergrated out of the box -> Out-of-the-box integration Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about writing the adapters to external monitoring once Co-Authored-By: Rigs Caballero <grca@google.com> * You can apply -> Use Co-Authored-By: Rigs Caballero <grca@google.com> * We call a system that has the advantages above -> We refer to a system with the advantages above as Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the "Let me summarize" sentence Co-Authored-By: Rigs Caballero <grca@google.com> * put Istio the first in the features table * rewrite the sentence about the price of egress control Co-Authored-By: Rigs Caballero <grca@google.com> * increase of CPU usage by the cluster pods -> increased CPU usage by the cluster's pods Co-Authored-By: Rigs Caballero <grca@google.com> * Rewrite the sentence about traffic passing through two proxies Co-Authored-By: Rigs Caballero <grca@google.com> * complete the previous commit Co-Authored-By: Rigs Caballero <grca@google.com> * In the case of -> if you use Co-Authored-By: Rigs Caballero <grca@google.com> * making the count of proxies three -> adding a third proxy. Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about the traffic between proxies on the local host Co-Authored-By: Rigs Caballero <grca@google.com> * different configurations of Istio -> different Istio configurations set to control Co-Authored-By: Rigs Caballero <grca@google.com> * to measure carefully -> to carefully measure, for your applications -> with your applications Co-Authored-By: Rigs Caballero <grca@google.com> * measure and decide -> measure before you decide Co-Authored-By: Rigs Caballero <grca@google.com> * , and also compare with -> and compare Co-Authored-By: Rigs Caballero <grca@google.com> * provide our take -> share my thoughts Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about high latency of access to external services, part 1 Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about high latency of access to external services, part 2 Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about microservice architecture Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about the additional hop Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence "we are working to reduce performance" Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about possible optimizations, part 1 Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about possible optimizations, part 2 Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about possible optimizations, part 3 Co-Authored-By: Rigs Caballero <grca@google.com> * I also hope -> hopefully, can serve as -> is, for controlling -> to control Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence about the first Istio use case Co-Authored-By: Rigs Caballero <grca@google.com> * remove leftover from the previous commit Co-Authored-By: Rigs Caballero <grca@google.com> * remove the last sentence about the performance overhead * add links to Istio features * with Istio sidecar injected -> in the mesh * then apply the adapters -> apply them * add a comma * rewrite the sentence about Istio being already beneficial Co-Authored-By: Rigs Caballero <grca@google.com> * replace * bullets by - * remove double and * The network policies -> Network policies * remove "adding a third proxy" * split a long line * add a sentence about "Istio is the only solution" * encourage users to install Istio, check Istio tasks and use discuss.istio.io * fix a typo * rewrite Istio is the only solution as bullets Co-Authored-By: Rigs Caballero <grca@google.com> * compete the previous commit Co-Authored-By: Rigs Caballero <grca@google.com> * rewrite the sentence "if you had not a chance to work with Istio yet" Co-Authored-By: Rigs Caballero <grca@google.com> * chec egress traffic control -> check egress traffic control task Co-Authored-By: Rigs Caballero <grca@google.com> * Tell us what you think -> we also want to hear from you Co-Authored-By: Rigs Caballero <grca@google.com> * specify a traffic source -> specify the traffic source * egress control task -> egress control tasks * remove the final dot from the third bullet * use a relative url for istio.io * change the published date to today
This commit is contained in:
Vadim Eisenberg
mergify[bot]
parent
3c42578b57
commit
b1b48a39eb
|
|
@ -171,7 +171,8 @@ all of these requirements, in particular it is transparent, DNS-aware, and Kuber
|
|||
|
||||
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
|
||||
control of egress traffic. In
|
||||
[the
|
||||
part 3 of this series](/blog/2019/egress-traffic-control-in-istio-part-3/) I compare it with alternative solutions such as
|
||||
[Kubernetes Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) and legacy
|
||||
egress proxies/firewalls.
|
||||
|
|
|
|||
|
|
@ -122,7 +122,7 @@ If you see other attacks that involve egress traffic or security holes in the cu
|
|||
## Summary
|
||||
|
||||
Hopefully, I managed to convince you that Istio is an effective tool to prevent attacks involving egress
|
||||
traffic. In the next part of this series, I compare secure control of egress traffic in Istio with alternative
|
||||
traffic. In [the next part of this series](/blog/2019/egress-traffic-control-in-istio-part-3/), I compare secure 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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,151 @@
|
|||
---
|
||||
title: Secure Control of Egress Traffic in Istio, part 3
|
||||
subtitle: Comparison of alternative solutions to control egress traffic including performance considerations
|
||||
description: Comparison of alternative solutions to control egress traffic including performance considerations.
|
||||
publishdate: 2019-07-22
|
||||
attribution: Vadim Eisenberg (IBM)
|
||||
keywords: [traffic-management,egress,security,gateway,tls]
|
||||
---
|
||||
|
||||
Welcome to part 3 in our 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 a secure control system for egress traffic.
|
||||
In [the second part in the series](/blog/2019/egress-traffic-control-in-istio-part-2/), I presented the Istio way of
|
||||
securing egress traffic and showed how you can prevent the attacks using Istio.
|
||||
|
||||
In this installment, I compare secure control of egress traffic in Istio with alternative solutions such as using Kubernetes
|
||||
network policies and legacy egress proxies and firewalls. Finally, I describe the performance considerations regarding the
|
||||
secure control of egress traffic in Istio.
|
||||
|
||||
## Alternative solutions for egress traffic control
|
||||
|
||||
First, let's remember the [requirements for egress traffic control](/blog/2019/egress-traffic-control-in-istio-part-1/#requirements-for-egress-traffic-control) we previously collected:
|
||||
|
||||
1. Support of [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) with
|
||||
[SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) or of [TLS origination](/docs/reference/glossary/#tls-origination).
|
||||
1. **Monitor** SNI and the source workload of every egress access.
|
||||
1. Define and enforce **policies per cluster**.
|
||||
1. Define and enforce **policies per source**, _Kubernetes-aware_.
|
||||
1. **Prevent tampering**.
|
||||
1. Traffic control is **transparent** to the applications.
|
||||
|
||||
Next, I'm going to cover two alternative solutions for egress traffic control: the Kubernetes network policies and
|
||||
egress proxies and firewalls. I show the requirements they satisfy, and, more importantly, the requirements they can't satisfy.
|
||||
|
||||
Kubernetes provides a native solution for traffic control, and in particular, for control of egress traffic, through the [network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/).
|
||||
Using these network policies, cluster operators can configure which pods can access specific external services.
|
||||
Cluster operators can identify pods by pod labels, namespace labels, or by IP ranges. To specify the external services, cluster operators can use IP ranges, but cannot use domain names like `cnn.com`. This is because **Kubernetes network policies are not DNS-aware**.
|
||||
Network policies satisfy the first requirement since they can control any TCP traffic.
|
||||
Network policies only partially satisfy the third and the fourth requirements because cluster operators can specify policies
|
||||
per cluster or per pod but operators can't identify external services by domain names.
|
||||
Network policies only satisfy the fifth requirement if the attackers are not able to break from a malicious container into the Kubernetes
|
||||
node and interfere with the implementation of the policies inside said node.
|
||||
Lastly, network policies do satisfy the sixth requirement: Operators don't need to change the code or the
|
||||
container environment. In summary, we can say that Kubernetes Network Policies provide transparent, Kubernetes-aware egress traffic
|
||||
control, which is not DNS-aware.
|
||||
|
||||
The second alternative predates the Kubernetes network policies. Using a **DNS-aware egress proxy or firewall** lets you
|
||||
configure applications to direct the traffic to the proxy and use some proxy protocol, for example,
|
||||
[SOCKS](https://en.wikipedia.org/wiki/SOCKS).
|
||||
Since operators must configure the applications, this solution is not transparent. Moreover, operators can't use
|
||||
pod labels or pod service accounts to configure the proxies because the egress proxies don't know about them. Therefore, **the egress proxies are not Kubernetes-aware** and can't fulfill the fourth requirement because
|
||||
egress proxies cannot enforce policies by source if a Kubernetes artifact specifies the source.
|
||||
In summary, egress proxies can fulfill the first, second, third and fifth requirements, but can't satisfy the fourth and
|
||||
the six requirements because they are not transparent and not Kubernetes-aware.
|
||||
|
||||
## Advantages of Istio egress traffic control
|
||||
|
||||
Istio egress traffic control is **DNS-aware**: you can define policies based on URLs or on wildcard domains like
|
||||
`*.ibm.com`. In this sense, it is better than Kubernetes network policies which are not DNS-aware.
|
||||
|
||||
Istio egress traffic control is **transparent** with regard to TLS traffic, since Istio is transparent:
|
||||
you don't need to change the applications or configure their containers.
|
||||
For HTTP traffic with TLS origination, you must configure the applications in the mesh to use HTTP instead of HTTPS.
|
||||
|
||||
Istio egress traffic control is **Kubernetes-aware**: the identity of the source of egress traffic is based on
|
||||
Kubernetes service accounts. Istio egress traffic control is better than the legacy DNS-aware proxies or firewalls which
|
||||
are not transparent and not Kubernetes-aware.
|
||||
|
||||
Istio egress traffic control is **secure**: it is based on the strong identity of Istio and, when you
|
||||
apply
|
||||
[additional security measures](/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations),
|
||||
Istio's traffic control is resilient to tampering.
|
||||
|
||||
Additionally, Istio's egress traffic control provides the following advantages:
|
||||
|
||||
- Define access policies in the same language for ingress, egress, and in-cluster traffic. You
|
||||
need to learn a single policy and configuration language for all types of traffic.
|
||||
- Out-of-the-Box integration of Istio's egress traffic control with Istio's policy and telemetry adapters.
|
||||
- Write the adapters to use external monitoring or access control systems with Istio only once and
|
||||
apply them for all types of traffic: ingress, egress, and in-cluster.
|
||||
- Use Istio's [traffic management features](/docs/concepts/traffic-management/) for egress traffic:
|
||||
load balancing, passive and active health checking, circuit breaker, timeouts, retries, fault injection, and others.
|
||||
|
||||
We refer to a system with the advantages above as **Istio-aware**.
|
||||
|
||||
The following table summarizes the egress traffic control features that Istio and the alternative solutions provide:
|
||||
|
||||
| | Istio Egress Traffic Control | Kubernetes Network Policies | Legacy Egress Proxy or Firewall |
|
||||
| --- | --- | --- | ---|
|
||||
| DNS-aware | {{< checkmark_icon >}} | {{< cancel_icon >}} | {{< checkmark_icon >}} |
|
||||
| Kubernetes-aware | {{< checkmark_icon >}} | {{< checkmark_icon >}} | {{< cancel_icon >}} | {
|
||||
| Transparent | {{< checkmark_icon >}} | {{< checkmark_icon >}} | {{< cancel_icon >}} |
|
||||
| Istio-aware | {{< checkmark_icon >}} | {{< cancel_icon >}} | {{< cancel_icon >}} |
|
||||
|
||||
## Performance considerations
|
||||
|
||||
Controlling egress traffic using Istio has a price: increased latency of calls to external services and
|
||||
increased CPU usage by the cluster's pods.
|
||||
Traffic passes through two proxies:
|
||||
|
||||
- The application's sidecar proxy
|
||||
- The egress gateway's proxy
|
||||
|
||||
If you use [TLS egress traffic to wildcard domains](/docs/tasks/traffic-management/egress/wildcard-egress-hosts/),
|
||||
you must add
|
||||
[an additional proxy](/docs/tasks/traffic-management/egress/wildcard-egress-hosts/#wildcard-configuration-for-arbitrary-domains)
|
||||
between the application and the external service. Since the traffic between the egress gateway's proxy and
|
||||
the proxy needed for the configuration of arbitrary domains using wildcards is on the pod's local
|
||||
network, that traffic shouldn't have a significant impact on latency.
|
||||
|
||||
See a [performance evaluation](/blog/2019/egress-performance/) of different Istio configurations set to control egress
|
||||
traffic. I would encourage you to carefully measure different configurations with your own applications and your own
|
||||
external services, before you decide whether you can afford the performance overhead for your use cases. You should weigh the
|
||||
required level of security versus your performance requirements and compare the performance overhead of all
|
||||
alternative solutions.
|
||||
|
||||
Let me share my thoughts on the performance overhead that controlling egress traffic using Istio adds:
|
||||
Accessing external services already could have high latency and the overhead added
|
||||
because of two or three proxies inside the cluster could likely not be very significant by comparison.
|
||||
After all, applications with a microservice architecture can have chains of dozens of calls between microservices.
|
||||
Therefore, an additional hop with one or two proxies in the egress gateway should not have a large impact.
|
||||
|
||||
Moreover, we continue to work towards reducing Istio's performance overhead.
|
||||
Possible optimizations include:
|
||||
|
||||
- Extending Envoy to handle wildcard domains: This would eliminate the need for a third proxy between
|
||||
the application and the external services for that use case.
|
||||
- Using mutual TLS for authentication only without encrypting the TLS traffic, since the traffic is already
|
||||
encrypted.
|
||||
|
||||
## Summary
|
||||
|
||||
I hope that after reading this series you are convinced that controlling egress traffic is very important for the
|
||||
security of your cluster.
|
||||
Hopefully, I also managed to convince you that Istio is an effective tool to control egress traffic
|
||||
securely, and that Istio has multiple advantages over the alternative solutions.
|
||||
Istio is the only solution I'm aware of that lets you:
|
||||
|
||||
- Control egress traffic in a secure and transparent way
|
||||
- Specify external services as domain names
|
||||
- Use Kubernetes artifacts to specify the traffic source
|
||||
|
||||
In my opinion, secure control of egress traffic is a great choice if you are looking for your first Istio use case.
|
||||
In this case, Istio already provides you some benefits even before you start using all other Istio features:
|
||||
[traffic management](/docs/tasks/traffic-management/), [security](/docs/tasks/security/),
|
||||
[policies](/docs/tasks/policy-enforcement/) and [telemetry](/docs/tasks/telemetry/), applied to traffic between
|
||||
microservices inside the cluster.
|
||||
|
||||
So, if you haven't had the chance to work with Istio yet, [install Istio](/docs/setup/kubernetes/install/) on your cluster
|
||||
and check our [egress traffic control tasks](/docs/tasks/traffic-management/egress/) and the tasks for the other
|
||||
[Istio features](/docs/tasks/). We also want to hear from you, please join us at [discuss.istio.io](https://discuss.istio.io).
|
||||
Loading…
Reference in New Issue