For normal service-to-service communication, it makes sense to directly define the services you expect to talk to and letting Consul Connect (Service Mesh) handle the details. But there are cases where you want a central set of servers (Bastion hosts) that should be able to talk to most, if not all, services (e.g. troubleshooting services via API calls). These would be servers with elevated permission used by a select group of people, also with elevated permissions. Curious if this is possible with Service Mesh as it is now, and with or without being managed by Nomad (or other orchestration system)?
I suppose you could script up "consul connect proxy -sidecar-for " calls on server startup, but that doesn’t seem ideal. Also have to make sure it is refreshed when new services are added, etc.
If this is currently not supported, is it in the pipeline?
Welcome to the Discuss forums! This is a really interesting question, and one that has come up often enough to warrant a different solution. Have you looked at Boundary?
Traditional approaches like SSH bastion hosts or VPNs require distributing and managing credentials, configuring network controls like firewalls, and exposing the private network. Boundary provides a secure way to access hosts and critical systems without having to manage credentials or expose your network, and is entirely open source.
I would recommend checking out the repo, as well as the category here on our forums. We announced this open source project earlier this year, and recently hit release 0.1.7. We would love feedback on your experience, both on GitHub and Discuss!
@jsosulska, I have briefly look at Boundary and it is interesting. However, my question is more around having a central set of control servers that should have access to all other services (notably their APIs). However, at least per the countdash demo job used to demonstrate Nomad and Consul Connect integration, the idea is the have the API only accessible via the proxy so there is no direct address (IP and port) available. This makes sense for service-to-service connections, but there could valid reasons to hit an API (toubleshooting, scripts, etc) that can’t easily leverage Consul Connect. And opening the service to be accessible directly kind of negates the purpose of the Service Mesh since some communication will be encrypted and some won’t be. Mapping services to unique ports (albeit, internally to their namespaces) and accessing them via localhost (that gets routed via the proxy) would work, but not sure how you would set that up so that in one go without doing the aforementioned scripting of “consul connect proxy -sidecar-for” solution, which definitely isn’t ideal.
Is this suppose to be something that Boundary resolves? And if so, is there a page you can reference that helps highlight that?
@jsosulska, actually, I managed to find this page, that helps fill in this feature gap. It is more elegant than scripting up mass sidecar proxies, but would be great to have a way to create a privileged proxy connection that could access all upstream services via localhost and their registered service ports.
@jsosulska, just for clarity, the question is more around having a one-to-many privileged proxy. Whereas I omit the target service or, perhaps via filters, enabled multiple services and intentions could be used to control what downstream services are accessible. This would provide more flexibility, especially if you don’t know the downstream services upfront and want to be able to support newer ones later without changing the proxy. This way intentions handle that mapping in a sense. The last page shows how to create ad hoc “operator” connections, which could be useful for one-off investigations and debugging, but would have be set up for each instance.
Is it possible to submit this somewhere as a feature request to get reviewed?