Connection permissions

Boundary
#1

Hey, I’m trying to allow connections to a host only if this host is in a specific host catalog.
For example: There is a host set local and a target localhost. Local is set as host source for the target localhost. Now, the user test should only be able to connect to the target localhost if the host set local is in the host catalog development.

I tried it with the pinned ID grant. This didn’t work.

id=;type=target;actions=authorize-session

Is there a way to implement this or something similar?
Thanks for your help

#2

Hmmm. I’m not sure if what you’re describing is something Boundary is really intended to support – hosts can belong to multiple host sets, and I suppose you could set up multiple dynamic catalogs that the same host could show up in different host sets of at different times, but what’s the use case?

But in any case, if you want a user to see and be able to use only a specific target, I think you can do that with the following permission grants on a role in each scope that contains that user as a principal:

grant_scope_id: global
grant_strings: [ "id=*;type=*;actions=read,list" ]

grant_scope_id: [organization ID]
grant_strings: [ "id=*;type=*;actions=read,list" ]

grant_scope_id: [project ID]
grant_strings: [ "type=target;actions=list","id=[target ID];actions=read,authorize-session" ]
1 Like
#3

I’m trying to implement our the current infrastructure in boundary. We have a bit more than two thousand hosts for different applications and in different environments (integration, production and others). Every developer should only be able to access his hosts and not the others.

For example: Application xyz has two hosts in integration and four in production. The developer should now only be able to access his two hosts in integration. The other hosts in integration shouldn’t be accessible.

It’s a bit complex, but hope you can understand the use case.

#4

I had this idea too, but our infrastructure is way too big. It would be a lot of effort to create a separate role for every host.

#5

I don’t think you need a different role for each host, but I do think the scenario outlined by the OP is best handled by different targets.

Maybe at some point we can allow more filtering in targets to act on specific values. But broadly speaking we try not to allow-then-deny. Boundary aims to be a true zero-trust system - it prefers to allow you to compose what you want to allow, rather than try to exclude permissions after the fact, as doing so can easily end up a process that is complicated and brittle.

1 Like
#6

For example: Application xyz has two hosts in integration and four in production. The developer should now only be able to access his two hosts in integration. The other hosts in integration shouldn’t be accessible.

I think you can do this with regular host sets. It’s even easier if you have your environments in a cloud with a supported dynamic host catalog plugin. Would something like this work?

Host Catalog Integration → Host set AppA-Int → Host AppA-[0, 1]
Host Catalog Prod → Host set AppA-Prod → Host AppA-[0, 1, 2, 3]

Target AppA-Integration → host set AppA-Int.
Target AppA-Prod → host set AppA-Prod.
Target AppA-All could exist and link to both of the above host sets.

You can assign the AppA developer(s) to a user/group that is part of a role that gives permission to only read and open sessions to the AppA-Integration target. If they need to access a specific host, they can connect on the CLI using the -host argument (they’ll need to enumerate the hosts in the host set to know the ID of the host they need, but that’s doable with some basic scripting).

#7

That’s a very good idea.
I’ll try it.
Thank you for your help. :slightly_smiling_face:

1 Like