[RFE] Tag based policy

[Yang Youseok]

It's not directly related to Neutron though, Neutron have been used tagging concept widely so that I think it's good place to start with. Also, I felt this feature allows rbac_policy functionality to be achieved in a slightly more generic way.

What I want to achieve is tag based policy. The scenario that I imagine like this

1. Admin attach tag to several resource. (Network / Service Provider ...)

2. Tags attached in project exposed in auth_token so that credential used oslo.policy can take tagging list.

3. Admin add specific rule in oslo.policy like this

"get_network": "project_tags:%(tags)s"

4. Then users can access limited resources which only matched to their tag.

I think changing for the implementation belongs to several components though (oslo.context / oslo.policy / keystone / nova ...), LoC is not so much since there were already many building blocks can be used.

I already posted the keystone side for the feature that I said in (2):
https://bugs.launchpad.net/keystone/+bug/1807697

It seems that the feedback from the service use directly this feature can give a little more power to this RFE. So I will be appreciated to what Neutron folks think about it.

Thanks in advance.

[Slawek Kaplonski (slaweq)]

We already have role based access control for some of resources (like networks or qos policies). We also have "regular" policy.json mechanism which can be used to define some access "levels" for users.
So I'm affraid if adding 3rd mechanism is really good idea. Maybe we should focus on e.g. improving rbac instead? Or maybe it's completly fine to have both things in place - I really don't know but I think that this should be discussed first :)

[Yang Youseok (ileixe)]

@Slawek Kaplonski

Thanks for your attention about this issue.

I also strongly against adding more complexity (especially for the complex APIs like oslo.policy), but I could not find optimal solution for our problems. If there were better solutions with current features, I definitely use it.

For better understanding, I need to say what kind of problems we encounters.

1. (Neutron) Admin want to 'map' access control of resource to 'project'.
  It's somewhat looks like to rbac_policy in Neutron. Admin want some project to access some
  shared network / subnet / service providers or anything.

  Using olso.policy, we have to assign role to 'user' so there is no way to control per
  'project' units.

  Using rbac_policy, it can be achieved to access resources per projects though, it does not have
  'mapping' mechanism like 'tag' so admin have to assign fine-graded policies. For example, when
  admin want a project to restrict some service providers, they have to create rbac_policy for
  every service providers. If there is something like mapper (tag in this case), admin can make a
  tag without assigning every resources. And even worse, there is no feature like rbac_policy in
  other projects at all..

2. (Nova) Admin want to restrict host aggregate per projects.
  From my current understanding, user can choose their deployment environments using availability
  zone (host aggregate). But if admin want to restrict some host resources to some projects.
  There is no building blocks for that. Only way to be available I found is that separating
  regions but it's not a option considering operating cost.

There were many other use cases though, I think two things mentioned above is major. I wonder what kind of 'regular' way to solve this kind problem, and even I worried that it's not a problem at all since it was solved in a completely different way. This kind of problems have troubled us for a long time, so I appreciated any kind of advices.

For the implementation, I do not mean to introduce a whole new thing. What I want to is
1. To expose tag attribute in keystone side (and keystonemiddleware / oslo.context / keystoneauth)
2. Add new 'kind' called 'tag' to oslo.policy. I think GenericCheck in oslo.policy is usually enough though, we have to deal with many to many mapping in that case. So adding a simple new kind is needed.

Thanks!

[Yang Youseok (ileixe)]

Hi forks. I sent initial PoC code for this issue. Please consider the patch below. Any comments would be appricated.

https://review.opendev.org/#/c/654321/

[Miguel Lavalle (minsel)]

Hi Yang,

I see that the Keystone team showed some openness to go in this direction (I left a note in the RFE you filed with them). I would like to see the feedback we get from oslo.policy.

In the meantime, let's try to make some progress here. When you say above that "admin want a project to restrict some service providers", what do you mean by service providers?

[Yang Youseok (ileixe)]

Hi Miguel, Thanks for the comment.

Service provider is I said above is the very service provider in Neutron. I would like to give our specific case for better understanding.

- We have two kinds of LBaaS service provider. Octavia / 3-rd party appliance
- Since resource provided appliance is restricted, we also have to put a limit on it.
- We want projects with 'Production' tag only can access appliance service provider LBaaS.
- So we add tag API on 'service_provider' in Neutron, filtering with the tag based policy.

I know there is no tagging API in service provider resource yet, if this concept seems to be reasonable, I willing to add related patch on the API.

Thanks.

[Miguel Lavalle (minsel)]

Hi Yang,

I can see that the RFE in Keystone was not accepted: https://bugs.launchpad.net/keystone/+bug/1807697. That RFE was a prerequisite for this one. As a consequence, I think we should also close this RFE. I will wait a week for you to respond

[Yang Youseok (ileixe)]

Sure, thanks for tracking this issue.

[Miguel Lavalle (minsel)]

Hi Yang,

Thanks for the follow up. Closing this RFE