Hello Dustin, The use case I'm describing actually goes a little further than my original requirement, for which the solution we discussed was accepted by all my stakeholders (after a few groans and calls for using Oracle Coherence instead of Memcached).
I appreciate it may be hard for you to see the benefit of allowing a single memcached instance to accept connections from both trusted and untrusted networks with heterogeneous clients deployed across these networks but I should clarify that some of these clients simply read the cache, and others populate it with data. We don't care too much about who can connect to the cache to read it but we care a lot about who is authorised to write to the cache. With this in mind put yourself in the position were setting up the firewall rules and secure tunnels is the job of two separate infrastructure teams and managing the secure connections on the servers which populate the cache falls into the remit of an external customer and a third party to issue certificates. This is pretty much the problem I'm facing, the challenge is as much operational as it is technical and having to orchestrate all these actors is difficult and clumsy work (hopefully for obvious reasons). Being able to manage this configuration in Memcached hugely simplifies the task. I don't need to burden the infrastructure teams nor ask to the client to manage a secure tunnel at their end I simply set up memcached to listen on multiple interfaces which connect to different VLANS and route clients that require authentication to populate the cache to connect via the secure VLAN and the read only clients from the less secure VLAN. I'd be happy to draw up a diagram of the two deployment architectures to highlight the different in entropy between them (give me a couple of days). I'm intrigued about the use of a proxy, you'll have to excuse my ignorance but are you suggesting that I can have two memcached instances configured in a cluster where they maintain their state and have one use authentication and the other not? If so this may be a possible workaround for my use case (at the cost of increasing my RAM requirements somewhat). My cache will start at about 2GB and will grow to 4GB in time. On Apr 14, 9:55 pm, Dustin <[email protected]> wrote: > On Apr 12, 4:40 am, hoos <[email protected]> wrote: > > > • Support SASL authentication > > • Don’t support SASL authentication > > • Are deployed to trusted networks > > • Are deployed to un-trusted networks > > I thought I'd replied to this... sorry. > > If you have varying levels of trust into a single memcached, you're > probably best off either not providing access at varying trust levels > to the same cache, or using proxies to contain the trust. It's hard > to see the benefit of supporting SASL on a trusted network and no SASL > on an untrusted network in the same daemon.
