Beanstalkd: add support for SSL and auth

[zimbatm]

When deploying in the cloud it's often the case that you want to deploy beanstalkd on a remote network. An example would be if you want to use beanstalkd with a Heroku app. Because of how Heroku works, beanstalkd would have to be deployed somewhere else like for example a EC2 instance and then accessed removing from the Heroku app.

Right now the protocol doesn't have a provision to secure the traffic and identify the client so the port basically has to stay open. Because Heroku doesn't provide a fixed set of IPs for a given app the best we can do is limit the access to all the IPs allocated to us-east-1.

Is there anything right now that allows to control the ACL that I have been missing ? I don't think that the protocol supports it but I guess it could be fairly easy to use client SSL certificates to manage the encryption and authorization of clients as an overlay.

Even within a secured network it's nice to be able to assume that it has been compromised. It allows for tighter control without having to fiddle with firewalls or network appliances.

EDIT: I guess I am trying to see if I am alone on this. I would be happy to add SSL to beanstalkd if there is any interest.

[JensRantil]

Somewhat a duplicate of https://github.com/kr/beanstalkd/issues/197.

My suggestion is to front beanstalkd with an stunnel instance and do client certificate authentication.

[zimbatm]

Yes that's one possibility but most (all?) client libraries don't support it. Unless it becomes part of the protocol I doubt the support will become that wide either. What do you think ?

[JensRantil]

What do you think ?

Maybe. I guess it's a trade-off between:

• How many bells and whistles beanstalkd should support.
• How many clients supports injecting an SSL socket when they are instantiated.

I don't think the latter is too hard in most programming languages, but clearly it requires som double work. Beanstalkd has historically tried to stay slim on features.

I'm not the maintainer of this project, so I don't make the final decisions :) I'll let @kr bring up his final opinion about this.

[zimbatm]

I think it would be easier to decouple SSL and auth actually.

Adding a auth <shared-secret> step in the protocol like redis wouldn't be too much change and already support cases where you don't care about MITM (if the AWS network can be MITMed we have other concerns).

Then add SSL on top if MITM is a problem. Client SSL certificates are nice but probably harder to integrate in the client. They also tend to be quite large and not fit nicely in an ENV-based setup. Then beanstalkd would optionally implement SSL or depend on stunnel or equivalent. I guess since beanstalkd care about connection tracking not having a middleman might be beneficial there.

[ysmolsky]

I have marked this issue as unplanned. This is the kind of feature we are not planning to do in near future because of complexity and lack of clarity.

@tomponline @sergeyklay

[tomponline]

Agreed, stunnel would be an option in these cases.

[ysmolsky]

Closing since we won't fix this for sure.