<div dir="ltr">Hi all,<br><br>Whenever deploying a service inside a network, basic security concerns come to mind:<br><br>Is the network trusted? Can we send data in plaintext?<br>Is the service available only to those intended to use it?<br><div>Can the service itself or others have access to the data?</div><div><br></div><div>That is no exception for caching servers and a while ago, me and Lance Bragstad started a discussion about this topic.<br></div><br><font size="4"><b>Possible solutions<br></b></font><br><div><b>Protecting data in transit using TLS<br></b></div><div><br></div><div>Requires a backend with TLS support.<br></div><br>Since version 1.5.13, Memcached supports authentication and encryption via TLS. This feature requires:<br><br>OpenSSL 1.1.0 or later;<br>A Memcached client with TLS support;<br>A Memcached server built using ./configure --enable-tls.<br><br>Encrypting the traffic protects the data in transit from reading and tampering. The complexity impact is that each Memcached server will need a valid certificate. The performance impact is the TLS overhead itself.<br><br>Performing client authentication protects the server from unauthorized read and write operations. The complexity impact is that each Memcached client will need a valid certificate. The performance impact is bigger due to the extra steps to authenticate both sides.<br><br>This approach doesn't protect the data held in memory by Memcached in any other way.<br><b><br></b><div><b>Authentication using SASL</b></div><div><b><br></b></div><div>Requires a backend with SASL support.<br></div><div><b></b></div><br>Since version 1.4.3, Memcached supports authentication via SASL. This feature requires:<br><br>A Memcached client with SASL support;<br>A Memcached server built using ./configure --enable-sasl.<br><br>This approach protects the server from unauthorized read and write operations. The complexity and performance impact is according to SASL usage.<br><br>This approach doesn't protect the data in transit or held in memory by Memcached in any other way.<br><b><br></b><div><b>Encrypting data before storing</b></div><div><b><br></b></div><div>Requires <b>NO</b> extra features in the backend.<br></div><div><b></b></div><br>This approach consists of encrypting the data before sending it to the caching servers. The complexity impact is dealing with key sharing for the encryption/decryption process. The performance impact depends on the algorithms used for encryption.<br><br><div>This approach protects the data both in transit and held in memory by caching servers, but the key sharing is more prone to setup errors than the TLS or the SASL approach.</div><div><br></div><div>---</div><div><br></div><div>After considering the possible solutions, we decided to tackle the TLS path first. We did an initial analysis of oslo.cache backends that use Memcached together with Hervé Beraud here:</div><div><br></div><div><a href="https://etherpad.openstack.org/p/oslo-cache-tls-support-worksheet">https://etherpad.openstack.org/p/oslo-cache-tls-support-worksheet</a></div><div><br></div><div>Since python-binary-memcached already has SASL support, we thought it to be a good first candidate to implement TLS support and last month I had it merged here:</div><div><br></div><div><a href="https://github.com/jaysonsantos/python-binary-memcached/pull/211">https://github.com/jaysonsantos/python-binary-memcached/pull/211</a></div><div><br></div><div>We are now looking for more people interested in the discussion and help to push changes forward.<br></div><div><br></div>--<br><br>Moisés Guimarães<br><br>Software Engineer<br><br>Red Hat</div>