[chef] Re: Re: Chef12: knife user show to non-admin users

[Steven Danna < >]

Hi Tiago,

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:

    mary > knife raw -s 'https://api.opscode.piab/' 'users/mary/_acl' | jq 
.read
    {
      "actors": [
        "pivotal",
        "mary"
      ],
      "groups": [
        "acme_global_admins"
      ]
    }

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.

Now, knowing this, to give your users access to read each others' keys
you might try:

1) Adding the users group to the acme_global_admins group
2) Adding a given user to the "actors" section of the user's read ace
3) 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:
https://gist.github.com/stevendanna/1eb99f01a2f0f22ba619

You can use it like this from your Chef Server:

./danger_add_users_to_global_admins_group acme

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.