RBAC Permission Denied

Bug #1716007 reported by Bogdan Ratiu
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
New
Undecided
Bogdan Ratiu
OpenContrail
New
Undecided
Unassigned

Bug Description

Hi,

On a setup with 3 nodes (running Centos 7.3):
-Openstack node (Mitaka)
-Contrail config, controller, analytics node (Contrail 3.2.5)
-compute node
The Openstack was installed first, then Contrail was installed and provisioned using the fab tool.

Reproduce steps:
1. Enable RBAC authentication
2. Test RBAC authentication in the GUI:
   a. Create a Member role user named "test".
   b. In the GUI go to Configure->Infrastructure->RBAC(global) and assign *.* CRUD rights for Member role.
   c. Check in the CLI that everything is ok:
[root@contrail lib]# python /opt/contrail/utils/rbacutil.py --op read
AAA mode is rbac

Oper = read
Name = ['default-global-system-config', 'default-api-access-list']
UUID = None
API Server = 127.0.0.1:8082

Rules (8):
----------
 1 fqname-to-id *:CRUD,
 2 id-to-fqname *:CRUD,
 3 useragent-kv *:CRUD,
 4 documentation *:R,
 5 /.* *:R,
 6 *.* Member:R,
 7 / *:R,
 8 *.* Member:CRUD,

   d. In the GUI log in as the Member and try to create a simple virtual network.
      It will succeed.

Conclusion: Basic RBAC is working ok.

3. Attempt a bit more complicated test:
   In the GUI:
   a. Remove *.* CRUD rights from Member.
   b. Replace with:
      *.* R for Member
      virtual-networks,* CRUD for Member
      network-ipams,* CRUD for Member

Check the CLI:
[root@contrail lib]# python /opt/contrail/utils/rbacutil.py --op read
AAA mode is rbac

Oper = read
Name = ['default-global-system-config', 'default-api-access-list']
UUID = None
API Server = 127.0.0.1:8082

Rules (10):
----------
 1 fqname-to-id *:CRUD,
 2 id-to-fqname *:CRUD,
 3 useragent-kv *:CRUD,
 4 documentation *:R,
 5 /.* *:R,
 6 *.* Member:R,
 7 / *:R,
 8 *.* Member:R,
 9 virtual-networks.* Member:CRUD,
10 network-ipams.* Member:CRUD,

    c. Go back to the GUI and as the Member attempt to create a new virtual-network. It will fail!
       The error will be: Permission Denied. (see attachment).

Additional info:
I have enabled debugging and check in the contrail-api.log
In the first case when everything is ok, I can see a long list of RBAC checks being done:

09/08/2017 05:22:10 PM [contrail-api]: __default__ [SYS_NOTICE]: VncApiNotice: rbac: +++ (R:67b6047f-425a-459b-b0bc-853fc1f7269f) project ['default-domain', 'admin'] admin=no, mode=444 mask=707 perms=700, (usr=67b6047f425a459bb0bc853fc1f7269f(admin)/own=67b6047f425a459bb0bc853fc1f7269f/sh=[])
09/08/2017 05:22:14 PM [contrail-api]: __default__ [SYS_NOTICE]: VncApiNotice: rbac: +++ (W:67b6047f-425a-459b-b0bc-853fc1f7269f) project ['default-domain', 'admin'] admin=no, mode=222 mask=707 perms=700, (usr=67b6047f425a459bb0bc853fc1f7269f(admin)/own=67b6047f425a459bb0bc853fc1f7269f/sh=[])
09/08/2017 05:22:14 PM [contrail-api]: __default__ [SYS_NOTICE]: VncApiNotice: rbac: +++ (R:f4f89069-7aef-4c8c-8c71-8dd7728b1cd8) virtual_network ['default-domain', 'admin', 'sumi'] admin=no, mode=444 mask=707 perms=700, (usr=67b6047f425a459bb0bc853fc1f7269f(admin)/own=67b6047f425a459bb0bc853fc1f7269f/sh=[])

In the second case, I can only see one check and that check is also successful, but somehow the other checks are not done:

09/08/2017 05:12:41 PM [contrail-api]: __default__ [SYS_NOTICE]: VncApiNotice: rbac: +++ (R:67b6047f-425a-459b-b0bc-853fc1f7269f) project ['default-domain', 'admin'] admin=no, mode=444 mask=707 perms=700, (usr=67b6047f425a459bb0bc853fc1f7269f(admin)/own=67b6047f425a459bb0bc853fc1f7269f/sh=[])

Is this a known issue? I RBAC supposed to be used with such granularity?

Bottom line: *.* CRUD works for Member. Just specific rights will not be enough.
I suspected that there are some dependencies, so I went in the GUI and added all the items from the Object list one by one, added * for the Property and added CRUD for each one of them (more than 50 items).
Even after doing this I was still unable to create a new network as the Member user in the GUI.

Tags: openstack
Revision history for this message
Bogdan Ratiu (bratiu) wrote :
information type: Proprietary → Public
Revision history for this message
Bogdan Ratiu (bratiu) wrote :
Sachin Bansal (sbansal)
Changed in juniperopenstack:
assignee: nobody → Suresh Vinapamula (sureshk)
Revision history for this message
Suresh Vinapamula (sureshk) wrote :

After the bug fix https://bugs.launchpad.net/juniperopenstack/+bug/1699097, rules have to be configured against singular object type for individual object CRUD operations, and plural object if multiget is involved.

Changed in juniperopenstack:
assignee: Suresh Vinapamula (sureshk) → nobody
assignee: nobody → Bogdan Ratiu (bratiu)
Revision history for this message
Suresh Vinapamula (sureshk) wrote :

Hi Bogdan Ratiu,

Can you please validate if you are still seeing the issue after configuring rule against singular object type? In this case against virtual-network.

-Suresh

Revision history for this message
Bogdan Ratiu (bratiu) wrote :

Hi Suresh,

First of all thank you for the quick reply.
For reference I can not access the link at:
https://bugs.launchpad.net/juniperopenstack/+bug/1699097

Anyways, I have changed the rule from: <virtual-networks, *> to <virtual-network,*> and I can confirm that the creation of the virtual network is now working as expected.

But I still have 2 issues:
1. After setting rules like this:
AAA mode is rbac

Oper = read
Name = ['default-global-system-config', 'default-api-access-list']
UUID = None
API Server = 127.0.0.1:8082

Rules (6):
----------
 1 fqname-to-id *:CRUD,
 2 id-to-fqname *:CRUD,
 3 useragent-kv *:CRUD,
 4 documentation *:R,
 5 / *:R,
 6 virtual-network.* Member:CRUD, << this is the rule I added

As I said I can create, but I am not able to see the existing virtual-networks, or the ones I have already created.
So what is the other rules that I need to add so I can also see the existing virtual-networks in the GUI?

2. Still a bug: in the GUI when you want set the permissions, in the object drop down not all objects are present. In my case only the virtual-networks object is present, not the virtual-network one. So this is the main reason that I did not try to set CRUD permissions for virtual-network (I can set it by hand, but can not select it from the drop-down list)

So I guess that the drop down list should be updated to include all the configurable objects. Please see attachment.

For reference this is on the latest 3.2.5 release.

Again thank you and have a nice day.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.