Impossible to define policy rule based on domain ID

Bug #1699060 reported by Valeriy Ponomaryov on 2017-06-20
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Glance
Undecided
Unassigned
Manila
Wishlist
Unassigned
OpenStack Compute (nova)
Wishlist
Unassigned
OpenStack Heat
Triaged
Wishlist
Unassigned
neutron
Wishlist
Unassigned
oslo.policy
Wishlist
Unassigned
watcher
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

description: updated
tags: added: policy
description: updated
description: updated
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
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?

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

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.

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) on 2017-07-05
Changed in heat:
status: New → Triaged
importance: Undecided → Wishlist
Changed in manila:
importance: Undecided → Wishlist
status: New → Opinion
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
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) on 2018-05-07
Changed in heat:
milestone: none → no-priority-tag-bugs
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
Adam Young (ayoung) wrote :

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

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  Edit
Everyone can see this information.

Other bug subscribers