improbable-eng / kedge Goto Github PK

We use https://github.com/improbable-eng/go-srvlb resolver to watch on resolver changes.

The interval of lookup is based on TTL, but std golang net libraries does not support those.

So either:

• use https://github.com/miekg/dns inside of https://github.com/improbable-eng/go-srvlb
• move to https://github.com/grpc/grpc-go/blob/master/resolver/dns/dns_resolver.go#L195

Error wraps are too verbose. E.g:

errors.Wrapf(err, "error on updating routing on event %v", event)`

Can be reduce to just:

errors.Wrapf(err, "update routing on event %v", event)`

There are some strong use cases to give fine-grained control over what permissions are needed for each individual route.

• For OIDC it will be just expected permissions per certain route
• For TLS certs - expected metadata

Preferably, it would be a separate layer before proper routing. We don't want to mix mapping with authorizing the request. Instead, we want to isolate potential auth bugs (up for discussion).

However, there are some specific arguments not to do it though.

1. Encourage additional auth per service. is easier to separate logic here and to not use kedge as default auth layer for service. (however, as an example, Nginx is doing exactly that)
2. Difficulty in maintenance and configuration of these auths per route.

Nevertheless, we can consider doing it if needed.

Hey, this looks AMAZING! Thank you for this.

I was wondering if it would be possible to access RTSP connections (next to HTTP) in another cluster?

Cédric

Similar to https://github.com/improbable-eng/kedge/blob/master/proto/kedge/config/http/routes/adhoc.proto we could potentially implement gRPC adhoc rules bases on authority.

When trying to access the /debug/pprof/profile endpoint for a golang webserver with kedge/winch, I get an ERR_EMPTY_RESPONSE.

Basically this will allow debug, per container access.

How it should work?
IPAdhoc:

• For some specified matcher in form of <ip>.matcher dial to ip and allow only some ports.
  PodAdhoc:
• For some specified matcher in form of <pod>.matcher - ask Kube API for pod IP (with some cache) and dial to fetched ip and allow only some ports.

We resolve all configured kEdges on demand. Even when it is used constantly, we perform DNS resolution every each time.

Let's optimize this. (DNS can be flaky)

Right now, there is no possibility to configure correct TLS. The only possibility is to use insecure option.

Running: kubectl logs <something -f

Gives some logs and after a ~minute it returns error: unexpected EOF

Winch:

WARN[337520] httputil: ReverseProxy read error during body copy: unexpected EOF
  caller=winch.ReverseProxy system=http

Kedge:
time="2018-05-22T13:56:10Z" level=warning msg="httputil: ReverseProxy read error during body copy: context canceled\n" caller="backend reverseProxy" system=http

Reading the blog article/readme, the architecture bears some similarities to the newly introduced Gateways in Istio, that allows bridging multiple kubernetes clusters or any infrastructure for that matter, while still leveraging a TLS infrastructure. (Disclaimer: I am one of the authors of the gateway in Istio). It would be educational and helpful for others (using Istio) to know the drawbacks of the architecture I describe below. If there are any limitations, we would be happy to address them. [sorry for spamming your issue list, but I couldn't get hold of your email]

Here is a simple strawman version of cross cluster communication using the gateways (https://github.com/rshriram/istio_federation_demo) which uses a similar architecture to yours (a globally shared DNS domain, ingress gateway to route to appropriate backend service, etc.). It has end to end mTLS (shared root CA, per cluster intermediate CA, etc.). With that, you would simply be able to do something like http://foo.bar.com, that would be upgraded to mTLS by the local sidecar (istio proxy), and forwarded to the remote gateway (authenticated via mTLS again), and then to the backend service.

The /rs/cors package has this reported CVE CVE-2018-20744 when the CORS policy is set to *. Since the CORS policy is configurable with a flag it is possible a user could configure it to "*" resulting in insecure behaviour.

This will allow to have TLS passthrough on all hops. However it requires Go client supporting HTTP CONNECT, which is scheduled to be in Go 1.10 release.