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.

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

Discovery based on IP addresses #2270

Open
grampelberg opened this issue Feb 12, 2019 · 6 comments

Comments

@grampelberg
Copy link
Member

commented Feb 12, 2019

What problem are you trying to solve?

For outgoing connections, service names are not always used. Prometheus, for example, uses IP addresses to scrape the metrics. This isn't an issue for load balancing, but it is important for TLS and service profiles.

How should the problem be solved?

Associate TLS and service profiles to outgoing requests that are IP address based as well as DNS based.

@olix0r

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

To be clear: this is scoped to supporting enriched discovery (i.e. route & endpoint metadata) for HTTP requests when the :authority is numeric or when a :authority/Host is omitted (and we only have an SO_ORIGINAL_DST address).

What is the desired behavior for endpoint discovery when an IP address refers to a kubernetes load balancer IP? Should the proxy discover each individual endpoint in the service? Or should it use the LB IP and let kube proxy do the heavy lifting? My preference would be the former, I think.

@olix0r

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

Currently the proxy is configured to only perform endpoint/route discovery for a whitelisted set of domain suffixes. How do we restrict the set of IPs that a proxy does discovery for?

My initial proposal is that the proxy be configured with subnets that are managed by Kubernetes. Is it possible to discover this configuration via the Kubernetes API or does this need to be configured with control plane installation?

Also, @grampelberg, how do you expect this to work with IP addresses? I think that profile discovery should not be enabled by default for IP addresses. We could potentially devise something to work with kubernetes-managed networks (maybe), but we cannot support IP based profiles for services outside the cluster, as there is no reliable to map an IP address to a canonical, logical service name. What is the use case for profile discovery based on IP address?

@grampelberg

This comment has been minimized.

Copy link
Member Author

commented Feb 12, 2019

What is the desired behavior for endpoint discovery when an IP address refers to a kubernetes load balancer IP? Should the proxy discover each individual endpoint in the service? Or should it use the LB IP and let kube proxy do the heavy lifting? My preference would be the former, I think.

I like letting kube-proxy do the heavy lifting, but what are the implications on identity at that point?

we cannot support IP based profiles for services outside the cluster, as there is no reliable to map an IP address to a canonical, logical service name.

It'd be possible to do a reverse DNS lookup, right? Though, the name would be unlikely to match up and probably not worth supporting anyways.

What is the use case for profile discovery based on IP address?

I'm assuming that policy will hang off profiles, but maybe that's a server concern and this is specific to the clients?

It'd be beneficial for per-route metrics when using an IP on services that are headless or use IPs to communicate primarily. Feels like it is firmly in the nice to have category until there's a serious ask for it. There are implications on the debugging/diagnosis side though (why can't I see metrics?).

@olix0r

This comment has been minimized.

Copy link
Member

commented Feb 12, 2019

It'd be possible to do a reverse DNS lookup, right? Though, the name would be unlikely to match up and probably not worth supporting anyways.

Even if we could, this is extremely fragile due to virtual hosting (i.e. especially when talking to CDN-terminated services). I think we're going to have to have a degraded experience when we can't know a name for a service.

I think we should limit the scope of this issue to endpoint metadata (i.e. TLS) and not arbitrary policy, until we have a clearer story around how this policy is associated/owned/etc.

@stale

This comment has been minimized.

Copy link

commented May 13, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label May 13, 2019

@hawkw

This comment has been minimized.

Copy link
Member

commented May 13, 2019

Should this be pinned?

@stale stale bot removed the wontfix label May 13, 2019

@klingerf klingerf added the rfc label Jun 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.