Thanks!!

The problem is: knife-vault needs to get public key of the users to
generate the hash.

If the guy is a non-admin, he only can generate for his own, and I can’t
see the key:

$ knife vault show reliability portability-credentials
ERROR: ChefVault::Exceptions::SecretDecryption:
reliability/portability-credentials is not encrypted with your public key.
Contact an administrator of the vault item to encrypt for you!

And the guy who did, can’t generate to me because the can’t see my private
key using ‘knife user show tiago_cruz’

Thanks!!

The short story is that this may be impossible without talking
directly to the internal SQL database and/or the bifrost (internal
authorization system) API. I’ve explained a bit below. The
explanation may be a bit terse for those on the list who haven’t used
the RBAC system much.

To read a user’s private key, you need to have the read permission on
the user itself either by being directly in the read ACE for that user
object or in a group that is in the read ACE. Adding your
vault-admins group to the read ACE of the users group won’t provide
the permissions you need since it doesn’t give you any permission on
the members of that group, simply on the group object itself.

The read ACE for a user Mary in the organization acme looks like this:

When Mary is associated to an organization, a special group is added
to the READ ace of the user. The group is in the form of
ORGNAME_global_admin and contains the admin group of the organization.
When she is disassociated from the org, that group is removed from her
read ACE. Since the admin users are in the admin group, the admin
group is in the acme_global_admins group, and the acme_global_admins
is in the read ACE of the user, an admin user can read Mary’s user
object.

Adding some arbitrary other group that contains the users to the
groups section of the users read ace

Unfortunately,

a) It appears Chef 12 has a bug such that you can’t update a user’s
acl without removing the ORGNAME_global_admin group from the ACL.
This would break the access that org admins have by default and would
put you in a situation that isn’t likely well tested. [0]

b) You can’t add actors or groups to the ORGNAME_global_admin group
because that group doesn’t exist inside an organization and thus
simply isn’t reachable via an API endpoint.

Option (1) above is likely doable with a script that directly
manipulates some of the backend services [1].

I hope this help.

Cheers,

Steven

[0] Updating user ACLs worked in 11.2.x so I’ll likely be following up
internally and filing a bug.
[1] By likely doable, I mean completely doable:gist.github.com

HOWEVER, please note that (1) this is messing with internal
implemntation details and it will probably break, (2) I haven’t
audited what other permissions those users will get, and (3) I haven’t
audited edge cases of users being associated and disassociated from
orgs. Basically I ran it once and it worked.

The short story is that this may be impossible without talking
directly to the internal SQL database and/or the bifrost (internal
authorization system) API. I’ve explained a bit below. The
explanation may be a bit terse for those on the list who haven’t used
the RBAC system much.

To read a user’s private key, you need to have the read permission on
the user itself either by being directly in the read ACE for that user
object or in a group that is in the read ACE. Adding your
vault-admins group to the read ACE of the users group won’t provide
the permissions you need since it doesn’t give you any permission on
the members of that group, simply on the group object itself.

The read ACE for a user Mary in the organization acme looks like this:

When Mary is associated to an organization, a special group is added
to the READ ace of the user. The group is in the form of
ORGNAME_global_admin and contains the admin group of the organization.
When she is disassociated from the org, that group is removed from her
read ACE. Since the admin users are in the admin group, the admin
group is in the acme_global_admins group, and the acme_global_admins
is in the read ACE of the user, an admin user can read Mary’s user
object.

Adding some arbitrary other group that contains the users to the
groups section of the users read ace

Unfortunately,

a) It appears Chef 12 has a bug such that you can’t update a user’s
acl without removing the ORGNAME_global_admin group from the ACL.
This would break the access that org admins have by default and would
put you in a situation that isn’t likely well tested. [0]

b) You can’t add actors or groups to the ORGNAME_global_admin group
because that group doesn’t exist inside an organization and thus
simply isn’t reachable via an API endpoint.

Option (1) above is likely doable with a script that directly
manipulates some of the backend services [1].

HOWEVER, please note that (1) this is messing with internal
implemntation details and it will probably break, (2) I haven’t
audited what other permissions those users will get, and (3) I haven’t
audited edge cases of users being associated and disassociated from
orgs. Basically I ran it once and it worked.

Just to clarify: The group ‘acme_global_admins’ has the same privileges than
the ‘admin’ default group?

No, apologies if this was unclear. The ORGNAME_global_admins group,
as far as I know, only appears in the ACL of user’s who have been
associated to ORGNAME. It does not, by default, grant members any
other permissions. The admins group is a member of the
ORGNAME_global_admins group specifically for the purpose of getting
permission on the global user objects for members of the org. Perhaps
this will help:

ORGNAME_global_admins group --has–> Permission on user objects

admin --has–> permission on many local organization objects
–is a member of --> ORGNAME_global_admins group

Because if I just put the user in admin group, the ‘knife user show’ works,
and so he is able to use ‘knife vault’ using the option:

Correct, if you put a user in the admin group, they will be able to
see the keys of all other users in that org by virtue of the fact that
the admin group in ORGNAME is a member of the special
ORGNAME_global_admins group. Of course, any user in the admin group
gets the permissions associated with the admin group.