Add internal route(s) as SANs on instance identity certificates

[bengerman13]

Add internal route(s) as SANs on instance identity certificates

Summary

In order to allow our users to leverage instance identity certs for TLS on internal networking communications, we want the certificates to include internal routes, if any, as Subject Alternative Names

Diego repo

https://github.com/cloudfoundry/executor
https://github.com/cloudfoundry/rep

Describe alternatives you've considered (optional)

We've also considered recommending our users do one of:

• manage their own instance certificates out-of-band
• leverage identity certificates, but ignore name mismatch
• look up IPs of target containers, then make their requests by IP so they don't get a name mismatch

None of these seem like great options for our users - we're looking for an easier lift for them that maintains identity assertions.

Additional Text Output, Screenshots, or contextual information (optional)

I think I've figured our approximately how to implement this, so our team could potentially help with/take on this work if there's community appetite for it.
My implementation sketch looks like this (this is my first time looking at this codebase, though, so apologies if I'm way off-base):

• add SANs to runInfo.CertificateProperties
• extract SANs in CredManager::generateCreds
• add SANs to createCertificateTemplate

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. Unfortunately, the Pivotal Tracker project is private so you may be unable to view the contents of the story.

The labels on this github issue will be updated when the story is started.

[pburkholder]

@ameowlia Does having this in "Issue Inbox" mean it could be addressed soon? 🙏

[ameowlia]

👋 Hello @pburkholder,

🎉 I get to deliver good news! Yes! We are working on this. I assigned @mariash to this issue to give you more information.

[mariash]

We are working on a solution to have an additional listener in Envoy on port 61443 that proxies to port 8080 inside of container. Listener will terminate the TLS and certificate will contain the SANs with all application internal routes. We don't want to use the same listener on port 61001 that is used by Gorouter because Envoy can be configured to validate client certificate from Gorouter and that is not going to work with C2C. As a first iteration whenever map-route command adds a new route application will need to be restarted to pick up the new certificate.

[mogul]

It looks like this may have made it out in the most recent Diego release (v2.55.0)... Is that so? If so, can we get a summary here and see this closed?

[mariash]

@mogul this feature consists of multiple steps. v2.55.0 exposes port 61443 on Envoy for C2C. It will terminate TLS using certificate that is valid for application internal routes. Implementation that is in v2.55.0 requires application restart after the map-route command is run. We are working now on update where application restart won't be needed and C2C certificate will be regenerated for running application when the the internal route is added/removed.

[folksgl]

Is the implementation as it stands in 2.55.0 going to be forward-compatible with additional changes that @mariash mentioned? Essentially -- if our team starts setting up apps to communicate using 61443 instead of the $PORT variable that applications are binding to, will we wish we had waited a few more Diego releases to start taking advantage of the new SANs being added?