On Wed, Jan 25, 2017 at 5:40 PM, Julien Boeuf <jbo...@google.com> wrote:
> I think "when it sees the proxy address" also has fundamental issues, like >> requiring the proxy to have a hard-coded stable IP. That means you couldn't >> add a new proxy to the rotation if experiencing too much load. >> >> More likely, in your scheme, I'd expect the "proxy address" to become >> 100% fake. "Oh! It's 1.1.1.1! That's our secret code for proxy address." >> > The main issue here I think, as you pointed out, is that naming and the > mapper need to agree on something (e.g. the proxy address or a sentinel > address as in your example) and this is not great. On the other hand, it > allows us to support cases where the name of the LB (or direct backend > connection in non-LB case) cannot be really resolved on the client but can > be resolved on the proxy. This is a really nice feature of HTTP CONNECT so > I'm willing to live with it. > As another alternative, why not fix all of case 1 and support programmatic configuration, in addition to http_proxy? What would be wrong with specifying configuration that lb.example.com should use proxy 1.2.3.4 (like in case 1, but only for the host lb.example.com)? A more concrete flow: 1. client wants to connect to service.example.com 2. check whether service.example.com should use a proxy. It shouldn't 3. do DNS SRV resolution for _grpclb._tcp.service.example.com to determine if it should use a LB. It should, and says to connect to lb.example.com 4. check whether lb.example.com should use a proxy. It should 5. use CONNECT to lb.example.com (as a hostname) I recognize step 3 is speculative, but it seems any discussion as to how GRPCLB+DNS works in speculative. If I want Case 2, but don't want to expose internal IP addresses to >>>> unauthenticated clients, I'd just make GRPCLB public and connect to it >>>> directly, without CONNECT. DNS returns public IPs, and the GRPCLB >>>> communication can be authenticated. >>>> >>> I don't think that this would pass some security/deployment requirements > (certainly not ours) as it would force the load balancer to run within the > client's security zone boundary. > How so? I'd use a L4 (if using client certs) or L7 (if using bearer tokens) reverse proxy instead of a forward proxy. The reverse proxy would be in the same network location as the forward proxy. Now, you could complain that now there are two proxies instead of one. I would agree that is a shortcoming. There could be other issues, like maybe it is harder to configure clients. But I don't see any security/trust zone differences between the approaches. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oMCEysy0brO3ywBwNdXTamvWgz2F3qYFD7xEy1ary8FpQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
