Automatic worker filter setup on targets. Multi-tenant architecture.

[angelbarrera92]

Is your feature request related to a problem? Please describe. We are setting up a multi-tenant boundary architecture. Each tenant (boundary organization) provides its private workers. These workers can only be used by that organization; so all targets in the projects inside the organization must have a filter configured.

Also, I think it could be an issue having workers configured with tags (all workers with tags), that are able to process connections to targets without any filter configured.

IMHO:

• If a target has no worker filters, any worker without tags should be able to process the connection.
• If a target has no worker filters, workers with tags should NOT be able to process the connection.
• If a target has worker filters, only matching workers should be able to process the connection.

Describe the solution you'd like Hooks, events, or any organization policies to enable targets to be configured with some worker filters on creation. https://www.boundaryproject.io/docs/concepts/filtering/worker-tags#target-worker-filtering

Describe alternatives you've considered I can create predefined targets for the tenants, but if the tenant admin creates new targets, the configuration is not propagated automatically (i can restrict tenant admin to create targets... ). I considered also running a database query/trigger, but I don't feel comfortable with this kind of solution.

Explain any additional use-cases This is something more people will find interesting while running multi-tenant boundary architectures.

Additional context Im available to talk about more issues like these.

[jefferai]

We have been thinking of adding a toggle that switches the default behavior for matching workers from "all workers match unless a filter is defined, then they must match the filter" to "no workers match unless they specifically match a filter". I think that would suffice for your needs?

It'd also possibly be interesting to allow further filtering to be configured at the org level to apply/filter out workers for all projects in the org.

Tagging in @PPacent on this as a feature request (at least for the former).

[angelbarrera92]

We have been thinking of adding a toggle that switches the default behavior for matching workers from "all workers match unless a filter is defined, then they must match the filter" to "no workers match unless they specifically match a filter". I think that would suffice for your needs?

Yes! This is something really interesting for multi-tenant setups. I don't want (or maybe is not possible because of network partitions) to access client-2 infra with a worker of the client-1 and the other way round.

It'd also possibly be interesting to allow further filtering to be configured at the org level to apply/filter out workers for all projects in the org.

Ye! I was thinking about it in a more generic way, maybe some kind of events or an admission webhook would be awesome. I mean, if I can "intercept" some requests (like post/create targets) I can modify the request adding information depending on the organization and/or project to which it belongs (like Kubernetes does with the admission webhooks). Or an event system that I can subscribe to with a "lambda" (webhook).

[springroll12]

We have been thinking of adding a toggle that switches the default behavior for matching workers from "all workers match unless a filter is defined, then they must match the filter" to "no workers match unless they specifically match a filter". I think that would suffice for your needs?

I think this is ideal for non-multitenant use cases as well. For instance if workers live in different VPCs and should only be used for certain targets. My understanding is that a tagging system is in place to allow associating workers with specific targets as of 0.1.5, but I think this suggestion would allow situations where controllers live in a central VPC, while workers live in the various "target" VPCs. (See this thread for details on the use case)

[sym-stiller]

This feature would be very interesting for my company as well. As described in the previous answer, we are running a set of controllers in a K8s cluster, and multiple sets of workers in different K8s clusters.

We allow our users to create new Boundary targets with the Boundary TF provider, and want to ensure that they can only create targets for hosts in their respective K8s cluster. This restriction is implemented with a Terraform OPA policy, a little bit of Boundary RBAC and worker filters based on tags. I'm sure that if any user looks close enough, they will find a loophole in my implementation because there is no way to restrict which user can connect to which worker in Boundary.

All of this would become much easier if we could either

• define policies on the scope/project/hostset level that whitelist and/or blacklist specific workers
• use Boundary RBAC to define which user can connect to which worker (or worker group)
• define a worker filter that automatically applies to all targets in a scope and can't be overwritten
• use OPA policies to grant or deny requests to the authorize-session API
• any combination of the above