Feature Request: Pluggable Signature Generator/Verifier

[nelz9999]

Thanks for all the awesome work on Hystrix. I'm currently in the beginning stages of trying it out on a small subset of our Production use cases, and I'm looking forward to reaping the benefits!

However, I'm slightly paranoid and uncomfortable with exposing the streams out of each box just to the entire world (at the application-layer).

I'd like for there to be at least some prima facie way to ensure that a request for the streams comes from a trusted consumer.

An extension of some base class would be able to provide the information requested.

public class HystrixStreamRequestSigner {

public boolean requireSignature() { returns false; }

// Can assume that we'd possibly use the unix time as the input public String getSignatureOutput(final long input) { ... }

public boolean verifySignature(final long input, final String signed) {...} }

(I may be able to contribute some example code if you're interested in seeing further.)

[benjchristensen]

Hi @nelz9999, sorry I missed you on IRC earlier.

I definitely agree that the streams should not be exposed publicly.

The way we handle that at Netflix is that the /hystrix.stream route is not permitted through our front-facing proxy/routing layer so only requests from inside our network can get access to them.

Another way I've seen it done is a servlet filter that only permits access to hystrix.stream if appropriate privileges are presented or it's an internal IP address.

Yet another way is that the hystrix.stream servlet is exposed on a separate HTTP listener (like port 8077) that exposes administration utilities while normal production traffic is accepted on another port (80, 8080, etc).

Do any of those solutions work for you?

[nelz9999]

@benjchristensen thanks for those suggestions!

For both the routing layer and HTTP port solutions, I'll look into those and try to get our Ops team to help me with that.

I hadn't thought of the ServletFilter, but I probably should have. That will be my first way of attacking this.

However, I was hoping that since all 3 of the projects (Turbine, Dashboard, and Event Stream) are associated, it'd be possible for them to use the same pluggable Strategy for signing/verifying the HTTP GET requests.

[benjchristensen]

Since different organizations all have different ways of accomplishing security (firewalls, security groups, single-sign on, credentials, ip ranges, etc) and it can all be accomplished without plugins (through ServletFilters, proxies, infrastructure) I think in this case it's better to not add the extra complexity to the Hystrix components themselves and leave security as a separate layer.

Also, the effort to implement, register and deploy plugins for signing/verifying for each of the components is as much work or more than the generic alternatives.

This does seem like something I should write up on the wiki though.

Is that satisfactory to you?

[nelz9999]

I've implemented a Filter around the /hystrix.stream that checks for proper 'credentials' before continuing. This will serve my purposes for now, while I am experimenting and trying to show value. Once I have buy-in from our Ops guys, then I'll be able to get them to help me implement the other techniques.

So, yes, the Filter fits into my adoption plan.

And yes, addressing the security stuff on the wiki would be helpful.

Thanks for your help!

[benjchristensen]

Glad that works for you. Hope your experimenting continues to be positive and never hesitate to ask a question here, on IRC or Twitter.

Ben