-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Connect: Expose HTTP health checks #5396
Labels
theme/connect
Anything related to Consul Connect, Service Mesh, Side Car Proxies
type/enhancement
Proposed improvement or new feature
Milestone
Comments
4 tasks
freddygv
added a commit
that referenced
this issue
Sep 26, 2019
Fixes: #5396 This PR adds a proxy configuration stanza called expose. These flags register listeners in Connect sidecar proxies to allow requests to specific HTTP paths from outside of the node. This allows services to protect themselves by only listening on the loopback interface, while still accepting traffic from non Connect-enabled services. Under expose there is a boolean checks flag that would automatically expose all registered HTTP and gRPC check paths. This stanza also accepts a paths list to expose individual paths. The primary use case for this functionality would be to expose paths for third parties like Prometheus or the kubelet. Listeners for requests to exposed paths are be configured dynamically at run time. Any time a proxy, or check can be registered, a listener can also be created. In this initial implementation requests to these paths are not authenticated/encrypted.
freddygv
added a commit
that referenced
this issue
Sep 27, 2019
Fixes: #5396 This PR adds a proxy configuration stanza called expose. These flags register listeners in Connect sidecar proxies to allow requests to specific HTTP paths from outside of the node. This allows services to protect themselves by only listening on the loopback interface, while still accepting traffic from non Connect-enabled services. Under expose there is a boolean checks flag that would automatically expose all registered HTTP and gRPC check paths. This stanza also accepts a paths list to expose individual paths. The primary use case for this functionality would be to expose paths for third parties like Prometheus or the kubelet. Listeners for requests to exposed paths are be configured dynamically at run time. Any time a proxy, or check can be registered, a listener can also be created. In this initial implementation requests to these paths are not authenticated/encrypted.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
theme/connect
Anything related to Consul Connect, Service Mesh, Side Car Proxies
type/enhancement
Proposed improvement or new feature
Currently we recommend that apps that use a Connect proxy should protect themselves from clients bypassing the proxy by only listening on localhost.
On a VM-based setup where the Consul agent and application are on same host and share a network namespace this works fine. The app can register TCP/HTTP health checks and agent can perform them locally even though the app instance is not exposed to the network.
In Kubernetes where we run agents in a separate pod and they can only talk to the application pod via it's public IP, there is currently no way to have the app register network-based health checks with Consul and protect itself by listening only on loopback within the pod.
By extension, for applications that specify Kube liveness/readyness checks, these stop working once they stop listening publicly on the Pod IP and the same issue occurs for the Kubelet.
It's possible to work around this now if you can modify your app or manually configure the proxy in some way to expose only the health check endpoint but this is not obvious or easy to do.
We should do something like:
Note that we will likely need to setup a similar listener anyway for exposing Prometheus metrics publicly from Envoy (proxying to the insecure internal admin interface on loopback).
Another potential option would be if we can configure Envoy to perform the active health check itself on the local app instance and then just have a simple TCP check to the public port. This would only work if Envoy rejects new connections when it has no healthy backend instances which I think is true but would need validating. It also requires that any network check possible in Consul or kube needs to be supported by active health checks in Envoy too but I thing that is the case.
The text was updated successfully, but these errors were encountered: