Impossible to define policy rule based on domain ID

Bug #1699060 reported by Valeriy Ponomaryov
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Glance
New
Undecided
Unassigned
OpenStack Compute (nova)
Opinion
Wishlist
Unassigned
OpenStack Heat
Triaged
Wishlist
Unassigned
OpenStack Shared File Systems Service (Manila)
Opinion
Wishlist
Unassigned
neutron
Opinion
Wishlist
Unassigned
oslo.policy
Invalid
Wishlist
Unassigned
watcher
Opinion
Wishlist
Unassigned

Bug Description

We have common approach to set rules for each API using policy.json file.
And for the moment, it is not possible to use "domain_id" in policy rules,
only "project_id" and "user_id". It becomes very important because Keystone API v3 is used more and more.
The only service that supports rules with "domain_id" is Keystone itself.

As a result we should be able to use following rules:
"admin_or_domain_owner": "is_admin:True or domain_id:%(domain_id)s",
"domain_owner": "domain_id:%(domain_id)s",

like this:

"volume:get": "rule:domain_owner",

or

"volume:get": "rule:admin_or_domain_owner",

Right now, we always get 403 error having such rules.

Related mail-list thread: https://openstack.nimeyo.com/115438/openstack-dev-all-policy-rules-for-apis-based-on-domain_id

Tags: policy
description: updated
tags: added: policy
description: updated
description: updated
Revision history for this message
gordon chung (chungg) wrote :

please don't create these openstack-wide bugs, it spams everyone. i've removed telemetry projects but feel free to apply patches to them (don't do it for ceilometer since it doesn't have an active api).

no longer affects: aodh
no longer affects: ceilometer
no longer affects: panko
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote :

Yeah, I don't think opening bugs against every project is the right way to go here. This really is a cross project thing that could use some discussion. Maybe start a mailing list thread?

Revision history for this message
Valeriy Ponomaryov (vponomaryov) wrote :
description: updated
Revision history for this message
Kirill Zaitsev (kzaitsev) wrote :

Mass opening bugs definitely not going to solve this. Also it's not quite clear from the bug or mail — what the projects should/shouldn't do. Is it really an issue with oslo.policy?

no longer affects: murano
Revision history for this message
Valeriy Ponomaryov (vponomaryov) wrote :

Kirill,

it is issue of each separate project, not library. Library does everything correctly.

Each project should start storing "domain_id" in DB models as it is done with "project_id" and "user_id".

Only then, it will be possible to use it with "oslo.policy" library.

So, for everyone, it is not "spam", each of assigned projects DOES have bug, that is "not complete support of keystone API v3".

And before marking it as "not affecting" need to verify it first. Steps for reproducing are defined in buyg report.

Revision history for this message
Sean Dague (sdague) wrote :

Items like this for Nova would definitely need a spec, it's not a bug

Changed in nova:
status: New → Opinion
importance: Undecided → Wishlist
Rico Lin (rico-lin)
Changed in heat:
status: New → Triaged
importance: Undecided → Wishlist
Changed in manila:
importance: Undecided → Wishlist
status: New → Opinion
Revision history for this message
Sean McGinnis (sean-mcginnis) wrote :

Agree with above. If we want this, this needs to be a general policy change across projects, and not something each project needs to address. This is a new feature request (probably for oslo.policy) and not a bug.

no longer affects: cinder
Revision history for this message
Akihiro Motoki (amotoki) wrote :

I agree with Sean. It is worth tackled as a cross project topic.

As an individual project, neutron triages this in the same way as nova does.

Changed in neutron:
status: New → Opinion
importance: Undecided → Wishlist
Changed in watcher:
importance: Undecided → Wishlist
status: New → Opinion
Rico Lin (rico-lin)
Changed in heat:
milestone: none → no-priority-tag-bugs
Revision history for this message
Ben Nemec (bnemec) wrote :

From this bug I'm not clear exactly what would be needed from oslo.policy for this. I know we just merged https://github.com/openstack/oslo.policy/commit/775641a5fc549c20be37cf862deca394bf7f2d21 which allows policy to deal with context objects. Would that be helpful here?

Changed in oslo.policy:
status: New → Incomplete
importance: Undecided → Wishlist
Revision history for this message
Adam Young (ayoung) wrote :

This is actually due to oslo-context, which is what the services use to enforce policy.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

@Ben, this is nothing to do with oslo-policy. it has to do with the values passed to oslo-policy in the creds dict. If the creds dict does not have domain-id populated in it, you can't enforce on it.

Changed in oslo.policy:
status: Incomplete → Invalid
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.