Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add warning about ExternalName not working with TLS/HTTPS #16627

Closed
wants to merge 3 commits into from
Closed

Add warning about ExternalName not working with TLS/HTTPS #16627

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3bb12bf
Add warnings about ExternalName not working with TLS/HTTPS
jimmyjones2 Sep 30, 2019
53044e1
Updated ExternalName warning with @sftim suggested wording
jimmyjones2 Oct 5, 2019
2968b3f
Updated ExternalName warning with suggested wording from sftim
jimmyjones2 Oct 5, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions content/en/docs/concepts/services-networking/service.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -913,6 +913,9 @@ forwarding. Should you later decide to move your database into your cluster, you
can start its Pods, add appropriate selectors or endpoints, and change the
Service's `type`.

{{< warning >}}
ExternalName many not work with services protected with TLS SNI and/or HTTPS.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jimmyjones2 This doesn't feel like enough of an explanation (I had to go and read the previous issue).

  • I'm not sure that SNI or not is relevant. If the remote service uses TLS but not SNI, the client will still see a hostname mismatch when they connect to (eg) my-service.prod or my.service.prod.svc.cluster.local.
  • HTTPS might be useful in case readers haven't heard of TLS though.

How much is this different to the challenge with using TLS with a Service within your cluster? In both cases it feels like you need to make sure that the TLS server can provide a valid certificate and that if you don't the clients won't be happy.

It's a point worth making but it's also important to be clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sftim Absolutely, I agree it's not really an explanation. I can think of 3 issues:

  • Client: certificate CN/SAN won't match
  • Server: if using SNI to route traffic, it won't know where to send it
  • Server: with HTTP/HTTPS, the Host field will be wrong, so might not know which website to serve

I think the challenge is different to internal services. With internal services you can use the internal Kubernetes CA. For services outside the cluster, no public CA will sign certificates with internal cluster hostnames, so your only option is a corporate CA, but even then it's probably against policy as two clusters could have the same internal service name.

The other challenge is you may not control the external service, so are unable to encourage them to add support for the hostname you internally refer to it as. Even if you could, they might not even be able to help you due to the reasons above, and embedding internal cluster configuration into an external service seems nasty.

How about:

"ExternalName might not work for services using protocols such as as TLS or HTTP. These use the hostname to secure and/or route traffic and may not be expecting the internal cluster name"

{{< /warning >}}

{{< note >}}
This section is indebted to the [Kubernetes Tips - Part
Expand Down