cloudfoundry / cloudfoundry/cf-deployment
TLS for everything
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 315
- Forks
- 315
- Avg merge
- 7d 9h
- Merged PRs (30d)
- 5
Description
What is this issue about?
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?
- 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?
- metrics-discovery-registrar-windows - not using nats-tls hostname, falling back to 4222. We have pull request in for this one already (https://github.com/cloudfoundry/metrics-discovery-release/pull/6)
- route_registrar - not using nats-tls
- gorouter - not using nats-tls
What version of cf-deployment are you using?
[cf-deployment v13.19.0]
Tag your pair, your PM, and/or team!
@amhuber
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the cf-deployment v13.19.0 configuration for routing-api, metrics-discovery-registrar-windows, route_registrar, and gorouter, starting with the linked metrics-discovery-release pull request. Check why HTTP or non-TLS NATS endpoints remain enabled or selected, and confirm whether all four paths use TLS or have a documented reason not to.
Written by the indexing model from the issue text.
Assessment
- Domain
- infrastructure, networking, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100