weaveworks
Question: Do we need to have TLS on Core?
While doing https://github.com/weaveworks/weave-gitops/issues/1959, it was pointed out to me that:
we expect --insecure to pretty much always be set for security reasons: you'll have a separate ingress to encrypt the data, so you don't need to worry about how to configure allowed ciphers, special-case certificate renewal, and so on. That doesn't mean anything will be transmitted without encryption.
And I asked:
In that case, why do we offer TLS at all?
To which I got a 🤷 .
So... why?
Acceptance Criteria
@JamWils will update with inverting the behavior so "certificates" are not required by default. A modern platform would secure this via load balancers and ingress policies.
it feels like the k8s dashboard arguments is probably not a terrible place to look for inspiration.
Looks like they have --insecure-port (default 9090) and --insecure-binding (default 127.0.0.1) and then additionally TLS arguments that can be set (e.g. --tls-cert-file etc.).
Their recommended deployment creates some empty secrets for TLS certs and mounts them but (as far as I can see) doesn't actually configure the deployment to use them (by default it's accessed via http) but it seems they do some cert generation themselves @ boot time?
tl;dr I don't think it's unreasonable to do tls on core but I think we should default to http as the dashboard does because, certainly for demo/getting started that's how people will use it.
I think most of the cases we don't need TLS (most likely, it will be used behind an nginx/traefik/caddy ingress controler with tls), but enterprise should be able to handle that as some of the security compliances have full end-to-end encryption requirement and it included in-cluster communication too (FIPS, HIPA), so it's not enough to terminate the TLS connection on a load balancer and call backend without TLS.
Question:
- Do we want to provide that functionality in core?
- Is it something enterprise can implement and maintain or it's easier to manage them in core?
Using internal TLS is there, but not documented; and it is not "on" by default which is correct. Closing for now.
