Regular users do not have access to 'admin' ID when creating ACLs

Bug #1627391 reported by Stephen Balukoff on 2016-09-24
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Barbican
Triaged
Wishlist
Douglas Mendizábal

Bug Description

In order for a regular tenant to create an ACL granting access to a secret to the admin user, the tenant would run a command like the following:

openstack acl user add -u <user_id> <secret_href>

However, the <user_id> in the above command is the UUID of the user to which we'd like to grant access, and regular cloud users do not have access to the UUID of the admin user:

$ source ~/devstack/openrc demo demo
$ openstack user show admin
You are not authorized to perform the requested action: admin_required (HTTP 403) (Request-ID: req-fe4e0959-04dc-48f7-a483-d0e1e7111b35)
$ openstack user list
You are not authorized to perform the requested action: admin_required (HTTP 403) (Request-ID: req-10b4d620-5e8a-4b31-b13f-e48a34a81611)

This is problematic, since in order for 3rd party services to work (like neutron-lbaas and octavia), the user must grant access to secrets they upload to the 'admin' user or some service user.

Granted, any given cloud operator could make their specific admin UUID known to any users who need to use these third party services; However it really seems like this is unnecessary extra work we are forcing users and operators to go through: We should provide a simple means for a regular non-privileged user to grant access to secrets they create to 'admin' and 'service'-type users.

This bug report is related to this one: https://bugs.launchpad.net/barbican/+bug/1627389

Pankaj Khandar (pankaj-khandar) wrote :

admin have access to all resources, why do we need to explicitly give access to admin?

Stephen Balukoff (sbalukoff) wrote :

If admin is supposed to have access to all resources, then that's another bug that needs to be filed, because it doesn't.

Go ahead and try accessing a secret created by the demo user as the admin user without the demo user creating an ACL for the admin to access it.

Pankaj Khandar (pankaj-khandar) wrote :

I have a Demo user and then i have admin user who have key-manager:admin role on demo project .. and that admin user can list the secret saved/inserted by demo user.

Stephen Balukoff (sbalukoff) wrote :

Oh, so this doesn't happen for you? What am I doing differently?

stack@cairn:~$ source ~/devstack/openrc admin admin
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
stack@cairn:~$ openstack role add --project demo --user demo creator
WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils
+-----------+----------------------------------+
| Field | Value |
+-----------+----------------------------------+
| domain_id | None |
| id | 8da892bd0d06484bbb699c23dcb3353c |
| name | creator |
+-----------+----------------------------------+
stack@cairn:~$ source ~/devstack/openrc demo demo
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
stack@cairn:~$ openstack secret store --name='test_secret' --payload-content-type='text/plain' --payload="blahblahblah"
WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils
decoding Unicode is not supported
stack@cairn:~$ openstack secret list| awk '/ test_secret / {print $2}'
WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils
http://10.209.40.10:9311/v1/secrets/ba8fcfd9-9dc6-4d36-ae91-477fc7dc6891
stack@cairn:~$ openstack secret get -p http://10.209.40.10:9311/v1/secrets/ba8fcfd9-9dc6-4d36-ae91-477fc7dc6891
WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils
+---------+--------------+
| Field | Value |
+---------+--------------+
| Payload | blahblahblah |
+---------+--------------+
stack@cairn:~$ source ~/devstack/openrc admin admin
WARNING: setting legacy OS_TENANT_NAME to support cli tools.
stack@cairn:~$ openstack secret get -p http://10.209.40.10:9311/v1/secrets/ba8fcfd9-9dc6-4d36-ae91-477fc7dc6891
WARNING: openstackclient.common.utils is deprecated and will be removed after Jun 2017. Please use osc_lib.utils
4xx Client error: Forbidden: Secret payload retrieval attempt not allowed - please review your user/project privileges
Forbidden: Secret payload retrieval attempt not allowed - please review your user/project privileges

Dave McCowan (dave-mccowan) wrote :

The admin needs to be an admin in the same project as the user. In @Stephen's example, it's user "demo" of project "demo". The user "admin" of project "demo" would have access, but user "admin" of project "admin" would not.

Changed in barbican:
assignee: nobody → Douglas Mendizábal (dougmendizabal)
milestone: none → pike-1
status: New → Triaged
Michael Johnson (johnsom) wrote :

I think this bug is less important than the cascade ACL in bug 1592612
If we have the cascade ACL feature we can eliminate this requirement from user workflow in lbaas/octavia.

Dave McCowan (dave-mccowan) wrote :

This should be addressed by cascading ACLs. Closing this bug, and tracking under bug 1592612.

Changed in barbican:
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers