←back to thread

Go-Safeweb

(github.com)
188 points jcbhmr | 8 comments | 14 Nov 24 03:04 UTC | HN request time: 0.001s | source | bottom
Show context
pushupentry1219 ◴[14 Nov 24 04:54 UTC] No.42133267[source]▶
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.
replies(6): >>42133422 #>>42133588 #>>42133628 #>>42134049 #>>42134283 #>>42135953 #
ongy ◴[14 Nov 24 06:21 UTC] No.42133588[source]▶
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 incredibly easy to supply every in-cluster process with a certificate form the cluster-internal CA.

-- Googler, not related to this project

replies(2): >>42133623 #>>42136458 #
cyberpunk ◴[14 Nov 24 06:30 UTC] No.42133623[source]▶
Why wouldn’t you use istio or cilium for this?
replies(2): >>42133703 #>>42134434 #
1. grogenaut ◴[14 Nov 24 06:49 UTC] No.42133703[source]▶
Why add another layer if you aren't already using istio or cilium?
replies(1): >>42133841 #
2. cyberpunk ◴[14 Nov 24 07:26 UTC] No.42133841[source]▶
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?
replies(1): >>42133881 #
3. sofixa ◴[14 Nov 24 07:35 UTC] No.42133881[source]▶
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.
replies(1): >>42134052 #
4. cyberpunk ◴[14 Nov 24 08:06 UTC] No.42134052{3}[source]▶
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

replies(1): >>42134342 #
5. sofixa ◴[14 Nov 24 09:04 UTC] No.42134342{4}[source]▶
> 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.

replies(1): >>42134687 #
6. cyberpunk ◴[14 Nov 24 10:09 UTC] No.42134687{5}[source]▶
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.

replies(1): >>42135697 #
7. sofixa ◴[14 Nov 24 12:48 UTC] No.42135697{6}[source]▶
Istio is a notorious pain to maintain, because it has a bunch of dependencies around Kube clusters, so you can't just helm install istio every time there's a new release.
replies(1): >>42136110 #
8. cyberpunk ◴[14 Nov 24 13:50 UTC] No.42136110{7}[source]▶
That’s not my experience at all and I’ve run hundreds of clusters across multiple cloud providers and on bare metal.

You absolutely can helm upgrade istio, why not?

Can you give any actual examples of this?