Hi,
I really like the simple and predictable permission model of Boundary with well-defined id, type and actions in the grant strings (that map perfectly to api resources). One thing that I miss though, is the possibility to reference credential-libraries in the type.
My use case is fairly simple: I have a database target (doesn’t really matter if it uses a static or dynamic host catalog) and I have connected multiple credential libraries from the same store (Vault). Let’s assume I have three access levels: viewer, editor, admin, each configured via a different Vault database role. Now I want to make sure that only people from a specific OIDC managed group have access to a certain credential library.
If I could grant access to the target and limit the access to a specific credential library, that would be much simpler than creating multiple targets, each with a single credential library, which is how I’m dealing with this issue now.
Any thoughts?
Strictly my opinion: It would be one model of doing what you’re currently doing with multiple targets, and to my mind it would be kind of like the way Boundary “plugs in” a host address at connect time – I think the main downsides of it would just be the change in the current access model of Boundary:
- The current mapping of credentials to targets keeps things simple and easy to understand – connecting to a given target will always use exactly the credential library configured for that target. The only question you need to answer to know what a given user can connect to and with what credentials given to them is “what targets do they have access to?”
- I think it would be a pretty big schema change in how Boundary does things under the hood.
- It raises some issues like “what does it mean for a user to have access to a target but be denied access to any configured credentials for it? What should Boundary do in such a case?” You could say something like “define a flag for whether connection proceeds with no credentials, or connection is denied altogether”, but now we’re meddling in the schema again and making things even more complicated.
(Not saying the idea is wrong, or that what Boundary currently does is objectively better, just different in a way that would take a lot of work to support at this point.)
Hi @omkensey, thanks for chiming in.
While I agree that the change may not be the easiest to make, I do feel it’s strange to put targets and roles (that’s essentially what credential libraries expose) in the same basket.
What I’m suggesting wouldn’t be a total redesign of the access model but a small targeted improvement. The way I see it, we could use something similar to output_fields just instead of filtering the json keys that are output, filter the values.
That way I could grant a principal authorize-session on all targets given the target contains a certain credential library in brokered_credential_source_ids or injected_application_credential_source_ids
So you’d still have multiple credential libraries, but they would all be statically attached to the target and then filtered down to what credentials the user is authorized for at connect time?
I guess so.
When you say statically attached, what would be a different way?
Basically the difference I’m envisioning is credentials that are unconditionally presented or injected by virtue of being defined as part of the target and the user attributes matching a credential filter, vs. credentials that are chosen dynamically by the user at authorization time in some fashion (e.g. “here are all the credentials you are allowed to use, which one(s) would you like to use for this connection?”).
I’m still not saying the former is a small amount of effort or fits in the roadmap, but I can see how it or something like it could potentially make an admin’s life easier and I think it’s worth a feature request.
Hi @omkensey, that’s what I thought. I’ll consider creating the feature request then.
As for the latter option, either I misunderstood you or it seems that this is already a possibility:
You can attach multiple credentials currently, but the user will be served all of them, with no filtering or opportunity to choose which are served.
Gotcha.
I guess this will be the natural direction of the product development.
The more secret stores and libraries you support, the greater the need to filter them out.
