capability delegation

[jmls]

Is there any capability to delegate the creation of policies ?

As an example, let's say that I have the following secret paths

/secrets/data/divisionA/IT
/secrets/data/divisionA/Sales

/secrets/data/divisionB/

and I want users in division A to be able to only create secrets in /secrets/data/divisionA/a/b/c/d/ and set permissions on who can read / write delete those secrets.

At the moment, it seems that only the admin (or user with policy permissions) can create the capabilities on the specified paths. However, if you have this capability of creating policies, don't you then have permissions to create a policy for any path ?

ie without granting full policy access to a user, they cannot create policies on their own paths

I suppose what I'm looking for is the ability to set capabilities for the maintenance of policies on a certain path

Am I explaining this properly ? Has anyone else had a similar scenario and come up with a solution ?

[cipherboy]

@jmls Pardon for the short reply, I'm currently debugging something...

I think this is what namespaces are for in Vault Enterprise (not present in OpenBao): admins can create namespaces and delegate permissions to create policies within the namespace. Then users within the namespace cannot grant permissions outside of that namespace, even to themselves.

In general, yes, it is a high privileged operation though. I don't think there's any way to restrict it, within OpenBao at the moment.

[jmls]

ah, poo ;)

Any plans on implementing something similar ? Would be a killer feature ;)

[jmls]

I wonder how hard would it be to create a plugin that can act as a wrapper around policy maintenance that has to be given a token on startup that has permissions to read / write policies , but checks the paths of the policies in question against the capabilities of the user token and creates / maintains the policies on behalf of the user

If the user tries to access the polices directly they are denied - they have to go through the "namespace" plugin

so "normal" policy owner would assign capabilities to users/groups for /policycheck/some_path

the plugin then checks for /policycheck/some_path permissions on behalf of the user token, if they have rights then uses the plugin token to actually perform the required tasks on some_path

[jmls]

"how hard" ... this from a non-go coder :)

[cipherboy]

Ah, I was going to suggest you open a PR for Namespaces. ;-) A feature request will do instead, I can expand it into a RFC later if nobody else gets to it. I will probably not be the one to write the feature, though.

This idea of a plugin is rather hard. Plugins do not have access to the privileged Core (that maintains the policies) and thus great, great care would need to be taken to expose enough of Core to allow this. Likely some other mechanism would be more ideal (e.g., allowing a special delegated-policy creation).

However, note that this alone isn't enough: now that I'm thinking about this, there's two points of privilege.

One is yes, as identified, policy creation.

The other is "login info" creation, where any policy can be chosen: see e.g., here: token_policies can be arbitrarily chosen by whomever has write access to /auth/userpass/users/:username. So, simply restricting policy creation isn't enough, you also have to restrict policy selection across a wide variety of (auth-plugin specific) paths. This is, again, hard, without namespaces to allow some natural limitations.

[jmls]

wait, what ... now that you say it, I can see it - I suppose my brain never considered it because that's so ... dumb ...

A user with update capabilities to their own account can give themselves admin policies ? Any policy / capability they want ?

Isn't that just a potential huge security problem ?

I would have thought that assigning policies to an user would always have to have it's own policy !

[cipherboy]

In general, I think entity control in particular was expected to be privileged as it controls billing for upstream's Enterprise offering. Technically user control does as well, but it's more complicated. :-)

[jmls]

Looking at it, even the actual entity has the same problem

/identity/entity/name/:name haws the same issue

https://openbao.org/api-docs/secret/identity/entity/

[jmls]

ah, hold on. Can't parameters play a part here ?

path "auth/userpass/users/*" {
  capabilities = ["update"]
  denied_parameters = {
    "token_policies" = []
    "policies" = []
  }
}

[cipherboy]

Right, but parameters are defined in policies. So you can restrict a user from specifying policies if you grant them update permission to their account (I wouldn't, I still maintain that's a privileged operation either way)... But if you grant them policy granting permissions, they can either overwrite their own policy, or grant someone else permission to modify their own account+permission to modify policies. I think the latter requires two accounts to pull off (if you restrict the ability to modify your own policies by ACLing), but still :-)

I think I'm rather comfortable saying both account modification and policy control are definitely administrative, privileged operations. My 2c?

[cipherboy]

You could also use allowed_parameters instead. Or if you were doing userpass and wanted them to change their password, https://openbao.org/api-docs/auth/userpass/#update-password-on-user is an endpoint just for that.

[jmls]

damn, that namespace feature is more and more compelling ;)

[cipherboy]

@jmls File the RFE on the issue tracker and I'll start thinking about it. :-)

[youcefnb]

was the RFC ever filed for this issue? I couldn't find it.

[cipherboy]

I don't believe so. If you wanted to start it, feel free!

[youcefnb]

What's the best way to do that?

[cipherboy]

@youcefnb I'd start a feature request issue on the main repository with general thoughts and requirements from your end. If you're interested in contributing to the design and/or development of the feature, I'd work through the RFC template... If you want to go the latter route, it might be good to build a draft version to share, perhaps via the mailing list or matrix server. :-)

[cipherboy]

I'm going to go ahead and close this: #486 was opened which should be the canonical place to discuss namespaces in the future and this has been added to our official roadmap: #569!

We're happy to work with anyone interested in adding this feature :-)