4 ms·

(disclaimer: I work at dotCloud) You can actually break down the security issue into 2 distinct problems: Problem 1: unauthorized access. If an unauthorized

by shykes 14y ago

(disclaimer: I work at dotCloud) You can actually break down the security issue into 2 distinct problems: Problem 1: unauthorized access. If an unauthorized client can issue redis commands, you're screwed. One way to prevent that is to block all network trafic to redis, except for a whitelist of trusted clients. As explained above this is not possible on a PaaS because a) your application containers share source IPs with other, untrusted containers, and b) those source IPs may change at any time as your containers are moved around. However, there's another way: using a master password. With this optional feature, Redis can be configured to authenticate all queries with a single statically-defined password. You have to use it well: specifically, make it long enough to sustain brute-force attacks, and be careful where you store it. Luckily, dotCloud (and presumably other redis providers) implements these best practices for you so you can benefit from the security. Problem 2: trafic interception. Redis does not support encryption, so if Alice can eavesdrop on the network, she can intercept and possibly forge Redis commands. If you can't trust EC2's network, this means you can't use Redis on EC2 at all (independently of problem 1), unless you implement end-to-end SSL encryption with something like stunnel. However, it's more likely that you, like the majority of EC2 customers, already have to trust their network anyway. In that case, you're probably Ok using Redis on EC2 and therefore on dotCloud. So, to summarize: - A well-engineered PaaS (and specifically dotCloud) protects you from unauthorized access - If you can tolerate the risk that your public cloud provider (or somebody who hacked them) intercepting network trafic, you can use Redis on a PaaS. Otherwise you need to implement your own service with end-to-end encryption (keeping in mind that your public cloud provider also has access to encryption keys stored on disk and memory)

gingerlime 14y ago
Stunnel (which uses SSL) allows you to use client-side certificate to authenticate the client side of the connection. Similarly you can define SSH tunnels using public-key authentication. The same way github authenticates access to git repositories. You can also use VPN connections like OpenVPN etc. So even if you can't restrict by source IP, you should be able to add another layer of security wrapping redis, providing both authentication and traffic protection.
- shykes 14y ago
  That's correct. The only downside of client certificates is that they can be a PITA for developers, especially if you find yourself frequently spinning up new dev and staging environments. Also, on a PaaS this might force you to check-in your certificate alongside your code in order to deploy it. On dotCloud you can avoid this with the rsync upload method (which is now the default in 0.9).

by shykes 14y ago

gingerlime 14y ago

Stunnel (which uses SSL) allows you to use client-side certificate to authenticate the client side of the connection. Similarly you can define SSH tunnels using public-key authentication. The same way github authenticates access to git repositories. You can also use VPN connections like OpenVPN etc. So even if you can't restrict by source IP, you should be able to add another layer of security wrapping redis, providing both authentication and traffic protection.

shykes 14y ago
That's correct. The only downside of client certificates is that they can be a PITA for developers, especially if you find yourself frequently spinning up new dev and staging environments. Also, on a PaaS this might force you to check-in your certificate alongside your code in order to deploy it. On dotCloud you can avoid this with the rsync upload method (which is now the default in 0.9).