toggle quoted messageShow quoted text
Glad to see this conversation happening. I've been involved in several conversations about this over the years but I'm not sure what public artifacts exist about these efforts. Historically, it has been a challenge to organize so-called "cross-cutting efforts"
that require the involvement of many different teams and it may be especially challenging now that much of the community has shifted its focus to developing cf-for-k8s.
That said, here's a thought: perhaps we can approach this feature request and other "cross-cutting" features for cf-for-vms with the following strategy going forward:
- Create an issue to track this feature of cf-for-vms in the cf-deployment github repo
- While it's good to continue discussing this anywhere and everywhere (Slack, email, etc), let's make that that Github issue the canonical home for discussion about this going forward and try to "close the loop" back there if discussions are had elsewhere.
- If separate issues can be carved out for specific components, create issues on their repositories and link them back to the Github issue on cf-deployment.
Github's auto-linking between issues should help us make these more discoverable, regardless of which direction the link is going.
Jon, would you like to do the honors as the thread starter here?
From: cf-dev@... <cf-dev@...> on behalf of Miki Mokrysz via lists.cloudfoundry.org <miki.mokrysz=digital.cabinet-office.gov.uk@...>
Sent: Tuesday, September 15, 2020 11:41 AM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] TLS for everything
+1 on desiring everything to be encrypted on the network.
We’re under the impression that Silk (apps.internal) traffic between cells is also unencrypted.
On Tuesday, 15 September 2020, Peter Burkholder via
We may run into similar requirements for
, so TLS everywhere would be A+.
There has been a lot of excellent progress in securing all CF traffic with TLS and as far as I can tell there are only a few things that are still unencrypted.
Is there a timeline or any plans for these last few things?
1) routing-api - still using both TLS and non-TLS in the cf-deployment. The http endpoint is what is registered in the router. Is there a reason for still enabling both?
2) metrics-discovery-registrar-windows - not using nats-tls hostname, falling back to 4222
3) route_registrar - not using nats-tls
4) gorouter - not using nats-tls
We have a requirement that all traffic on the network is encrypted and I would really love to stop running IPsec. :)
Peter Burkholder | cloud.gov
compliance & security