Hi,
configured your terraform infra for boundary server. Created Core infrastructure and Backed RDP\servers targets. Im trying yo connect via “Boundary Desktop” client with user jeff that has admin role (created via terraform) and grant:
What am I missing on this configuration? why I can see that only with default admin user that has global permissions?
The grant needed on a target to allow a user to connect with it is authorize-session. You’ll need to add that in order to connect.
Looks like that role is at the org level. Targets live in projects, so unless you’ve set the grant scope ID to whatever project contains the target, it won’t apply permissions to that project.
I’ve figured this out, scroll to post #9 for spoilers
This just tripped me up too and I can confirm it’s role scoping that is stopping jeff. I added a new user to the Administration role of an Engineering org I created and couldn’t get any targets to appear. They only did so when I selected a specific project from that org.
More generally though, this seems like a confusing piece of design. I’d love some confirmation or otherwise on the following, because it looks like:
admin user in dev mode gets access to everything (including authorize-session in all orgs) because they exist at the Global scope level and have a ...*...*...* grant at the Global level.Org level with a ...*...*...* grant at the Org level won’t see any targets, because despite what the UI suggests, a Project isn’t really a sub-scope of an Org.Grant Scope dropdown looks very much like selecting Engineering would mean the grant applies to all of Production, Staging and DevOps.OK, I’m super confused. I added the pre-generated user to both Administration at the Global level and the auto-generated Administration of a new Org called Support (it’s at the Support org level). admin can see all the targets in Support, but user can’t see any.
Is there a third place admin is getting permissions to see Targets? If anyone else wants to try this and see what happens, that would be awesome.
The Global Administration role
The Support Administration role
admin’s available targets
user’s available targets
I figured out what got me twisted, and I’m leaving the above in case anyone comes across the same thing. It was the TF provider auto_create_admin_role and the permissions table in the docs that tipped me off.
Yes grants for targets are very much on the single project scope only, what confused me was seeing a Roles menu in both Global and any Org I made, but not any Project's that were made. But, if you build the URL in the same way as the other Roles pages, you can access it (and presumably via the CLI too).
This page not being visible had me assuming that grants at an Org would be inherited by a Project because otherwise how else was the Org level Administration role working? 
First I went here to find the roles for the project
http://localhost:9200/scopes/{Project ID}/roles
Clicking Administration didn’t work from there, but you can copy the Role ID and go direct to
http://localhost:9200/scopes/{Project ID}/roles/{Role ID}/principals
And I found that the admin user was a principal, but of course user was not - hence not seeing any targets.
Sounds like the same thing @BrandonALXEllisSS posted about?
Glad you sorted it out! Yeah, it can be a bit tough to follow at first, but just remember that a role always coneys grants in only one scope…either the scope of the role, or one of its children, but it’s not inherited. It may seem like it’d be easier if it was inherited, but we gamed it out a lot early on and it really becomes significantly harder to reason about the final set of permissions if it inherits and then you need to be able to deny inheritance. So once your deployment gets complex enough I think you’ll be glad it works how it does 
Haha!! We’ll all get there in the end 
Yes, this does make sense. Thanks for confirming 
Hi Guys, I have 2 projects called core_infra(created with AWS terraform deployment) and another one I have created manually called intosite under one scope called organization:
under intosite i have 2 targets for 2 “environment”
I have created simple role under organization scope level called “intosite-ssh” and grant scope to intosite project:
I used what DirectRoot talked about go direct to http://localhost:9200/scopes/{Project ID}/roles and http://localhost:9200/scopes/{Project ID}/roles/{Role ID}/principals to look if the project intosite gets the role and notice that it is not inherited as you talked here before. I have created manually role called “test” (under intosite roles):
Then went to principals to add them (with test roleid/principals):
(I can only edit the grants successfully but not adding principals)
My question is why it is not visible in the global organization after accessing the project? why do I need to use the URL itself? and there is a way to fix the add principals I have mentioned?
Antoher issue is when I try to use Permissions | Boundary by HashiCorp for configuring permission for specific target id:
with type it doesn’t let me do that only with some other specific id for example host-catalog:
id=hcst_1234567890;type=host-catalog;actions=create,read,update
last question regarding users deployment via terraform. there is no global admin that should created like it was on -dev deployments? maybe I need to configure some global admin user?
I honestly can’t tell from that output – can you get observability output from the console when accessing that page?
Take a look back at that page about pinning…in the screen shot you are trying to give permissions using id and type for a specific resource, and that isn’t an allowed format – use the id only. The reason it’s allowed for host catalogs is because host catalog is a top level collection type so it’s eligible for pinning, so when you’re setting ID there you’re actually setting the pin. We should maybe make that format disallowed when the type listed isn’t an eligible type…
