Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go-Safeweb

github.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Go-Safeweb

#31

Post by sofixa »

cyberpunk wrote: post #29
grogenaut wrote: post #23

Earlier quoted context omitted.

Why add another layer if you aren't already using istio or cilium?

Because it’s zero configuration auto mtls between all the services in your cluster (or intra-node if cillium) instead of managing a tls cert for every service?

Zero to little configuration at point of use, but a lot of upfront configuration, maintenance, fun issues when you need something slightly less traditional (e.g. something that needs raw TCP or heavens forbid, UDP). Different trade offs for different situations.

Re: Go-Safeweb

#32

Post by sofixa »

bayindirh wrote: post #20
yjftsjthsd-h wrote: post #13

Earlier quoted context omitted.

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. Why? I've run plenty of normal non-containerized apps that bind localhost:1234 and then are reverse proxied by nginx or caddy or whatever. (I agree that you would need a reverse proxy, I think that's kinda the point, it's the container thing I don't get)

Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned. Exhibit A: Docmost: https://docmost.com/docs/self-hosting/environment-variables I can understand the reverse proxy, but I want to run thing on a small VPS or a Raspberry Pi, etc. I want to use minimum resources so I can run more things per server. If this…

> Because some of the applications are "container native" and do not support configuration of IP/Port binding. Why? UNIX philosophy and working traditions be damned.

I'm not sure I follow. Docmost runs in a container, on a port which is configurable. By default, as all containers, that port is local to the container. The container orchestrator (be it docker CLI, docker-compose, Swarm, Nomad, Kubernetes, Podman) is the one who you instruct to expose a port from the container network to your host network. Docker tries to be smart and easy and will expose it on all networks by default, but even on it it's configurable, let alone on the more advanced options.

Re: Go-Safeweb

#33

Post by sofixa »

caust1c wrote: post #2

[flagged]

> Should google put this on all their products

They have a few products you pay for and are thus supported (for consumers YouTube Premium, Google One which is Drive storage+support, for organisations Google Cloud, Google Workspace), but for everything else, yeah. Unless you pay for One, you get no support from them on the random free stuff like Keep or Maps - you get what you pay for (in reality much more than that, something like Maps is a massive effort everyone can use for free).

Re: Go-Safeweb

#34

Post by hnlmorg »

kortilla wrote: post #11
NhanH wrote: post #10

Earlier quoted context omitted.

Handling https in the project also adds tons of complexity in the long run though: tls/ssl library versions, cert handling. Instead of having one way to deal with all of them (at the proxy layer, or sometimes at network layer), I have to deal with individual software way of managing those

I think you’re vastly overestimating the complexity of pointing a TLS library to a CA.

Their point isn’t about the complexity of installing a certificate. It’s doing it successfully and securely at scale.

Everything is easy until you have to do it at scale.

Re: Go-Safeweb

#35

Post by denysvitali »

sofixa wrote: post #33
caust1c wrote: post #2

[flagged]

> Should google put this on all their products They have a few products you pay for and are thus supported (for consumers YouTube Premium, Google One which is Drive storage+support, for organisations Google Cloud, Google Workspace), but for everything else, yeah. Unless you pay for One, you get no support from them on the random free stuff like Keep or Maps - you get what you pay for (in reality much more than that,…

As a Google One customer, I can guarantee that you get no support from them either.

The real support comes from talking with someone who works at Google and can direct you to the right team...

Re: Go-Safeweb

#37

Post by karmarepellent »

pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

I have use cases for both approaches (letting a reverse proxy handle TLS, letting the application listen on an external socket and handling TLS in the application).

I find is is easier to configure an application with a reverse proxy in front when different paths require e.g. different cache-control response headers. At the end of the day I do not want to replicate all the logic that nginx (and others) already provide when it integrates well with the application at the back.

Other commenters suggest that both ways (with or without additional reverse proxy) add "tons of complexity". I don't see why. Using a reverse proxy is what we have done for a while now. Installation and configuration (with a reasonable amount of hardening) is not complex and there exist a lot of resources to make it easier. And leaving the reverse proxy out and handling TLS in the application itself should not be "complex" either. Just parse a certificate and private key and supply them to whatever web framework you happen to use.

Re: Go-Safeweb

#38

Post by cyberpunk »

sofixa wrote: post #31
cyberpunk wrote: post #29

Earlier quoted context omitted.

Because it’s zero configuration auto mtls between all the services in your cluster (or intra-node if cillium) instead of managing a tls cert for every service?

Zero to little configuration at point of use, but a lot of upfront configuration, maintenance, fun issues when you need something slightly less traditional (e.g. something that needs raw TCP or heavens forbid, UDP). Different trade offs for different situations.

I still think it’s far less than managing tls per service.

Every component needs a different tls configuration, vs one time installing istio.

Raw TCP is supported by istio even with mtls, you just have to match in your VirtualServices on SNI instead of Host header.

We routinely mix tcp and http services on the same external ports, with mtls for both.

UDP I don’t really see how is relevant to a conversation on tls

Re: Go-Safeweb

#39

Post by L3viathan »

kyrra wrote: post #12
caust1c wrote: post #2

[flagged]

Any projects that does not have official headcount gets that tag line. Even some projects that are funded internally, may get that moniker externally as there's no guarantee it will be maintained. Most of the time these are projects that individual engineers go through the pain of open sourcing.

> as there's no guarantee it will be maintained

As opposed to official projects like Allo, Wave, Reader, etc. that will?

Re: Go-Safeweb

#40

Post by KelvinFineBoy69 »

pushupentry1219 wrote: post #6

Not sure how I feel about the HTTPS/TLS related bits. These days anything I write in Go uses plain HTTP, and the TLS is done by a reverse proxy of some variety that does some other stuff with the traffic too including security headers, routing for different paths to different services, etc. I never run a go web application "bare", public facing, and manually supplying cert files.

[dead]
Post reply on HN