Worker to target mapping?

Hi! I’ve been following this product for a few months now and after setting up a test instance, it looks quite promising – When this has Okta I’m going to deploy it nearly everywhere.

One thing I’ve noticed though is that there doesn’t seem to be any way to assign different workers to different targets, and nothing documented seems to hint at this being possible. Can’t understand why though – since if you have a fleet of workers spread out over different regions, clouds, etc it seems like it would greatly improve latency, as well as allowing fine tuned ACL setup for the workers. Is this a planned addition? Or possible now?

Bonus question: It seems like the only port I can currently connect to is the ‘default’ port. Can the client specify another one?

Hi @Timbus, thanks for the question and for the interest in Boundary!

On the Okta integration - this is coming soon! We are actively working on an OIDC authentication method that will be available in an upcoming release. For more information see our public roadmap.

For target mapping, we have a similar ask being tracked on this discuss thread and this github issue.

While it’s not in yet in our near-term roadmap, assigning targets to particular workers is very much in our vision for Boundary for the reasons you cited - improved latency and fine-tuned access controls to resources residing on private networks. Our team is actively discussing this but we still need to continue investigation before we can commit to a timeline publicly.

As for the bonus question - currently clients can only connect to a target’s default-port defined by an admin. As a work-around you could just create a separate target for each port that clients might use to connect.

Oh awesome, thanks for the very comprehensive information! The first discussion is exactly what I was thinking of, where as the git issue is… I guess tangentially related yeah.
I guess a workaround for now is one controller per region but that’s not too good for users, and kinda wonky to manage.
Good to know it’s a desired use case being considered though. Thanks again.