istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
istio.io/archive/v1.21/blog/2023/secure-apps-with-istio/index.html

220 lines
45 KiB
HTML
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!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="Secure Application Communications with Mutual TLS and Istio"><meta name=description content="Dive into securing application communications, mTLS and Istio to achieve end-to-end mTLS among your applications."><meta name=author content="Lin Sun (Solo.io), Yuval Kohavi (Solo.io)"><meta name=keywords content="microservices,services,mesh,istio,mtls,tls"><meta property="og:title" content="Secure Application Communications with Mutual TLS and Istio"><meta property="og:type" content="website"><meta property="og:description" content="Dive into securing application communications, mTLS and Istio to achieve end-to-end mTLS among your applications."><meta property="og:url" content="/v1.21/blog/2023/secure-apps-with-istio/"><meta property="og:image" content="https://raw.githubusercontent.com/istio/istio.io/master/static/img/istio-social.png"><meta property="og:image:alt" content="The Istio sailboat logo"><meta property="og:image:width" content="4096"><meta property="og:image:height" content="2048"><meta property="og:site_name" content="Istio"><meta name=twitter:card content="summary_large_image"><meta name=twitter:site content="@IstioMesh"><title>Istioldie 1.21 / Secure Application Communications with Mutual TLS and Istio</title>
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-98480406-2"></script><script>window.dataLayer=window.dataLayer||[];function gtag(){dataLayer.push(arguments)}gtag("js",new Date),gtag("config","UA-98480406-2")</script><link rel=alternate type=application/rss+xml title="Istio Blog" href=/v1.21/blog/feed.xml><link rel=alternate type=application/rss+xml title="Istio News" href=/v1.21/news/feed.xml><link rel=alternate type=application/rss+xml title="Istio Blog and News" href=/v1.21/feed.xml><link rel="shortcut icon" href=/v1.21/favicons/favicon.ico><link rel=apple-touch-icon href=/v1.21/favicons/apple-touch-icon-180x180.png sizes=180x180><link rel=icon type=image/png href=/v1.21/favicons/favicon-16x16.png sizes=16x16><link rel=icon type=image/png href=/v1.21/favicons/favicon-32x32.png sizes=32x32><link rel=icon type=image/png href=/v1.21/favicons/android-36x36.png sizes=36x36><link rel=icon type=image/png href=/v1.21/favicons/android-48x48.png sizes=48x48><link rel=icon type=image/png href=/v1.21/favicons/android-72x72.png sizes=72x72><link rel=icon type=image/png href=/v1.21/favicons/android-96x96.png sizes=96xW96><link rel=icon type=image/png href=/v1.21/favicons/android-144x144.png sizes=144x144><link rel=icon type=image/png href=/v1.21/favicons/android-192x192.png sizes=192x192><link rel=icon type=image/svg+xml href=/v1.21/favicons/favicon.svg><link rel=icon type=image/png href=/v1.21/favicons/favicon.png><link rel=mask-icon href=/v1.21/favicons/safari-pinned-tab.svg color=#466BB0><link rel=manifest href=/v1.21/manifest.json><meta name=apple-mobile-web-app-title content="Istio"><meta name=application-name content="Istio"><meta name=msapplication-config content="/browserconfig.xml"><meta name=msapplication-TileColor content="#466BB0"><meta name=theme-color content="#466BB0"><link rel=stylesheet href=/v1.21/css/all.css><link rel=preconnect href=https://fonts.googleapis.com><link rel=preconnect href=https://fonts.gstatic.com crossorigin><link rel=stylesheet href="https://fonts.googleapis.com/css2?family=Barlow:ital,wght@0,400;0,500;0,600;0,700;1,400;1,600&display=swap"><script src=/v1.21/js/themes_init.min.js></script></head><body class="language-unknown archive-site"><script>const branchName="release-1.21",docTitle="Secure Application Communications with Mutual TLS and Istio",iconFile="/v1.21//img/icons.svg",buttonCopy="Copy to clipboard",buttonPrint="Print",buttonDownload="Download"</script><script src="https://www.google.com/cse/brand?form=search-form" defer></script><script src=/v1.21/js/all.min.js data-manual defer></script><header class=main-navigation><nav class="main-navigation-wrapper container-l"><div class=main-navigation-header><a id=brand href=/v1.21/ aria-label=logotype><span class=logo><svg xmlns="http://www.w3.org/2000/svg" width="128" height="60" viewBox="0 0 128 60"><path d="M58.434 48.823A.441.441.0 0158.3 48.497V22.583a.444.444.0 01.134-.326.446.446.0 01.327-.134h3.527a.447.447.0 01.325.134.447.447.0 01.134.326v25.914a.443.443.0 01-.134.326.444.444.0 01-.325.134h-3.527a.444.444.0 01-.327-.134z"/><path d="m70.969 48.477a6.556 6.556.0 01-2.818-1.955 4.338 4.338.0 01-1-2.78v-.345a.443.443.0 01.134-.326.444.444.0 01.326-.135h3.374a.444.444.0 01.326.135.445.445.0 01.134.326v.077a2.014 2.014.0 001.054 1.667 4.672 4.672.0 002.664.709 4.446 4.446.0 002.492-.633 1.862 1.862.0 00.958-1.591 1.426 1.426.0 00-.786-1.322 12.7 12.7.0 00-2.549-.939l-1.457-.46a21.526 21.526.0 01-3.3-1.227 6.57 6.57.0 01-2.262-1.783 4.435 4.435.0 01-.92-2.894 5.081 5.081.0 012.109-4.275 8.993 8.993.0 015.558-1.591 10.445 10.445.0 014.1.748 6.3 6.3.0 012.722 2.07 5 5 0 01.958 3.009.441.441.0 01-.134.326.441.441.0 01-.325.134h-3.258a.441.441.0 01-.326-.134.443.443.0 01-.134-.326 1.974 1.974.0 00-.978-1.667 4.647 4.647.0 00-2.665-.671 4.741 4.741.0 00-2.435.556 1.724 1.724.0 00-.938 1.553 1.512 1.512.0 00.9 1.4 15.875 15.875.0 003.01 1.055l.843.229a27.368 27.368.0 013.412 1.246 6.67 6.67.0 012.338 1.763 4.387 4.387.0 01.958 2.933 4.988 4.988.0 01-2.146 4.275 9.543 9.543.0 01-5.712 1.552 11.626 11.626.0 01-4.227-.709z"/><path d="m97.039 32.837a.443.443.0 01-.326.135h-3.911a.169.169.0 00-.191.192v9.239a2.951 2.951.0 00.632 2.108 2.7 2.7.0 002.013.652h1.15a.444.444.0 01.325.134.441.441.0 01.134.326v2.875a.471.471.0 01-.459.5l-1.994.039a8 8 0 01-4.524-1.035q-1.495-1.035-1.533-3.91V33.166A.17.17.0 0088.164 32.974H85.978A.441.441.0 0185.652 32.839.441.441.0 0185.518 32.513V29.83a.441.441.0 01.134-.326.444.444.0 01.326-.135h2.186a.169.169.0 00.191-.192v-4.485a.438.438.0 01.134-.326.44.44.0 01.325-.134h3.336a.443.443.0 01.325.134.442.442.0 01.135.326v4.485a.169.169.0 00.191.192h3.911a.446.446.0 01.326.135.446.446.0 01.134.326v2.683a.446.446.0 01-.133.324z"/><path d="m101.694 25.917a2.645 2.645.0 01-.767-1.955 2.65 2.65.0 01.767-1.955 2.65 2.65.0 011.955-.767 2.65 2.65.0 011.955.767 2.652 2.652.0 01.767 1.955 2.647 2.647.0 01-.767 1.955 2.646 2.646.0 01-1.955.767 2.645 2.645.0 01-1.955-.767zm-.211 22.906a.441.441.0 01-.134-.326V29.79a.444.444.0 01.134-.326.446.446.0 01.326-.134h3.527a.446.446.0 01.326.134.445.445.0 01.134.326v18.707a.443.443.0 01-.134.326.443.443.0 01-.326.134h-3.527a.443.443.0 01-.326-.134z"/><path d="m114.019 47.734a8.1 8.1.0 01-3.047-4.255 14.439 14.439.0 01-.652-4.37 14.3 14.3.0 01.614-4.371A7.869 7.869.0 01114 30.56a9.072 9.072.0 015.252-1.5 8.543 8.543.0 015.041 1.5 7.985 7.985.0 013.009 4.14 12.439 12.439.0 01.69 4.37 13.793 13.793.0 01-.651 4.37 8.255 8.255.0 01-3.028 4.275 8.475 8.475.0 01-5.1 1.553 8.754 8.754.0 01-5.194-1.534zm7.629-3.1a4.536 4.536.0 001.476-2.262 11.335 11.335.0 00.383-3.221 10.618 10.618.0 00-.383-3.22 4.169 4.169.0 00-1.457-2.243 4.066 4.066.0 00-2.531-.785 3.942 3.942.0 00-2.453.785 4.376 4.376.0 00-1.5 2.243 11.839 11.839.0 00-.383 3.22 11.84 11.84.0 00.383 3.221 4.222 4.222.0 001.476 2.262 4.075 4.075.0 002.549.8 3.8 3.8.0 002.44-.809z"/><path d="m15.105 32.057v15.565a.059.059.0 01-.049.059L.069 50.25A.06.06.0 01.005 50.167l14.987-33.47a.06.06.0 01.114.025z"/><path d="m17.631 23.087v24.6a.06.06.0 00.053.059l22.449 2.507a.06.06.0 00.061-.084L17.745.032a.06.06.0 00-.114.024z"/><path d="m39.961 52.548-24.833 7.45a.062.062.0 01-.043.0L.079 52.548a.059.059.0 01.026-.113h39.839a.06.06.0 01.017.113z"/></svg></span>
</a><button id=hamburger class=main-navigation-toggle aria-label="Open navigation">
<svg class="icon menu-hamburger"><use xlink:href="/v1.21/img/icons.svg#menu-hamburger"/></svg>
</button>
<button id=menu-close class=main-navigation-toggle aria-label="Close navigation"><svg class="icon menu-close"><use xlink:href="/v1.21/img/icons.svg#menu-close"/></svg></button></div><div id=header-links class=main-navigation-links-wrapper><ul class=main-navigation-links><li class=main-navigation-links-item><a class="main-navigation-links-link has-dropdown"><span>About</span><svg class="icon dropdown-arrow"><use xlink:href="/v1.21/img/icons.svg#dropdown-arrow"/></svg></a><ul class=main-navigation-links-dropdown><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/service-mesh class=main-navigation-links-link>Service mesh</a></li><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/solutions class=main-navigation-links-link>Solutions</a></li><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/case-studies class=main-navigation-links-link>Case studies</a></li><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/ecosystem class=main-navigation-links-link>Ecosystem</a></li><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/deployment class=main-navigation-links-link>Deployment</a></li><li class=main-navigation-links-dropdown-item><a href=/v1.21/about/faq class=main-navigation-links-link>FAQ</a></li></ul></li><li class=main-navigation-links-item><a href=/v1.21/blog/ class=main-navigation-links-link><span>Blog</span></a></li><li class=main-navigation-links-item><a href=/v1.21/news/ class=main-navigation-links-link><span>News</span></a></li><li class=main-navigation-links-item><a href=/v1.21/get-involved/ class=main-navigation-links-link><span>Get involved</span></a></li><li class=main-navigation-links-item><a href=/v1.21/docs/ class=main-navigation-links-link><span>Documentation</span></a></li></ul><div class=main-navigation-footer><button id=search-show class=search-show title='Search this site' aria-label=Search><svg class="icon magnifier"><use xlink:href="/v1.21/img/icons.svg#magnifier"/></svg></button>
<a href=/v1.21/docs/setup/getting-started class="btn btn--primary" id=try-istio>Try Istio</a></div></div><form id=search-form class=search name=cse role=search><input type=hidden name=cx value=002184991200833970123:iwwf17ikgf4>
<input type=hidden name=ie value=utf-8>
<input type=hidden name=hl value=en>
<input type=hidden id=search-page-url value=/search>
<input id=search-textbox class="search-textbox form-control" name=q type=search aria-label='Search this site' placeholder=Search>
<button id=search-close title='Cancel search' type=reset aria-label='Cancel search'><svg class="icon menu-close"><use xlink:href="/v1.21/img/icons.svg#menu-close"/></svg></button></form></nav></header><div class=banner-container></div><article class=post itemscope itemtype=http://schema.org/BlogPosting><div class=header-content><h1>Secure Application Communications with Mutual TLS and Istio</h1><p>Dive into securing application communications, mTLS and Istio to achieve end-to-end mTLS among your applications.</p></div><p class=post-author>Oct 17, 2023 <span>| </span>By Lin Sun - Solo.io, Yuval Kohavi - Solo.io</p><div><p>One of the biggest reasons users adopt service mesh is to enable secure communication
among applications using mutual TLS (mTLS) based on cryptographically verifiable
identities. In this blog, we’ll discuss the requirements of secure communication
among applications, how mTLS enables and meets all those requirements, along with
simple steps to get you started with enabling mTLS among your applications using Istio.</p><h2 id=what-do-you-need-to-secure-the-communications-among-your-applications>What do you need to secure the communications among your applications?</h2><p>Modern cloud native applications are frequently distributed across multiple Kubernetes clusters or virtual machines. New versions are being staged frequently and they can rapidly scale up and down based on user requests. As modern applications gain resource utilization efficiency by not being dependent on co-location, it is paramount to be able to apply access policy to and secure the communications among these distributed applications due to increased multiple entry points resulting in a larger attack surface. To ignore this is to invite massive business risk from data loss, data theft, forged data, or simple mishandling.</p><p>The following are the common key requirements for secure communications between applications:</p><h3 id=identities>Identities</h3><p>Identity is a fundamental component of any security architecture. Before your
applications can send their data securely, <strong>identities</strong> must be established for the
applications. This <em>establishing an identity</em> process is called <strong>identity validation</strong> - it
involves some well-known, trusted <strong>authority</strong> performing one or more
checks on the application workload to establish that it is what it claims to be. Once
the authority is satisfied, it grants the workload an identity.</p><p>Consider the act of being issued a passport - you will request one from some authority, that
authority will probably ask you for several different identity validations that prove you are
who you say you are - a birth certificate, current address, medical records, etc. Once you
have satisfied all the identity validations, you will (hopefully) be granted the identity
document. You can give that identity document to someone else as proof that you have satisfied
all the identity validation requirements of the issuing authority, and if they trust the
issuing authority (and the identity document itself), they can trust what it says about you (or they can contact the trusted authority and verify the document).</p><p>An identity could take any form, but, as with any form of identity document, the weaker the identity
validations are, the easier it is to forge, and the less useful that identity document is to anyone
using it to make a decision. That’s why, in computing, cryptographically verifiable identities are
so important - they are signed by a verifiable authority, similar to
your passport and driver’s license. Identities based around anything less are a security weakness
that is relatively easy to exploit.</p><p>Your system may have identities derived from network properties such as IP addresses with
distributed identity caches that track the mapping between identities and these network properties.
These identities don’t have strong guarantees as cryptographically verifiable
identities because IP addresses could be re-allocated to different workloads and identity caches may
not always be updated to the latest.</p><p>Using cryptographically verifiable identities for your applications is desired, because exchanging
cryptographically verifiable identities for applications during connection establishment is
inherently more reliable and secure than systems dependent on mapping IP addresses to identities.
These systems depend on distributed identity caches with eventual consistency and staleness issues
which could create a structural weakness in Kubernetes, where high rates of automated pod churn are
the norm.</p><h3 id=confidentiality>Confidentiality</h3><p>Encrypting the data transmitted among applications is critical - because in a world where breaches
are common, costly, and effectively trivial, relying entirely on <em>secure</em> internal environments or
other security perimeters has long since ceased to be adequate. To prevent a
<a href=https://en.wikipedia.org/wiki/Man-in-the-middle_attack>man-in-the-middle attack</a>, you require a unique encryption channel for a source-destination pair because you want a strong identity uniqueness guarantee to avoid <a href=https://en.wikipedia.org/wiki/Confused_deputy_problem>confused deputy problems</a>.
In other words, it is not enough to simply encrypt the channel - it must be encrypted using unique
keys directly derived from the unique source and destination identities so that only the source and
destination can decrypt the data. Further, you may need to customize the encryption, e.g. by
choosing specific ciphers, in accordance with what your security team requires.</p><h3 id=integrity>Integrity</h3><p>The encrypted data sent over the network from source to destination can’t be modified by any
identities other than the source and destination once it is sent. In other words, data received is
the same as data sent. If you don’t have <a href=https://en.wikipedia.org/wiki/Data_integrity>data integrity</a>,
someone in the middle could modify some bits or the entire content of the data during the
communication between the source and destination.</p><h3 id=access-policy-enforcement>Access Policy Enforcement</h3><p>Application owners need to apply access policies to their applications and have them enforced
properly, consistently, and unambiguously. In order to apply policy for both ends of a communication
channel, we need an application identity for each end. Once we have a cryptographically verifiable
identity with an unambiguous provenance chain for both ends of a potential communication channel, we
can begin to apply policies about who can communicate with what. Standard TLS, the widely used
cryptographic protocol that secures communication between clients (e.g., web browsers) and servers
(e.g., web servers), only really verifies and mandates an identity for one side - the server. But
for comprehensive end-to-end policy enforcement, it is critical to have a reliable, verifiable,
unambiguous identity for both sides - client and server. This is a common requirement for internal
applications - imagine for example a scenario where only a <code>frontend</code> application should call the
<strong>GET</strong> method for a backend <code>checkout</code> application, but should not be allowed to call the <code>POST</code> or
<code>DELETE</code> method. Or a scenario where only applications that have a JWT token issued by a particular
JWT issuer can call the <code>GET</code> method for a <code>checkout</code> application. By leveraging cryptographic
identities on both ends, we can ensure powerful access policies are enforced correctly, securely,
and reliably, with a validatable audit trail.</p><h3 id=fips-compliance>FIPS compliance</h3><p><a href=https://www.nist.gov/standardsgov/compliance-faqs-federal-information-processing-standards-fips>Federal Information Processing Standards (FIPS)</a>
are standards and guidelines for federal computer systems that are developed by
<a href=https://www.nist.gov/>National Institute of Standards and Technology (NIST)</a>. Not everyone
requires FIPS compliance, but FIPS compliance means meeting all the necessary security requirements
established by the U.S. government for protecting sensitive information. It is required when working
with the federal government. To follow the guidelines developed by the U.S. government relating to
cybersecurity, many in the private sector voluntarily use these FIPS standards.</p><p>To illustrate the above secure application requirements (identity, confidentiality and integrity),
let’s use the example that the <code>frontend</code> application calls the <code>checkout</code> application. Remember, you can think of <strong>ID</strong> in the diagram as any kind of identity document such as a government issued passport,
photo identifier:</p><figure style=width:100%><div class=wrapper-with-intrinsic-ratio style=padding-bottom:62.545899632802936%><a data-skipendnotes=true href=/v1.21/blog/2023/secure-apps-with-istio/requirements-flow.png title="Requirements when the frontend calls the checkout application"><img class=element-to-stretch src=/v1.21/blog/2023/secure-apps-with-istio/requirements-flow.png alt="Requirements when the frontend calls the checkout application"></a></div><figcaption>Requirements when the frontend calls the checkout application</figcaption></figure><h2 id=how-does-mtls-satisfy-the-above-requirements>How does mTLS satisfy the above requirements?</h2><p>TLS 1.3 (the most recent TLS version at the time of writing) <a href=https://datatracker.ietf.org/doc/html/rfc8446>specification</a>’s
primary goal is to provide a secure channel between two communicating peers.
The TLS secure channel has the following properties:</p><ol><li>Authentication: the server side of the channel is always authenticated, the client side is
optionally authenticated. When the client is
also authenticated, the secure channel becomes a mutual TLS channel.</li><li>Confidentiality: Data is encrypted and only visible to the client and server. Data must be
encrypted using keys that are unambiguously cryptographically bound to the source and destination
identity documents in order to reliably protect the application-layer traffic.</li><li>Integrity: data sent over the channel can’t be modified without detection. This is guaranteed by
the fact that only source and destination have the key to encrypt and decrypt the data for a given
session.</li></ol><h3 id=mtls-internals>mTLS internals</h3><p>We’ve established that cryptographically verifiable identities are key for securing channels and
supporting access policy enforcement, and we’ve established that mTLS is a battle-tested protocol
that mandates some extremely important guarantees for using cryptographically verifiable identities
on both ends of a channel - let’s get into some detail on how the mTLS protocol actually works under
the hood.</p><h4 id=handshake-protocol>Handshake protocol</h4><p>The <a href=https://datatracker.ietf.org/doc/html/rfc8446#section-4>handshake protocol</a> authenticates the
communicating peers, negotiates cryptographic modes and parameters, and establishes shared keying
material. In other words, the role of the handshake is to verify the communicating peers’ identities
and negotiate a session key, so that the rest of the connection can be encrypted based on the
session key. When your applications make a mTLS connection, server and client negotiate a cipher
suite, which dictates what encryption algorithm your applications will use for the rest of the
connection and your applications also negotiate the cryptographic session key to use. The whole
handshake is designed to resist tampering - interference by any entities that do not possess the
same unique, cryptographically verifiable identity document as the source and/or destination will be
rejected. For this reason, it is important to check the whole handshake and verify its integrity
before any communicating peer continues with the application data.</p><p>The handshake can be thought of as having three phases per the
<a href=https://datatracker.ietf.org/doc/html/rfc8446#section-2>handshake protocol overview</a> in the TLS 1.3
specification - again, let’s use the example of a <code>frontend</code> application calling a backend
<code>checkout</code> application:</p><ol><li>Phase 1: <code>frontend</code> and <code>checkout</code> negotiates the cryptographic parameters and encryption keys
that can be used to protect the rest of the handshake and traffic data.</li><li>Phase 2: everything in this phase and after are encrypted. In this phase, <code>frontend</code> and <code>checkout</code> establish other handshake parameters, and whether or not the client is also
authenticated - that is, mTLS.</li><li>Phase 3: <code>frontend</code> authenticates <code>checkout</code> via its cryptographically verifiable identity (and, in mTLS, <code>checkout</code> authenticates <code>frontend</code> in the same way).</li></ol><p>There are a few major differences since TLS 1.2 related to handshake, refer to the TLS 1.3 specification for <a href=https://datatracker.ietf.org/doc/html/rfc8446#section-1.2>more details</a>:</p><ol><li>All handshake messages (phase 2 and 3) are encrypted <strong>using the encryption keys negotiated in phase 1</strong>.</li><li>Legacy symmetric encryption algorithms have been pruned.</li><li>A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup.</li></ol><h4 id=record-protocol>Record protocol</h4><p>Having negotiated the TLS protocol version, session-key & <a href=https://en.wikipedia.org/wiki/HMAC>HMAC</a>
during the handshake phase, the peers can now securely exchange encrypted data that is chunked by the <a href=https://datatracker.ietf.org/doc/html/rfc8446#section-5>record protocol</a>. It is critical (and
required as part of the spec) to use the exact same negotiated parameters from the handshake to
encrypt the traffic to ensure the traffic confidentiality and integrity.</p><p>Putting the two protocols from the TLS 1.3 specification together and using the <code>frontend</code> and
<code>checkout</code> applications to illustrate the flow as below:</p><figure style=width:100%><div class=wrapper-with-intrinsic-ratio style=padding-bottom:59.57746478873239%><a data-skipendnotes=true href=/v1.21/blog/2023/secure-apps-with-istio/mtls-flow.png title="mTLS flows when the frontend calls the checkout application"><img class=element-to-stretch src=/v1.21/blog/2023/secure-apps-with-istio/mtls-flow.png alt="mTLS flows when the frontend calls the checkout application"></a></div><figcaption>mTLS flows when the frontend calls the checkout application</figcaption></figure><p>Who issues the identity certificates for <code>frontend</code> and <code>checkout</code>? They are commonly issued by a
<a href=https://en.wikipedia.org/wiki/Certificate_authority>certificate authority (CA)</a> which either has
its own <a href=https://en.wikipedia.org/wiki/Root_certificate>root certificate</a> or uses an intermediate
certificate from its root CA. A root certificate is basically a public key certificate that
identifies a root CA, which you likely already have in your organization. The root certificate is
distributed to <code>frontend</code> (or <code>checkout</code>) in addition to its own root-signed identity certificate. This is how
everyday, basic Public Key Infrastructure (PKI) works - a CA has responsibility for validating an
entity’s identity document, and then grants it an unforgeable identity document in the form of a
certificate.</p><p>You can rely on your CA and intermediate CAs as source of identity <strong>truth</strong> in a structural fashion
that maintains high availability and stable, persistently-verifiable identity guarantees in a way
that a massive distributed cache of IP and identity maps simply cannot. When the <code>frontend</code> and
<code>checkout</code> identity certificates are issued by the same root certificate, <code>frontend</code> and <code>checkout</code>
can verify their peer identities consistently and reliably regardless of which cluster or nodes or scale
they run.</p><p>You learned about how mTLS provides cryptographic identity, confidentiality and integrity, what
about scalability as you grow to thousands or more applications among multiple clusters? If you
establish a single root certificate across multiple clusters, the system doesn’t need to care when
your application gets a connection request from another cluster as long as it is trusted by the root
certificate - the system knows the identity on the connection is cryptographically verified. As your
application pod changes IP or is redeployed to a different cluster or network, your application (or
component acting on behalf of it) simply originates the traffic with its trusted certificate minted
by the CA to the destination. It can be 500+ network hops or can be direct; your access policies for
your application are enforced in the same fashion regardless of the topology, without needing to
keep track of the identity cache and calculate which IP address maps to which application pod.</p><p>What about FIPS compliance? Per TLS 1.3 specification, TLS-compliant applications must implement the
<code>TLS_AES_128_GCM_SHA256</code> cipher suite, and are recommended to implement <code>TLS_AES_256_GCM_SHA384</code>, both
of which are also in the <a href=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf>guidelines for TLS</a>
by NIST. RSA or ECDSA server certificates are also recommended by both TLS 1.3 specification and
NIST’s guideline for TLS. As long as you use mTLS and FIPS 140-2 or 140-3 compliant cryptographic
modules for your mTLS connections, you will be on the right path for
<a href=https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules>FIPS 140-2 or 140-3 validation</a>.</p><h2 id=what-could-go-wrong>What could go wrong</h2><p>It is critical to implement mTLS exactly as the TLS 1.3 specification dictates. Without using
proper mTLS following the TLS specification, here are a few things that can go wrong without
detection:</p><h3 id=what-if-someone-in-the-middle-of-the-connection-silently-captures-the-encrypted-data>What if someone in the middle of the connection silently captures the encrypted data?</h3><p>If the connection doesn’t follow exactly the handshake and record protocols as outlined in the TLS
specification, for example, the connection follows the handshake protocol but not using the
negotiated session key and parameters from the handshake in the record protocol, you may have your
connection’s handshake unrelated to the record protocol where identities could be different between
the handshake and record protocols. TLS requires that the handshake and record protocols share the same connection because separating them increases the attack surface for man-in-the-middle attacks.</p><p>A mTLS connection has a consistent end-to-end security from start of the handshake to finish. The
encrypted data is encrypted with the session key negotiated using the public key in the
certificate. Only the source and destination can decrypt the data with the private key. In other
words, only the owner of the certificate who has the private key can decrypt the data. Unless a
hacker has control of the private key of the certificate, he or she doesn&rsquo;t have a way to mess
around with the mTLS connection to successfully execute a man-in-the-middle attack.</p><h3 id=what-if-either-source-or-destination-identity-is-not-cryptographically-secure>What if either source or destination identity is not cryptographically secure?</h3><p>If the identity is based on network properties such as IP address, which could be re-allocated to
other pods, the identity can’t be validated using cryptographic techniques. Since this type of
identity isn’t based on cryptographic identity, your system likely has an identity cache to track
the mapping between the identity, the pod’s network labels, the corresponding IP address and the
Kubernetes node info where the pod is deployed. With an identity cache, you could run into pod IP
addresses being reused and identity mistaken where policy isn’t enforced properly when the identity
cache gets out of sync for a short period of time. For example, if you don’t have cryptographic
identity on the connection between the peers, your system would have to get the identity from the
identity cache which could be outdated or incomplete.</p><p>These identity caches that map identity to workload IPs are not <a href=https://en.wikipedia.org/wiki/ACID>ACID</a>
(Atomicity, Consistency, Isolation, and Durability) and you want your security system to be applied
to something with strong guarantees. Consider the following properties and questions you may want
to ask yourself:</p><ul><li>Staleness: How can a peer verify that an entry in the cache is <strong>current</strong>?</li><li>Incompleteness: If there&rsquo;s a cache miss and the system fails to close the connection, does the
network become unstable when it&rsquo;s only the cache <strong>synchronizer</strong> that is failing?</li><li>What if something simply doesn&rsquo;t have an IP? For example, an AWS Lambda service doesn’t by
default have a public IP.</li><li>Non-transactional: If you read the identity twice will you see the same value? If you are not
careful in your access policy or auditing implementation this can cause real issues.</li><li>Who will guard the guards themselves? Are there established practices to protect
the cache like a CA has? What proof do you have that the cache has not been tampered with? Are you
forced to reason about (and audit) the security of some complex infrastructure that is not your CA?</li></ul><p>Some of the above are worse than others. You can apply the <strong>failing closed</strong> principle but that does not solve all of the above.</p><p>Identities are also used in enforcing access policies such as authorization policy, and these
access policies are in the request path where your system has to make decisions fast to allow or
deny the access. Whenever identities become mistaken, access policies could be bypassed without
being detected or audited. For example, your identity cache may have your <code>checkout</code> pod’s prior
allocated IP address associated as one of the <code>checkout</code> identities. If the <code>checkout</code> pod gets
recycled and the same IP address is just allocated to one of the <code>frontend</code> pods, that <code>frontend</code> pod could have the <code>checkout</code>&rsquo;s identity before the cache is updated, which could cause wrong access
policies to be enforced.</p><p>Let us illustrate the identity cache staleness problem assuming the following large scale multi-cluster deployment:</p><ol><li>100 clusters where each cluster has 100 nodes with 20 pods per node. The number of total pods is 200,000.</li><li>0.25% of pods are being churned at all times (rollout, restarts, recovery, node churn, &mldr;), each churn is a 10 second window.</li><li>500 pods which are being churned are distributed to 10,000 nodes (caches) every 10 secs</li><li>If the cache synchronizer stalls what % stale is the system after 5 minutes - potentially as high as <strong>7.5%</strong>!</li></ol><p>Above assumes the cache synchronizer is in a steady state. If cache synchronizer has a brown-out it would affect its health-checking which increases churn rate, leading to cascading instability.</p><p>CA could also be <a href=https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise>compromised</a>
by an attacker who claims to present someone else and trick the CA to issue a certificate. The
attacker can then use that certificate to communicate with other peers. This is where
<a href=https://en.wikipedia.org/wiki/Certificate_authority#Certificate_revocation>certificate revocation</a> can remediate the situation by revoking the
certificate so it is no longer valid. Otherwise the attacker can exploit the compromised
certificate till expiry. It is critical to keep the private key for the root certificates in an HSM
that is kept <a href=https://en.wikipedia.org/wiki/Online_and_offline>offline</a> and use intermediate
certificates for signing workload certificates. In the event when CA is brown-out or stalled for 5
minutes, you won’t be able to obtain new or renewed workload certificates but the previously issued
and valid certificates continue to provide strong identity guarantees for your workloads. For
increased reliability for issuance, you can deploy Intermediate CAs to different zones and regions.</p><h2 id=mtls-in-istio>mTLS in Istio</h2><h3 id=enable-mtls>Enable mTLS</h3><p>Enabling mTLS in Istio for intra-mesh applications is very simple. All you need is to add your
applications to the mesh, which can be done by labeling your namespace for either sidecar injection
or ambient. In the case of sidecar, a rollout restart would be required for sidecar to be injected
to your application pods.</p><h3 id=cryptographic-identity>Cryptographic identity</h3><p>In Kubernetes environment, <a href=/v1.21/docs/concepts/security/#istio-identity>Istio</a>
creates an application’s identity based on its service account. Identity certificate is provided to
each application pod in the mesh after you add your application to the mesh.</p><p>By default, your pod&rsquo;s identity certificate expires in 24 hours and Istio rotates the pod identity
certificate every 12 hours so that in the event of a compromise (for example, compromised CA or
stolen private key for the pod), the compromised certificate only works for a very limited period
of time until the certificate expires and therefore limit the
damage it can cause.</p><h3 id=enforce-strict-mtls>Enforce strict mTLS</h3><p>The default mTLS behavior is mTLS whenever possible but not strictly enforced. To strictly enforce
your application to accept only mTLS traffic, you can use Istio’s
<a href=/v1.21/docs/reference/config/security/peer_authentication/>PeerAuthentication</a> policy, mesh-wide or
per namespace or workload. In addition, you can also apply Istio’s
<a href=/v1.21/docs/reference/config/security/authorization-policy/>AuthorizationPolicy</a> to control access for your workloads.</p><h3 id=tls-version>TLS version</h3><p>TLS version 1.3 is the default in Istio for intra-mesh application communication with the Envoy’s
<a href=https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto>default cipher suites</a>
(for example <code>TLS_AES_256_GCM_SHA384</code> for Istio 1.19.0). If you need an older TLS version, you can
<a href=/v1.21/docs/tasks/security/tls-configuration/workload-min-tls-version/>configure a different mesh-wide minimum TLS protocol version</a> for your workloads.</p><h2 id=wrapping-up>Wrapping up</h2><p>The TLS protocol, as established by the Internet Engineering Task Force (IETF), is one of the most
widely-reviewed, expert-approved, battle-tested data security protocols in existence. TLS is also
widely used globally - whenever you visit any secured website, you shop with confidence partly
because of the padlock icon to indicate that you are securely connected to a trusted site
by using TLS. The TLS 1.3 protocol was designed with end-to-end authentication,
confidentiality, and integrity to ensure your application’s identity and communications are not
compromised, and to prevent man-in-the-middle attacks. In order to achieve that (and to be
considered standards-compliant TLS), it is not only important to properly authenticate the
communicating peers but also critical to encrypt the traffic using the keys established from the
handshake. Now that you know mTLS excels at satisfying your secure application communication
requirements (cryptographic identities, confidentiality, integrity and access policy enforcement),
you can simply use Istio to upgrade your intra-mesh application communication with mTLS out of the
box - with very little configuration!</p><p><em>Huge thanks to Louis Ryan, Ben Leggett, John Howard, Christian Posta, Justin Pettit who
contributed significant time in reviewing and proposing updates to the blog!</em></p></div><nav class=pagenav><div class=left><a title="A quick recap of Istio at KubeCon North America, at the McCormick Place in Chicago." href=/v1.21/blog/2023/istio-at-kubecon-na/ class=next-link><svg class="icon left-arrow"><use xlink:href="/v1.21/img/icons.svg#left-arrow"/></svg>Istio at KubeCon North America 2023</a></div><div class=right><a title="A quick recap of Istio at KubeCon + CloudNativeCon + Open Source Summit China in Shanghai." href=/v1.21/blog/2023/istiocon-china/ class=next-link>IstioCon China 2023 wrap-up<svg class="icon right-arrow"><use xlink:href="/v1.21/img/icons.svg#right-arrow"/></svg></a></div></nav></article><footer class=footer><div class="footer-wrapper container-l"><div class="user-links footer-links"><a class=channel title='GitHub is where development takes place on Istio code' href=https://github.com/istio/community aria-label=GitHub><svg class="icon github"><use xlink:href="/v1.21/img/icons.svg#github"/></svg>
</a><a class=channel title="Access our team drive if you'd like to take a look at the Istio technical design documents" href=https://groups.google.com/forum/#!forum/istio-team-drive-access aria-label="team drive"><svg class="icon drive"><use xlink:href="/v1.21/img/icons.svg#drive"/></svg>
</a><a class=channel title='Interactively discuss issues with the Istio community on Slack' href=https://slack.istio.io aria-label=slack><svg class="icon slack"><use xlink:href="/v1.21/img/icons.svg#slack"/></svg>
</a><a class=channel title='Stack Overflow is where you can ask questions and find curated answers on deploying, configuring, and using Istio' href=https://stackoverflow.com/questions/tagged/istio aria-label="Stack Overflow"><svg class="icon stackoverflow"><use xlink:href="/v1.21/img/icons.svg#stackoverflow"/></svg>
</a><a class=channel title='Follow us on Twitter to get the latest news' href=https://twitter.com/IstioMesh aria-label=Twitter><svg class="icon twitter"><use xlink:href="/v1.21/img/icons.svg#twitter"/></svg></a></div><hr class=footer-separator role=separator><div class="info footer-info"><a class=logo href=/v1.21/ aria-label=logotype><svg xmlns="http://www.w3.org/2000/svg" width="128" height="60" viewBox="0 0 128 60"><path d="M58.434 48.823A.441.441.0 0158.3 48.497V22.583a.444.444.0 01.134-.326.446.446.0 01.327-.134h3.527a.447.447.0 01.325.134.447.447.0 01.134.326v25.914a.443.443.0 01-.134.326.444.444.0 01-.325.134h-3.527a.444.444.0 01-.327-.134z"/><path d="m70.969 48.477a6.556 6.556.0 01-2.818-1.955 4.338 4.338.0 01-1-2.78v-.345a.443.443.0 01.134-.326.444.444.0 01.326-.135h3.374a.444.444.0 01.326.135.445.445.0 01.134.326v.077a2.014 2.014.0 001.054 1.667 4.672 4.672.0 002.664.709 4.446 4.446.0 002.492-.633 1.862 1.862.0 00.958-1.591 1.426 1.426.0 00-.786-1.322 12.7 12.7.0 00-2.549-.939l-1.457-.46a21.526 21.526.0 01-3.3-1.227 6.57 6.57.0 01-2.262-1.783 4.435 4.435.0 01-.92-2.894 5.081 5.081.0 012.109-4.275 8.993 8.993.0 015.558-1.591 10.445 10.445.0 014.1.748 6.3 6.3.0 012.722 2.07 5 5 0 01.958 3.009.441.441.0 01-.134.326.441.441.0 01-.325.134h-3.258a.441.441.0 01-.326-.134.443.443.0 01-.134-.326 1.974 1.974.0 00-.978-1.667 4.647 4.647.0 00-2.665-.671 4.741 4.741.0 00-2.435.556 1.724 1.724.0 00-.938 1.553 1.512 1.512.0 00.9 1.4 15.875 15.875.0 003.01 1.055l.843.229a27.368 27.368.0 013.412 1.246 6.67 6.67.0 012.338 1.763 4.387 4.387.0 01.958 2.933 4.988 4.988.0 01-2.146 4.275 9.543 9.543.0 01-5.712 1.552 11.626 11.626.0 01-4.227-.709z"/><path d="m97.039 32.837a.443.443.0 01-.326.135h-3.911a.169.169.0 00-.191.192v9.239a2.951 2.951.0 00.632 2.108 2.7 2.7.0 002.013.652h1.15a.444.444.0 01.325.134.441.441.0 01.134.326v2.875a.471.471.0 01-.459.5l-1.994.039a8 8 0 01-4.524-1.035q-1.495-1.035-1.533-3.91V33.166A.17.17.0 0088.164 32.974H85.978A.441.441.0 0185.652 32.839.441.441.0 0185.518 32.513V29.83a.441.441.0 01.134-.326.444.444.0 01.326-.135h2.186a.169.169.0 00.191-.192v-4.485a.438.438.0 01.134-.326.44.44.0 01.325-.134h3.336a.443.443.0 01.325.134.442.442.0 01.135.326v4.485a.169.169.0 00.191.192h3.911a.446.446.0 01.326.135.446.446.0 01.134.326v2.683a.446.446.0 01-.133.324z"/><path d="m101.694 25.917a2.645 2.645.0 01-.767-1.955 2.65 2.65.0 01.767-1.955 2.65 2.65.0 011.955-.767 2.65 2.65.0 011.955.767 2.652 2.652.0 01.767 1.955 2.647 2.647.0 01-.767 1.955 2.646 2.646.0 01-1.955.767 2.645 2.645.0 01-1.955-.767zm-.211 22.906a.441.441.0 01-.134-.326V29.79a.444.444.0 01.134-.326.446.446.0 01.326-.134h3.527a.446.446.0 01.326.134.445.445.0 01.134.326v18.707a.443.443.0 01-.134.326.443.443.0 01-.326.134h-3.527a.443.443.0 01-.326-.134z"/><path d="m114.019 47.734a8.1 8.1.0 01-3.047-4.255 14.439 14.439.0 01-.652-4.37 14.3 14.3.0 01.614-4.371A7.869 7.869.0 01114 30.56a9.072 9.072.0 015.252-1.5 8.543 8.543.0 015.041 1.5 7.985 7.985.0 013.009 4.14 12.439 12.439.0 01.69 4.37 13.793 13.793.0 01-.651 4.37 8.255 8.255.0 01-3.028 4.275 8.475 8.475.0 01-5.1 1.553 8.754 8.754.0 01-5.194-1.534zm7.629-3.1a4.536 4.536.0 001.476-2.262 11.335 11.335.0 00.383-3.221 10.618 10.618.0 00-.383-3.22 4.169 4.169.0 00-1.457-2.243 4.066 4.066.0 00-2.531-.785 3.942 3.942.0 00-2.453.785 4.376 4.376.0 00-1.5 2.243 11.839 11.839.0 00-.383 3.22 11.84 11.84.0 00.383 3.221 4.222 4.222.0 001.476 2.262 4.075 4.075.0 002.549.8 3.8 3.8.0 002.44-.809z"/><path d="m15.105 32.057v15.565a.059.059.0 01-.049.059L.069 50.25A.06.06.0 01.005 50.167l14.987-33.47a.06.06.0 01.114.025z"/><path d="m17.631 23.087v24.6a.06.06.0 00.053.059l22.449 2.507a.06.06.0 00.061-.084L17.745.032a.06.06.0 00-.114.024z"/><path d="m39.961 52.548-24.833 7.45a.062.062.0 01-.043.0L.079 52.548a.059.059.0 01.026-.113h39.839a.06.06.0 01.017.113z"/></svg></a><div class=footer-languages><a tabindex=-1 lang=en id=switch-lang-en class="footer-languages-item active"><svg class="icon tick"><use xlink:href="/v1.21/img/icons.svg#tick"/></svg>
English
</a><a tabindex=-1 lang=zh id=switch-lang-zh class=footer-languages-item>中文</a></div></div><ul class=footer-policies><li class=footer-policies-item><a class=footer-policies-link href=https://www.linuxfoundation.org/legal/terms>Terms and Conditions
</a>|
<a class=footer-policies-link href=https://www.linuxfoundation.org/legal/privacy-policy>Privacy policy
</a>|
<a class=footer-policies-link href=https://www.linuxfoundation.org/legal/trademark-usage>Trademarks
</a>|
<a class=footer-policies-link href=https://github.com/istio/istio.io/edit/release-1.21/content/en/index>Edit this Page on GitHub</a></li></ul><div class=footer-base><span class=footer-base-copyright>&copy; 2024 the Istio Authors.</span>
<span class=footer-base-version>Version
Archive
1.21.2</span><ul class=footer-base-releases><li class=footer-base-releases-item><a tabindex=-1 class=footer-base-releases-link onclick='return navigateToUrlOrRoot("https://istio.io/blog/2023/secure-apps-with-istio/"),!1'>current release</a></li><li class=footer-base-releases-item><a tabindex=-1 class=footer-base-releases-link onclick='return navigateToUrlOrRoot("https://preliminary.istio.io/blog/2023/secure-apps-with-istio/"),!1'>next release</a></li><li class=footer-base-releases-item><a tabindex=-1 class=footer-base-releases-link href=https://istio.io/archive>older releases</a></li></ul></div></div></footer><div id=scroll-to-top-container aria-hidden=true><button id=scroll-to-top title='Back to top' tabindex=-1><svg class="icon top"><use xlink:href="/v1.21/img/icons.svg#top"/></svg></button></div></body></html>
Reference in New Issue View Git Blame Copy Permalink