Impossible to define policy rule based on domain ID

[Valeriy Ponomaryov]

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

[gordon chung (chungg)]

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).

[Sean McGinnis (sean-mcginnis)]

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?

[Valeriy Ponomaryov (vponomaryov)]

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

[Kirill Zaitsev (kzaitsev)]

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?

[Valeriy Ponomaryov (vponomaryov)]

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)]

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

[Sean McGinnis (sean-mcginnis)]

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.

[Akihiro Motoki (amotoki)]

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.

[Ben Nemec (bnemec)]

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?

[Adam Young (ayoung)]

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

[Morgan Fainberg (mdrnstm)]

@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.