TLS verification of backend services #852
Conversation
Signed-off-by: Robbie McMichael <[email protected]>
Signed-off-by: Robbie McMichael <[email protected]>
Signed-off-by: Robbie McMichael <[email protected]>
robbiemcmichael
force-pushed
the
tls-verification
branch
from
b86fbf5 to
df1647d
Compare
|
Updated my branch to remove some modifications to the deployment YAML file that were used for testing and accidentally left in as well as to add sign-offs to all commit messages. |
Signed-off-by: Robbie McMichael <[email protected]>
robbiemcmichael
force-pushed
the
tls-verification
branch
from
df1647d to
b7be449
Compare
There was a problem hiding this comment.
Thank you for this change. Apart from the unrelated cleanups in the PR, I would prefer to not merge this until a discussion on the implementation via #813 is complete.
I'm sorry that it has taken so long to reply, we're a very small team.
| v.clusters[c.Name] = c | ||
| } | ||
| case *dag.TCPService: | ||
| case dag.Service: |
There was a problem hiding this comment.
This is good cleanup, but unrelated to this change. Can you please send it as its own PR. Thank you.
There was a problem hiding this comment.
It wasn't completely unrelated to this PR, I had to change Clustername to take a Service as a parameter since the hash needed to include fields that are only present in an HTTPService.
The cleanup here was made possible as a byproduct of changing that function, but I can still split those parts out into a separate PR if you'd like.
|
Thank you for working on this. I'm sorry that it took so long to resolve and that we ended up duplicating some of your work. I'm going to close this as a duplicate of #1045 |
@davecheney It was good to meet you at the YOW! Conference. I briefly talked to you about implementing TLS verification for backend services; I finally got around to finishing off a sample implementation which verifies both the CA and hostname of the certificate.
This PR addresses issue #813. The implementation is similar to the design I suggested in that issue, however the ingress route schema has changed slightly to accommodate hostname verification. The question I had around the granularity of specifying the TLS verification settings (i.e. should it be one per ingress route, route or service?) is still my main concern and it would be good to get your thoughts. I'm happy to rework this PR based on any design concerns or code review comments.