Aaron Stone wrote:
Authentication, at least, has been in the community memcached release for
the last two micro releases:
http://code.google.com/p/memcached/wiki/ReleaseNotes143
It's a reasonable effort at keeping someone from writing to your
cache. Surely they can still sniff the network to get your data.
memcached with encryption is like a Ferrari with monster truck tires.
Oops, I see I brought up a few things that were already in the thread,
sorry!
I think I agree here, but it may depend. In my opinion, with most
things security related, the level of controls inserted should be
proportional to the anticipated threat. The SASL implementation was put
into memcached (and libmemcached and spymemcached) with a use case in mind.
The very real use case that some people were trying to deal with in
cloud deployments (and possibly some cloudy enterprise deployments) is a
situation where it'd be hard to sniff the network, but it would be
useful to ensure you know who someone is when they connect. This was
covered back when it was released:
http://code.google.com/p/memcached/wiki/SASLHowto
http://blog.northscale.com/northscale-blog/2009/11/sasl-memcached-now-available.html
http://blogs.sun.com/trond/entry/sasl_support_in_libmemcached
There are some who run on clouds (public or private) who may need this
kind of thing. There are others who run on pretty well controlled
networks that don't need any of it. Right now, memcached provides both.
I could see situations where one may need additional controls, but the
kind of security controls that started the thread off (namely SELinux)
which to me means security labels, usually means you don't trust
non-audited programs and instead have the platform look after them. I
guess KaiGai has taken that further with other application components
though.
Getting down to the item level would be tough to accept due to the
overhead involved, one would think though. There may be some ways of
getting closer to access control though without going down to the item
level.
- Matt
