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

41–50 of 78 posts

Re: Go-Safeweb

#41

Post by bayindirh »

thayne wrote: post #27
kortilla wrote: post #11

Earlier quoted context omitted.

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.

I don't think so. We run a horde of machines, and run plethora of services, which are custom and/or has a very narrow install base due to the niche they serve.

99% of them use system-wide PKI store for CA and their certificates, which is under /etc. All of them have configuration options for these folders, and have short certificate lives because of the operational regulations we have in place.

At worst case, we distribute them with saltstack. Otherwise we just use scp, maybe a small wrapper script. Managing them doesn't take any measurable time for us.

...and we have our own CA on top of it.

Re: Go-Safeweb

#42

Post by sofixa »

cyberpunk wrote: post #38
sofixa wrote: post #31

Earlier quoted context omitted.

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

> one time installing istio

And never update it afterwards?

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

You might have UDP services alongside your TCP/HTTP behind TLS.

Re: Go-Safeweb

#43

Post by bayindirh »

sofixa wrote: post #32
bayindirh wrote: post #20

Earlier quoted context omitted.

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 th…

Let me try to explain myself clearer.

First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance.

I'm talking about small fry installations, for personal reasons, on small equipment. Think Raspi5/N100 NUC boxes as the target hardware.

I have limited resources, want no heat/noise at my home or want to pay as small as possible for a good VPS. Now, for something like docmost, I need a container runtime, and ingress controller/a reverse proxy, because I want to open this service to a VPN or web somehow.

I don't have much qualms with containers, as long as there are no cut corners. We'll talk about two examples here.

First is Wiki.js. Comes with 3 containers. DB, Wiki, Updater. OK. They are not much resource heavy, so acceptable. On top, Wiki container handles its own HTTPS, TLS certificates via Let's Encrypt (and allows custom ones, as well). It's the nice one. I can expose it, or hide it, I can handle my certificates or it can handle itself. Nice, batteries included. Install in 10 seconds, update occasionally, enjoy.

Second is docmost. It's a nice tool. Allows me to create a space and put a bunch of people in to collaborate. Install for desktop in 10 seconds & Works. Nice. I want to open it to outside. Forward a couple of ports? No. There's no HTTPS. Now I need to terminate it. Traefik? Too big for the job. Apache, doable but needs half an hour from get go. Can I limit it to localhost for local installations, for myself? No. As long as I run it, it binds to 0.0.0.0. So, if I want to install it locally to my desktop, I still need to add a firewall in front of it, because whole LAN can see it, and no, I don't trust any devices on my network (not people, but the apps).

This is my problem. I want batteries included solutions, which can adapt to my circumstances. I don't have the desire to run n servers for m services, because they are too lazy to be flexible to adapt their environments. It's not I can't do it, it's the contrary, but I don't want to, because I want to live my life and have time for people and things I care.

The services I use must be able to adaptable to my environment. This is how bare-metal services, daemons in UNIX world work. I can fit a whole rack of services in a powerful enough server and isolate them if required. It saves space, power, time and sanity. Littering services with services in boxes and putting more boxes on top of that because their developers are lazy makes my blood boil.

Re: Go-Safeweb

#44

Post by bayindirh »

treflop wrote: post #28
bayindirh wrote: post #22

Earlier quoted context omitted.

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 b…

Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.

My service doesn't take much resources, also the DB I use is light by itself. I added traefik, which is also light, and the VPN daemon which is also light.

However, these four layers are not light. They're heavier. I'd rather don't have Traefik in front and have a lighter stack, because for that much resources, I can run another server at another port, which can save me another VPS (money, maintenance time, documentation and interconnection).

I mean, we were using jails before Linux had containers. I'm not new to system administration or computers in general.

I don't get angry because things are complicated/hard. I get angry because we waste resources and write bad software because we somehow think "worst is the best".

Things add up. Light becomes heavy, easy becomes meaninglessly complex. This shouldn't be like that.

Re: Go-Safeweb

#45

Post by ongy »

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?

This might be me being daft, but I never quite understood the appeal of doing this with istio. OR also partially just due to the timing of when I started to care about things in k8s world. (Rather recently)

My understanding of that model is that the services themselves still just do unauthenticated HTTP, this gets picked up on the client side by a sidecar, packed into mTLS/HTTPS, authed+unpacked on the server sidecar, then passed as plain HTTP to the server itself.

This is great when we have intra-host vulnerabilities I guess. But doesn't allow to e.g. have code sanitizers that are strict on using TLS properly (google does this).

And while it is a real gain over simple unauthed with untrusted network between nodes, with cilium taking care of the intra-node networking being secure, I don't quite see how the added layer is more useful than using network policies strictly.

(besides some edge cases where it's used to further apply internal authorization based on the identity. Though that trusts the "network" (istio) again.)

Re: Go-Safeweb

#46

Post by cyberpunk »

sofixa wrote: post #42
cyberpunk wrote: post #38

Earlier quoted context omitted.

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

> one time installing istio And never update it afterwards? > UDP I don’t really see how is relevant to a conversation on tls You might have UDP services alongside your TCP/HTTP behind TLS.

At least in our org security let us know when it's time to patch various components and it's typically just a devops chore to bump a helm chart version and merge..

I don't really understand your point; You're trying to say managing a single helm release for istio is more effort than (in my case, for example) manually managing around 40 TLS certificates (and yes, we have an in-house PKI with our own CA that issues via ACME/certbot etc also) and the services that use them? It's clearly not?

Just templating out the config files for e.g Cassandra or ES, or Redis or whatever component takes multiple x the effort of ./helm install istio.

Re: Go-Safeweb

#48

Post by nirui »

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…

Are you mad because everybody is down voting your 42133422 post to shit, so you're down voting everyone who replied you? Don't do that, because it will only give you more down votes.

> it involves less moving parts

Every sane person who experienced a few server updates will not put out claim like that. One day you ran `apt upgrade -y`, minutes later 30% of your clients PHP website somehow went down? "less moving parts"?

In fact, Docker was invented to address this exact "it worked on my machine, why not yours" problem, by actually introducing "less moving parts".

> cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO

Stop trying to misrepresent anything. No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator". Also, for real, how can you terminate HTTPS twice?

Also, from your another post:

> Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.

Why stop there, if you start from user's keyboard as a layer, then there's 5, and screen 6, then countless Internet cable and routers. Man! so many layers, it's crazy!

Also, that's not how you structure things. You have a reverse proxy, and then a service, 2 layers total.

And VPN? Oh boy you'll probably be surprised that Docker has cross-node communication built right in (https://docs.docker.com/engine/network/drivers/overlay/), so you don't even need VPN to connect to your database.

Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.

Re: Go-Safeweb

#49

Post by pushupentry1219 »

effdee wrote: post #19
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.

The phrase "SSL added and removed here" from an NSA slide comes to mind.

To be clear I meant something like Caddy, or nginx not a solution like cloudflare or GCP doing my TLS

Re: Go-Safeweb

#50

Post by gr4vityWall »

bayindirh wrote: post #43
sofixa wrote: post #32

Earlier quoted context omitted.

> 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 th…

Let me try to explain myself clearer. First, any enterprise/homelab installation with significant resources is outside of my scope. I don't care about them. When you don't pay for the infra/power cost, all bets are off. You can install quadruple redundant 300 node K8S cluster sitting on two different data centers in different cities connected to their own power generation equipment for a simple docmost instance. I'm…

> Think Raspi5/N100 NUC boxes as the target hardware.

I don't think those would be negatively impacted by running Docker or Caddy. Isn't the performance cost of containers minimal these days?

I had similar thoughts in the past, but when I looked up performance comparisons between running something on docker vs without a container, the resulting performance was practically identical.

Post reply on HN