CLI arguments for rbac create are misleading and possibly incorrect

[Danny Cocks]

On a yoga install of openstack, I can run the following command as user with member role in projectA which is in domain DOM:

  openstack network rbac create --target-project projectB --target-project-domain DOM --action access_as_shared --type security_group my-security-group

The user doesn't have any role for project projectB but can successfully create an rbac for it. However, when I see the fields of the rbac, I see:

  | target_project_id | projectB |

The RBAC then fails to work as expected, because this is not an ID. If, instead, I create the rbac using an explicit ID of the project, then the RBAC behaves as expected.

From what I understand, the user cannot see "projectB" so there is no way for the CLI to lookup its ID. However, I would expect the CLI in this case to reply:

  "Cannot create rbac from name without permissions to list projects. Please use an ID instead"

I note that if use a user who is allowed to list projects, then when I create an rbac, the ID of the project appears in the fields of the rbac.

This bug is somewhat related to https://bugs.launchpad.net/neutron/+bug/1649909. The difference is that here we are not trying to create a "domain-scoped" rbac, but the confusion surrounding the `--target-project-domain` argument is still a problem.

[Bence Romsics (bence-romsics)]

Thank you for your report!

I was able to reproduce this problem on current master, specifically:

neutron cdb644574a
keystone 7a6e1a0bd
$ openstack --version
openstack 6.7.0

It seems to me we need to have a two-part fix:

(a) neutron should reject invalid target_tenants in requests like this:

REQ: curl -g -i -X POST http://192.168.122.198:9696/networking/v2.0/rbac-policies -H "Content-Type: application/json" -H "User-Agent: openstacksdk/3.1.1 keystoneauth1/5.6.0 python-requests/2.31.0 CPython/3.10.12" -H "X-Auth-Token: {SHA256}
4f7791206ff9b5fb43d4dd4226c30c63e30d1bc85612273c6e47554432dfa5dc" -d '{"rbac_policy": {"action": "access_as_shared", "object_type": "security_group", "object_id": "ac30c9b6-f419-4774-9521-cd6da3ebd511", "target_tenant": "nonsuch"}}'
http://192.168.122.198:9696 "POST /networking/v2.0/rbac-policies HTTP/1.1" 201 306
RESP: [201] Connection: keep-alive Content-Length: 306 Content-Type: application/json Date: Wed, 15 May 2024 13:52:05 GMT X-Openstack-Request-Id: req-666e325c-5107-48a0-89ec-52717053966d
RESP BODY: {"rbac_policy": {"id": "4a22d7d0-8199-468f-aa4e-77d6fd8c5539", "project_id": "11b2e9eba77948d987192915ef028222", "action": "access_as_shared", "object_id": "ac30c9b6-f419-4774-9521-cd6da3ebd511", "target_tenant": "nonsuch", "obj
ect_type": "security_group", "tenant_id": "11b2e9eba77948d987192915ef028222"}}

(b) openstackclient should reject target tenant names it cannot resolve to a uuid, particularly it should properly handle 403 errors:

GET call to identity for http://192.168.122.198/identity/v3/projects/nonsuch used request id req-32737285-3931-4f65-91fa-240bd303a8cd
Request returned failure status: 403
REQ: curl -g -i -X GET http://192.168.122.198/identity/v3/projects?domain_id=default&name=nonsuch -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -H "X-Auth-Token: {SHA256}4f7791206ff9b5fb43d4dd4226c30c63e30d1bc8561227
3c6e47554432dfa5dc"
Resetting dropped connection: 192.168.122.198
http://192.168.122.198:80 "GET /identity/v3/projects?domain_id=default&name=nonsuch HTTP/1.1" 403 135
RESP: [403] Connection: close Content-Length: 135 Content-Type: application/json Date: Wed, 15 May 2024 13:52:05 GMT Server: Apache/2.4.52 (Ubuntu) Vary: X-Auth-Token x-openstack-request-id: req-5d6732b9-f4b3-47f5-b447-cca24a624b49
RESP BODY: {"error":{"code":403,"message":"You are not authorized to perform the requested action: identity:list_projects.","title":"Forbidden"}}

GET call to identity for http://192.168.122.198/identity/v3/projects?domain_id=default&name=nonsuch used request id req-5d6732b9-f4b3-47f5-b447-cca24a624b49
Request returned failure status: 403
REQ: curl -g -i -X GET http://192.168.122.198/identity/v3/projects? -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -H "X-Auth-Token: {SHA256}4f7791206ff9b5fb43d4dd4226c30c63e30d1bc85612273c6e47554432dfa5dc"
Resetting dropped connection: 192.168.122.198
http://192.168.122.198:80 "GET /identity/v3/projects HTTP/1.1" 403 135
RESP: [403] Connection: close Content-Length: 135 Content-Type: application/json Date: Wed, 15 May 2024 13:52:05 GMT Server: Apache/2.4.52 (Ubuntu) Vary: X-Auth-Token x-openstack-request-id: req-428d741f-8b...

[Slawek Kaplonski (slaweq)]

I was investigating that issue and I think we should only document it on the neutron side and maybe fix handling of the 403 properly on the OSC side.
The main problem with validation on the neutron's server side is that project_id is just string, not even uuid like string so it is impossible to know just like that if this is project_id or not. To add such validation we would need to call keystone api with the auth_token of the user who made request to the Neutron and this have at least 2 problems:

1. it will make our API slower as it is synchronous and we will do request to the keystone api which will make our response to the user slower,

2. We will still not be able to verify if the project really exists or not when user who is doing request to neutron is just regular user and don't have access to the target project on keystone's side. We could theoretically use admin context (like Nova user) to ask keystone about the project but then Neutron API can be used by not allowed user to discover id of other projects.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-lib/+/920870

[Slawek Kaplonski (slaweq)]

After thinking about this a bit more I think that 404 and 403 are not handled in the same way on the OSC side to not give user who shouldn't have access the target project any information about if it exists or not. So I think that there we also can't really do anything more. I think that update to our api-ref: https://review.opendev.org/c/openstack/neutron-lib/+/920870 have to be enough to address this bug.