Announcing Envoy: C++ L7 proxy and communication bus • Hacker News Board

Re: Announcing Envoy: C++ L7 proxy and communication bus

#31

Post by athrowaway98988 » Thu, Sep 15, 2016, 4:01 AM UTC

seasonedschemer wrote: post #11

The info in https://lyft.github.io/envoy/docs/intro/comparison.html#prox... about Proxygen not supporting HTTP/2 is not correct. Proxygen has had HTTP/2 support for a while ( https://github.com/facebook/proxygen/blob/master/proxygen/li... ). Disclaimer: I work on Proxygen at FB.

This post needs no disclaimer. You are posting facts, not opinions that might be considered biased. A "Source: I work on Proxy at FB" might be understandable, but you provided source in the post.

Whether it's true or not, you look like you're just using the excuse to announce to everyone that you work at FB. As a person who works at Google, I understand the temptation... but you should fight it. It's super annoying.

Re: Announcing Envoy: C++ L7 proxy and communication bus

#32

Post by jguegant » Thu, Sep 15, 2016, 2:46 PM UTC

Any explanation on not using Asio instead of libevent (or libuv)? Performances?

Re: Announcing Envoy: C++ L7 proxy and communication bus

#33

Post by halayli » Sat, Sep 17, 2016, 3:26 PM UTC

ryan_lane wrote: post #30

halayli wrote: post #16

Wouldn't this require private keys to be sprinkled on all machines running it to inspect the traffic?

I work for Lyft. For this we have a secret management system, called confidant ( https://lyft.github.io/confidant/ ), that we use to distribute any necessary secrets. So, yes, you may need to have keys on every node (depending on your monitoring system), but assuming you securely distribute them, it's not a big deal. This is, of course, a general problem that's not necessarily related to envoy.

This increases your attack surface area. Any breach to one of those machines and the attacker can start doing mitm attacks. It also limits auto scalability assuming newly provisioned machines require manual approval of priv key distribution (that stays in memory) via hsm, and the same goes if the process dies. One way to limit the key distribution is to embed the routing information you require in the SNI at a second lb layer that's shielded from public traffic. This way your public machines don't hold any keys and if they get compromised, limiting the damage.

I agree it's a general problem. But sometimes certain architectures would require more vulnerable approaches vs others.