mirror of https://github.com/istio/istio.io.git
49 lines
24 KiB
HTML
49 lines
24 KiB
HTML
<!DOCTYPE html><html lang="en" itemscope itemtype="https://schema.org/WebPage"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"><meta name="theme-color" content="#466BB0"/><meta name="title" content="Using Network Policy with Istio"><meta name="description" content="How Kubernetes Network Policy relates to Istio policy"><meta name="og:title" content="Using Network Policy with Istio"><meta name="og:description" content="How Kubernetes Network Policy relates to Istio policy"><meta name="og:url" content="/blog/2017/0.1-using-network-policy.html"><meta name="og.site_name" content="Istio"><title>Istioldie 0.6 / Using Network Policy with Istio</title><script> window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date; ga('create', 'UA-98480406-2', 'auto'); ga('send', 'pageview'); </script> <script async src='https://www.google-analytics.com/analytics.js'></script><link rel="alternate" type="application/rss+xml" title="Istio Blog RSS" href="/v0.6/feed.xml"><link rel="shortcut icon" href="/v0.6/favicons/favicon.ico" ><link rel="apple-touch-icon" href="/v0.6/favicons/apple-touch-icon-180x180.png" sizes="180x180"><link rel="icon" type="image/png" href="/v0.6/favicons/favicon-16x16.png" sizes="16x16"><link rel="icon" type="image/png" href="/v0.6/favicons/favicon-32x32.png" sizes="32x32"><link rel="icon" type="image/png" href="/v0.6/favicons/android-36x36.png" sizes="36x36"><link rel="icon" type="image/png" href="/v0.6/favicons/android-48x48.png" sizes="48x48"><link rel="icon" type="image/png" href="/v0.6/favicons/android-72x72.png" sizes="72x72"><link rel="icon" type="image/png" href="/v0.6/favicons/android-96x196.png" sizes="96x196"><link rel="icon" type="image/png" href="/v0.6/favicons/android-144x144.png" sizes="144x144"><link rel="icon" type="image/png" href="/v0.6/favicons/android-192x192.png" sizes="192x192"><link rel="manifest" href="/v0.6/manifest.json"><meta name="apple-mobile-web-app-title" content="Istio"><meta name="application-name" content="Istio"><link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto:400,100,100italic,300,300italic,400italic,500,500italic,700,700italic,900,900italic"><link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/css/bootstrap.min.css" integrity="sha384-Gn5384xqQ1aoWXA+058RXPxPg6fy4IWvTNh0E263XmFcJlSAwiGgFAW/dAiS6JXm" crossorigin="anonymous"><link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.0.6/css/all.css"><link rel="stylesheet" href="/v0.6/css/light_theme.css" title="light"><link rel="alternate stylesheet" href="/v0.6/css/dark_theme.css" title="dark"> <script src="/v0.6/js/styleSwitcher.min.js"></script></head><body class="language-unknown theme-unknown"><header role="banner"><nav class="navbar navbar-expand-md navbar-dark fixed-top bg-dark"> <a class="navbar-brand" href="/v0.6/" style="visibility: visible"> <img class="logo" src="/v0.6/img/istio-logo.svg" alt="Istio Logo"/> <span class="brand-name">Istioldie 0.6</span> </a> <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarCollapse" aria-controls="navbarCollapse" aria-expanded="false" aria-label="Toggle navigation"> <span class="navbar-toggler-icon"></span> </button><div class="collapse navbar-collapse justify-content-end" id="navbarCollapse"><ul class="navbar-nav"><li class="nav-item"> <a class="nav-link " href="/v0.6/about/intro.html">About</a></li><li class="nav-item"> <a class="nav-link active" href="/v0.6/blog/2018/traffic-mirroring.html">Blog</a></li><li class="nav-item"> <a class="nav-link " href="/v0.6/docs/">Docs</a></li><li class="nav-item"> <a class="nav-link " href="/v0.6/help/">Help</a></li><li class="nav-item"> <a class="nav-link " href="/v0.6/community.html">Community</a></li><li class="nav-item dropdown" id="gearDropdown" style="white-space: nowrap"> <a href="" class="nav-link dropdown-toggle" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false"> <i style="width: 1em" class='fa fa-lg fa-cog'></i> </a><ul class="dropdown-menu" aria-labelledby="gearDropdown"><h6 class="dropdown-header">Other versions of this site</h6><li> <a href="https://istio.io">Current Release</a></li><li> <a href="https://preliminary.istio.io">Next Release</a></li><li> <a href="https://archive.istio.io">Older Releases</a></li><li class="dropdown-divider"></li><li> <i class='fa fa-check light'></i> <a href="" onclick="setActiveStyleSheet('light');return false;">Light Theme</a></li><li> <i class='fa fa-check dark'></i> <a href="" onclick="setActiveStyleSheet('dark');return false;">Dark Theme</a></li></ul></li></ul><form name="cse" id="searchbox" class="form-inline justify-content-end" role="search"> <input type="hidden" name="cx" value="013699703217164175118:iwwf17ikgf4" /> <input type="hidden" name="ie" value="utf-8" /> <input type="hidden" name="hl" value="en" /><div class="input-group"> <input name="q" class="form-control search-box" type="text" size="30" /> <button class="btn btn-search input-group-addon my-2 my-sm-0 fa fa-search" type="submit"></button></div></form></div></nav></header><div class="container-fluid blog"><div class="row row-offcanvas row-offcanvas-left"><div class="col-6 col-md-3 col-xl-2 sidebar-offcanvas"><nav class="sidebar"><div class="spacer"></div><div class="directory" role="tablist"><div class="card"><div class="card-header" role="tab" id="header1"> <a data-toggle="collapse" href="#collapse1" title="Blog posts for 2018" role="button" aria-controls="collapse1"><div> 2018 Posts</div></a></div><div id="collapse1" class="collapse" data-parent="#sidebar" role="tabpanel" aria-labelledby="header1"><div class="card-body"><ul class="tree"><li> <a title="An introduction to safer, lower-risk deployments and release to production" href="/v0.6/blog/2018/traffic-mirroring.html">Traffic mirroring with Istio for testing in production</a></li><li> <a title="Describes a simple scenario based on Istio Bookinfo sample" href="/v0.6/blog/2018/egress-tcp.html">Consuming External TCP Services</a></li><li> <a title="Describes a simple scenario based on Istio Bookinfo sample" href="/v0.6/blog/2018/egress-https.html">Consuming External Web Services</a></li></ul></div></div></div><div class="card"><div class="card-header" role="tab" id="header5"> <a data-toggle="collapse" href="#collapse5" title="Blog posts for 2017" role="button" aria-controls="collapse5"><div> 2017 Posts</div></a></div><div id="collapse5" class="collapse show" data-parent="#sidebar" role="tabpanel" aria-labelledby="header5"><div class="card-body"><ul class="tree"><li> <a title="Improving availability and reducing latency" href="/v0.6/blog/2017/mixer-spof-myth.html">Mixer and the SPOF Myth</a></li><li> <a title="Provides an overview of the Mixer plug-in architecture" href="/v0.6/blog/2017/adapter-model.html">Mixer Adapter Model</a></li><li> <a title="Istio 0.2 announcement" href="/v0.6/blog/2017/0.2-announcement.html">Announcing Istio 0.2</a></li><li> <span class="current" title="How Kubernetes Network Policy relates to Istio policy">Using Network Policy with Istio</span></li><li> <a title="Using Istio to create autoscaled canary deployments" href="/v0.6/blog/2017/0.1-canary.html">Canary Deployments using Istio</a></li><li> <a title="Istio Auth 0.1 announcement" href="/v0.6/blog/2017/0.1-auth.html">Using Istio to Improve End-to-End Security</a></li><li> <a title="Istio 0.1 announcement" href="/v0.6/blog/2017/0.1-announcement.html">Introducing Istio</a></li></ul></div></div></div><div class="text-center" style="margin-top: 1em; font-size: 1.2em;" > <a href="/v0.6/feed.xml"> <img style="width: 1.4em;" src="/v0.6/img/rss.svg" alt="RSS"/> Subscribe </a></div></div></nav></div><div class="col-12 col-md-9 col-lg-7 col-xl-8"><p class="d-md-none"> <label class="sidebar-toggler" data-toggle="offcanvas"> <i class="fa fa-chevron-right"></i> </label></p><main role="main"><h1>Using Network Policy with Istio</h1><p class="byline"> By <span class="attribution">Spike Curtis</span> / <span class="publish_date">August 10, 2017</span></p><p>The use of Network Policy to secure applications running on Kubernetes is a now a widely accepted industry best practice. Given that Istio also supports policy, we want to spend some time explaining how Istio policy and Kubernetes Network Policy interact and support each other to deliver your application securely.</p><p>Let’s start with the basics: why might you want to use both Istio and Kubernetes Network Policy? The short answer is that they are good at different things. Consider the main differences between Istio and Network Policy (we will describe “typical” implementations, e.g. Calico, but implementation details can vary with different network providers):</p><table><thead><tr><th> </th><th>Istio Policy</th><th>Network Policy</th></tr></thead><tbody><tr><td><strong>Layer</strong></td><td>“Service” — L7</td><td>“Network” — L3-4</td></tr><tr><td><strong>Implementation</strong></td><td>Userspace</td><td>Kernel</td></tr><tr><td><strong>Enforcement Point</strong></td><td>Pod</td><td>Node</td></tr></tbody></table><h2 id="layer">Layer</h2><p>Istio policy operates at the “service” layer of your network application. This is Layer 7 (Application) from the perspective of the OSI model, but the de facto model of cloud native applications is that Layer 7 actually consists of at least two layers: a service layer and a content layer. The service layer is typically HTTP, which encapsulates the actual application data (the content layer). It is at this service layer of HTTP that the Istio’s Envoy proxy operates. In contrast, Network Policy operates at Layers 3 (Network) and 4 (Transport) in the OSI model.</p><p>Operating at the service layer gives the Envoy proxy a rich set of attributes to base policy decisions on, for protocols it understands, which at present includes HTTP/1.1 & HTTP/2 (gRPC operates over HTTP/2). So, you can apply policy based on virtual host, URL, or other HTTP headers. In the future, Istio will support a wide range of Layer 7 protocols, as well as generic TCP and UDP transport.</p><p>In contrast, operating at the network layer has the advantage of being universal, since all network applications use IP. At the network layer you can apply policy regardless of the layer 7 protocol: DNS, SQL databases, real-time streaming, and a plethora of other services that do not use HTTP can be secured. Network Policy isn’t limited to a classic firewall’s tuple of IP addresses, proto, and ports. Both Istio and Network Policy are aware of rich Kubernetes labels to describe pod endpoints.</p><h2 id="implementation">Implementation</h2><p>The Istio’s proxy is based on <a href="https://envoyproxy.github.io/envoy/">Envoy</a>, which is implemented as a userspace daemon in the dataplane that interacts with the network layer using standard sockets. This gives it a large amount of flexibility in processing, and allows it to be distributed (and upgraded!) in a container.</p><p>Network Policy dataplane is typically implemented in kernel space (e.g. using iptables, eBPF filters, or even custom kernel modules). Being in kernel space allows them to be extremely fast, but not as flexible as the Envoy proxy.</p><h2 id="enforcement-point">Enforcement Point</h2><p>Policy enforcement using the Envoy proxy is implemented inside the pod, as a sidecar container in the same network namespace. This allows a simple deployment model. Some containers are given permission to reconfigure the networking inside their pod (CAP_NET_ADMIN). If such a service instance is compromised, or misbehaves (as in a malicious tenant) the proxy can be bypassed.</p><p>While this won’t let an attacker access other Istio-enabled pods, so long as they are correctly configured, it opens several attack vectors:</p><ul><li>Attacking unprotected pods</li><li>Attempting to deny service to protected pods by sending lots of traffic</li><li>Exfiltrating data collected in the pod</li><li>Attacking the cluster infrastructure (servers or Kubernetes services)</li><li>Attacking services outside the mesh, like databases, storage arrays, or legacy systems.</li></ul><p>Network Policy is typically enforced at the host node, outside the network namespace of the guest pods. This means that compromised or misbehaving pods must break into the root namespace to avoid enforcement. With the addition of egress policy due in Kubernetes 1.8, this difference makes Network Policy a key part of protecting your infrastructure from compromised workloads.</p><h2 id="examples">Examples</h2><p>Let’s walk through a few examples of what you might want to do with Kubernetes Network Policy for an Istio-enabled application. Consider the Bookinfo sample application. We’re going to cover the following use cases for Network Policy:</p><ul><li>Reduce attack surface of the application ingress</li><li>Enforce fine-grained isolation within the application</li></ul><h3 id="reduce-attack-surface-of-the-application-ingress">Reduce attack surface of the application ingress</h3><p>Our application ingress controller is the main entry-point to our application from the outside world. A quick peek at istio.yaml (used to install Istio) defines the Istio ingress like this:</p><div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="na">apiVersion</span><span class="pi">:</span> <span class="s">v1</span>
|
||
<span class="na">kind</span><span class="pi">:</span> <span class="s">Service</span>
|
||
<span class="na">metadata</span><span class="pi">:</span>
|
||
<span class="na">name</span><span class="pi">:</span> <span class="s">istio-ingress</span>
|
||
<span class="na">labels</span><span class="pi">:</span>
|
||
<span class="na">istio</span><span class="pi">:</span> <span class="s">ingress</span>
|
||
<span class="na">spec</span><span class="pi">:</span>
|
||
<span class="na">type</span><span class="pi">:</span> <span class="s">LoadBalancer</span>
|
||
<span class="na">ports</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">port</span><span class="pi">:</span> <span class="s">80</span>
|
||
<span class="na">name</span><span class="pi">:</span> <span class="s">http</span>
|
||
<span class="pi">-</span> <span class="na">port</span><span class="pi">:</span> <span class="s">443</span>
|
||
<span class="na">name</span><span class="pi">:</span> <span class="s">https</span>
|
||
<span class="na">selector</span><span class="pi">:</span>
|
||
<span class="na">istio</span><span class="pi">:</span> <span class="s">ingress</span>
|
||
</code></pre></div></div><p>The istio-ingress exposes ports 80 and 443. Let’s limit incoming traffic to just these two ports. Envoy has a <a href="https://www.envoyproxy.io/docs/envoy/latest/operations/admin.html#operations-admin-interface">built-in administrative interface</a>, and we don’t want a misconfigured istio-ingress image to accidentally expose our admin interface to the outside world. This is an example of defense in depth: a properly configured image should not expose the interface, and a properly configured Network Policy will prevent anyone from connecting to it. Either can fail or be misconfigured and we are still protected.</p><div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="na">apiVersion</span><span class="pi">:</span> <span class="s">networking.k8s.io/v1</span>
|
||
<span class="na">kind</span><span class="pi">:</span> <span class="s">NetworkPolicy</span>
|
||
<span class="na">metadata</span><span class="pi">:</span>
|
||
<span class="na">name</span><span class="pi">:</span> <span class="s">istio-ingress-lockdown</span>
|
||
<span class="na">namespace</span><span class="pi">:</span> <span class="s">default</span>
|
||
<span class="na">spec</span><span class="pi">:</span>
|
||
<span class="na">podSelector</span><span class="pi">:</span>
|
||
<span class="na">matchLabels</span><span class="pi">:</span>
|
||
<span class="na">istio</span><span class="pi">:</span> <span class="s">ingress</span>
|
||
<span class="na">ingress</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">ports</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">protocol</span><span class="pi">:</span> <span class="s">TCP</span>
|
||
<span class="na">port</span><span class="pi">:</span> <span class="s">80</span>
|
||
<span class="pi">-</span> <span class="na">protocol</span><span class="pi">:</span> <span class="s">TCP</span>
|
||
<span class="na">port</span><span class="pi">:</span> <span class="s">443</span>
|
||
</code></pre></div></div><h3 id="enforce-fine-grained-isolation-within-the-application">Enforce fine-grained isolation within the application</h3><p>Here is the service graph for the Bookinfo application.</p><div class="figure" style="width: 80%;"><div class="wrapper-with-intrinsic-ratio" style="padding-bottom: 59.08%"><figure> <a href="/v0.6/docs/guides/img/bookinfo/withistio.svg"> <img class="element-to-stretch" src="/v0.6/docs/guides/img/bookinfo/withistio.svg" alt="Bookinfo Service Graph" title="Bookinfo Service Graph" /> </a></figure></div><p>Bookinfo Service Graph</p></div><p>This graph shows every connection that a correctly functioning application should be allowed to make. All other connections, say from the Istio Ingress directly to the Rating service, are not part of the application. Let’s lock out those extraneous connections so they cannot be used by an attacker. Imagine, for example, that the Ingress pod is compromised by an exploit that allows an attacker to run arbitrary code. If we only allow connections to the Product Page pods using Network Policy, the attacker has gained no more access to my application backends <em>even though they have compromised a member of the service mesh</em>.</p><div class="language-yaml highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="na">apiVersion</span><span class="pi">:</span> <span class="s">networking.k8s.io/v1</span>
|
||
<span class="na">kind</span><span class="pi">:</span> <span class="s">NetworkPolicy</span>
|
||
<span class="na">metadata</span><span class="pi">:</span>
|
||
<span class="na">name</span><span class="pi">:</span> <span class="s">product-page-ingress</span>
|
||
<span class="na">namespace</span><span class="pi">:</span> <span class="s">default</span>
|
||
<span class="na">spec</span><span class="pi">:</span>
|
||
<span class="na">podSelector</span><span class="pi">:</span>
|
||
<span class="na">matchLabels</span><span class="pi">:</span>
|
||
<span class="na">app</span><span class="pi">:</span> <span class="s">productpage</span>
|
||
<span class="na">ingress</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">ports</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">protocol</span><span class="pi">:</span> <span class="s">TCP</span>
|
||
<span class="na">port</span><span class="pi">:</span> <span class="s">9080</span>
|
||
<span class="na">from</span><span class="pi">:</span>
|
||
<span class="pi">-</span> <span class="na">podSelector</span><span class="pi">:</span>
|
||
<span class="na">matchLabels</span><span class="pi">:</span>
|
||
<span class="na">istio</span><span class="pi">:</span> <span class="s">ingress</span>
|
||
</code></pre></div></div><p>You can and should write a similar policy for each service to enforce which other pods are allowed to access each.</p><h2 id="summary">Summary</h2><p>Our take is that Istio and Network Policy have different strengths in applying policy. Istio is application-protocol aware and highly flexible, making it ideal for applying policy in support of operational goals, like service routing, retries, circuit-breaking, etc, and for security that operates at the application layer, such as token validation. Network Policy is universal, highly efficient, and isolated from the pods, making it ideal for applying policy in support of network security goals. Furthermore, having policy that operates at different layers of the network stack is a really good thing as it gives each layer specific context without commingling of state and allows separation of responsibility.</p><p>This post is based on the three part blog series by Spike Curtis, one of the Istio team members at Tigera. The full series can be found here: <a href="https://www.projectcalico.org/using-network-policy-in-concert-with-istio/">https://www.projectcalico.org/using-network-policy-in-concert-with-istio/</a></p></main></div><div class="col-12 col-md-2 d-none d-lg-block"><nav class="toc"><div class="spacer"></div><div class="directory" role="directory"><ul><li><a href="#layer">Layer</a></li><li><a href="#implementation">Implementation</a></li><li><a href="#enforcement-point">Enforcement Point</a></li><li><a href="#examples">Examples</a><ul><li><a href="#reduce-attack-surface-of-the-application-ingress">Reduce attack surface of the application ingress</a></li><li><a href="#enforce-fine-grained-isolation-within-the-application">Enforce fine-grained isolation within the application</a></li></ul></li><li><a href="#summary">Summary</a></li></ul></div></nav></div></div></div><div class="footer"><footer><div class="container-fluid"><div class="row"><div class="col-sm-2"></div><nav class=" col-12 col-sm-3" role="navigation"><ul class="first"><li><a class="header" href="/v0.6/docs/">Docs</a></li><li><a href="/v0.6/docs/concepts/">Concepts</a></li><li><a href="/v0.6/docs/setup/">Setup</a></li><li><a href="/v0.6/docs/tasks/">Tasks</a></li><li><a href="/v0.6/docs/guides/">Guides</a></li><li><a href="/v0.6/docs/reference/">Reference</a></li></ul></nav><nav class="col-12 col-sm-3" role="navigation"><ul><li><a class="header" href="/v0.6/help/">Help</a></li><li><a href="/v0.6/help/faq/index.html">FAQ</a></li><li><a href="/v0.6/help/glossary.html">Glossary</a></li><li><a href="/v0.6/help/troubleshooting.html">Troubleshooting</a></li><li><a href="/v0.6/help/bugs.html">Report Bugs</a></li><li><a href="https://github.com/istio/istio.github.io/issues/new?title=Issue with _blog/2017/0.1-using-network-policy.md" target="_blank" rel="noopener">Doc Bugs & Gaps</a></li><li><a href="https://github.com/istio/istio.github.io/edit/master/_blog/2017/0.1-using-network-policy.md" target="_blank" rel="noopener">Edit This Page</a></li></ul></nav><nav class="col-12 col-sm-3" role="navigation"><ul><li><a class="header" href="/v0.6/community.html">Community</a></li><li> <a href="https://groups.google.com/forum/#!forum/istio-users" target="_blank" rel="noopener">User</a> | <a href="https://groups.google.com/forum/#!forum/istio-dev" target="_blank" rel="noopener">Dev Mailing Lists</a></li><li><a href="https://twitter.com/IstioMesh" target="_blank" rel="noopener">Twitter</a></li><li><a href="https://stackoverflow.com/questions/tagged/istio" target="_blank" rel="noopener">Stack Overflow</a></li><li><a href="https://github.com/istio/community/" target="_blank" rel="noopener">GitHub</a></li><li><a href="https://github.com/istio/community/blob/master/WORKING-GROUPS.md" target="_blank" rel="noopener">Working Groups</a></li></ul></nav></div><div class="row"><div class="col-12"><p class="description text-center" role="contentinfo"> Istio Archive 0.6, Copyright © 2018 Istio Authors<br> Archived on 02-Apr-2018</p></div></div></div></footer></div><script src="https://code.jquery.com/jquery-3.2.1.slim.min.js" integrity="sha384-KJ3o2DKtIkvYIK3UENzmM7KCkRr/rE9/Qpg6aAZGJwFDMVNA/GpGFF93hXpG5KkN" crossorigin="anonymous"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.12.9/umd/popper.min.js" integrity="sha384-ApNbgh9B+Y1QKtv3Rn7W3mgPxhU9K/ScQsAP7hUibX39j7fakFPskvXusvfa0b4Q" crossorigin="anonymous"></script> <script src="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0/js/bootstrap.min.js" integrity="sha384-JZR6Spejh4U02d8jOt6vLEHfe/JQGiRRSQQxSfFWpi1MquVdAyjUar5+76PVCmYl" crossorigin="anonymous"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/clipboard.js/1.7.1/clipboard.min.js"></script> <script src="https://www.google.com/cse/brand?form=searchbox"></script> <script src="/v0.6/js/misc.min.js"></script></body></html>
|