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

21–30 of 78 posts

Re: Go-Safeweb

#21

Post by nirui »

bayindirh wrote: post #9
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.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.

You can setup a Traefik (or some other ingress service) instance in a container and let it handle all the reverse proxying thingies for you. And if you do it right, the services should automatically register to the ingress service as they start up, and a port/HTTP route should be automatically assigned to them.

Do it in the old bare is harder and probably will always be harder, since you will be directly interact with OS facilities that was probably designed for something else than what you might try to run. Container management service such as Docker and Kubernetes abstracted away a lot of these complexities.

Funny enough, Traefik is written in Go... guess we've gone some (maybe not full) cycle on this one.

Re: Go-Safeweb

#22

Post by bayindirh »

nirui wrote: post #21
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

> Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. You can setup a Traefik (or some other ingress service) instance in a container and let it handle all the reverse proxying thingies for you. And if you do it right, the services should automatically register to the ingress service as they start up, and a port/HTTP route should be automatically assigned…

Honestly, doing things on bare server and interacting with OS is easier because it involves less moving parts and everything is in a more accessible state.

Containers are not bad per se, but cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO. Because not all of us have homelabs at home to install an onion of services to run a simple service open to outside.

A good example of this is Wiki.js. It's desinged as container native, but handles its own ingress, HTTPS and Let's Encrypt certificates. I have no qualms to it, but when another tool just cuts corners and tells you that "It's easy to install, but bring your own secure ingress layer on top", it gets ugly.

Because it adds moving parts, most importantly wastes resources for a 3 person installation on small hardware, etc. Keep in mind, these are tools designed for small user-bases. They're not enterprise software.

On my day job, we call 80 machine clusters "small". But this is not about things I install/manage at my job.

Re: Go-Safeweb

#23

Post by grogenaut »

cyberpunk wrote: post #18
ongy wrote: post #15

Earlier quoted context omitted.

I suspect this is partially from google's internal 0 trust cluster networking. I.e. even if the communication is entirely between components inside a k8s (or borg) cluster, it should be authenticated and encrypted. In this model, there may be a reverse proxy at the edge of the cluster, but the communication between this service and the internal services wouls still be https. With systems like cert-manager it's also i…

Why wouldn’t you use istio or cilium for this?

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

Re: Go-Safeweb

#24

Post by bayindirh »

NhanH wrote: post #10
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

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 mean, tons of "old-school" services handle these things fine for the last two decades, at least. It can't be that hard. It's just a TLS library, and some files in a specific format at the end of the day.

Re: Go-Safeweb

#25

Post by HumanOstrich »

warkdarrior wrote: post #4
caust1c wrote: post #2

[flagged]

It's an open-source library (or collection of libraries) for Go HTTP servers. Apache license, so it does not matter if Google supports it or not.

Until you have an equivalent team of volunteers ready to maintain the project, I think it does matter.

Re: Go-Safeweb

#26

Post by redundantly »

bayindirh wrote: post #24
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 mean, tons of "old-school" services handle these things fine for the last two decades, at least. It can't be that hard. It's just a TLS library, and some files in a specific format at the end of the day.

In my experience, most people have an extremely hard time wrapping their minds around how to configure TLS/HTTPS services and fail completely at understanding how it works.

Re: Go-Safeweb

#27

Post by thayne »

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.

For a single application, it's not too bad. When you have dozens of applications that all have different mechanisms to install a CA, rotate certs, etc. And some of those don't have a good way to automate rotating the certs, then it becomes a pain.

Re: Go-Safeweb

#28

Post by treflop »

bayindirh wrote: post #22
nirui wrote: post #21

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. You can setup a Traefik (or some other ingress service) instance in a container and let it handle all the reverse proxying thingies for you. And if you do it right, the services should automatically register to the ingress service as they start up, and a port/HTTP route should be automatically assigned…

Honestly, doing things on bare server and interacting with OS is easier because it involves less moving parts and everything is in a more accessible state. Containers are not bad per se, but cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO. Because not all of us have homelabs at home to install an onion of services to run a simple ser…

While I am not ready to recommend that everyone install Traefik, this is false.

You can get a single node Docker “cluster” going with Traefik in 15 seconds. There is no maintenance except updating occasionally. It doesn’t use much more resources. You do not need to install any third party tools. There is no onion of services. You literally just boot up Traefik plus your app.

This has been doable since at least 2019 by just installing Docker via your OS’ package manager.

I’ve started using containers before 99% of people and so got to see the fundamentals build up. You do not need to skip directly to “Kubernetes.” That’s like needing to wash your clothes so you skip directly to buying an industrial washing machine and then lamenting how all washing machines are overkill.

Re: Go-Safeweb

#29

Post by cyberpunk »

grogenaut wrote: post #23
cyberpunk wrote: post #18

Earlier quoted context omitted.

Why wouldn’t you use istio or cilium for this?

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?

Re: Go-Safeweb

#30

Post by ptman »

NhanH wrote: post #10
bayindirh wrote: post #9

Earlier quoted context omitted.

While I understand the sentiment, this makes bare installations too hard. A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc. That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastr…

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

https://pkg.go.dev/golang.org/x/crypto/acme/autocert
Post reply on HN