I would gladly pay a license fee to install this on my servers. I would not however, feel comfortable exposing my redis cluster to the whole wide world. I think they need to figure out how to offer this as an installable piece of software, that comes with either a usage or support license.
I'm not sure how they implemented this, but there is a way to implement this in a sane way, which is as a separated process that is able to access Redis, but totally mediates the communication with it in a secure way.
So you install this daemon alongside your Redis servers deployment, and it calls home (to avoid opening ports at all) with SSL in order to establish a secure communication channel with the web app.
Every request received by the web app is then verified and sent to the Redis server only after validation.
It is interesting that this is open source and BSD licensed, so in theory RedisGreen could use the same stuff as well and join the effort. This is the common part of the infrastructure that makes somewhat sense to develop together.
I also don't want my internal servers connecting to untrusted 3rd parties and sending potentially sensitive info. We never transmit logs or perf data outside of our network.
Hi, I helped build this. A few notes about security since people are asking...
RedisMonitor supports AWS security groups for people who are interested (just hit support and ask after signing up). This is the safest way to open up Redis for the security-conscious.
Standard security on a Redis server is a very long password checked at login (AUTH). All of the communication between client and server is unencrypted. We consider this reasonably safe within EC2, high risk over the open Internet.
Redis doesn't have TLS. A few clients have forks with TLS support, but we haven't audited their security at all yet and (frankly) we don't trust them at all.
I strongly suggest you evaluate something like http://www.tarsnap.com/spiped.html, a VPN, or a similar solution. This isn't just read-only access we are talking about.
I absolutely acknowledge that inter-region AWS usage is over the open Internet, and no one's encouraging bad habits like transferring unencrypted data between regions here.
VPNs are great. AWS security groups are reliable too.
I may have overreacted but I've seen people make statements like "We consider this reasonably safe within EC2..." and not realize the inter-region issue. That is why I wanted to force a clear statement.
I also think this really needs to be in your marketing copy or someone who is unaware of that is going to do that sort of thing.
Sorry if I'm being a pain but I think you are overestimating the average developer's knowledge of the potential security issues with exposing Redis like this.
Heroku offers 4 redis cloud providers. I wonder how many setups (if any) happen to go through inter-region, and if some of these providers support some kind of VPN/tunneling.
This violates a direct security tenet espoused by Redis itself:
"Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket." (http://redis.io/topics/security)
Moreover, your channel, which could be accomplished with a safer read-only, verified script, enables write access to potentially production Redis servers.
Write access for a _monitoring_ service.
AUTH from Redis is _not_ the only concern in this case.
What if the Redis server has buffer overflows?
What if the Redis server has a bug lurking inside it like Heartbleed?
Even _without_ logging in with AUTH, attackers could still access and play with this Redis server because it is no longer firewalled---it has to allow you to connect to it.
As others suggest, I would figure out some _secure_ _read-only_ method of accessing the Redis server.
Yes, like I said they probably wanted to avoid an install process and I would only do this internally. :)
That doesn't mean there isn't a cost v. benefit decision to be made that should be left up to the end user at some point. But basic precautions [such as securing the connection properly] need to be made at a minimum.
I provided the TBH as part of the disclosure of 'I do this...but I do not use a 3rd party.' so it is viable if done internally.
It is ridiculous to ask people to expose their Redis instances to the open internet while ignoring all the security risks associated with this, in addition to giving you full read/write access.
It wouldn't be much added complexity to require the use of something like stunnel or spiped. Or better yet a little daemon that streams the relevant data to your service; which can be audited and verified.
(1) Probably _yes_ unless you are inside Amazon EC2 and use some special security group settings and (hope) that all traffic and access stays within EC2 networks.
(2) It is impossible with the current setup to do that.
also there's a (3) you didn't ask, but should think about:
(3) You are giving _write-access_ to a _monitoring_ service.
This is a service that needs an agent type setup, I am disappointed by the number of services these days that require the ability to SSH or connect directly to my systems from some unknown network.
I am deliberately going to keep my Redis inside a VPC security group that permits zero outside connectivity, I only expect my webservers/workers/monitors to connect to a database so giving some third party access violates the whole point of VPC.
I'd invest the time to either use something like bsg75 mentioned or write your own Redis stat reporting in agent in something like Go.
