Add domain rbac to gnocchi

That makes sense.

We should take a step back and make the RBAC code more generic. I don't think it's wise to keep adding more Keystone related field (even if those are generally valid) in our indexer. We should figure something a bit more generic for our RBAC.

So my current thoughts on this is to add a generic "auth_source" on resources that could be mapped on a domain. This would add a larger support than just domains, as this could be a different domain or a different Keystone or a different system altogether.

I agree with your thoughts, it is better to make it generic and not only for keystone domains.

Though after chatting with Gordon, Keystone middleware explicit adds and use X-Domain-Id. So maybe we should just use call that domain_id and advertise at being generic (it's a string after all). You could use an URL or an UUID, or whatever you want.

Hi jd_, any news on storing the domain as resource metadata and adding domain rbac to gnocchi?

I think you can actually already use it as a metadata, you just can put it on "generic" so you need to include it on all your types.

I'm not sure if oslo.policy rules will work against those fields, we should add some checks I guess. Right now I think we just miss the extraction of X-Domain-Id and its usage in oslo.policy. I'll add that, that should be pretty straight forward.

Thaks Julien, when do you think we can have it added to use it with oslo.policy?

Fix proposed to branch: master
Review: https://review.openstack.org/338393

Reviewed: https://review.openstack.org/338393
Committed: https://git.openstack.org/cgit/openstack/gnocchi/commit/?id=e7a9a578fb2777c1965fbfbaf478f1cde892f30c
Submitter: Jenkins
Branch: master

commit e7a9a578fb2777c1965fbfbaf478f1cde892f30c
Author: Julien Danjou <email address hidden>
Date: Wed Jul 6 14:13:04 2016 +0200

    rest: allow to use X-Domain-Id in policy rules

    Change-Id: Idfdcd1c46e7d0207d3959dd67d1cadb6a249068b
    Closes-Bug: #1576804

Hello Julien,

I'm trying to use this fix, however I believe it's missing something. The resource-type "generic" is not one that a user can edit, therefore we would need to modify gnocchi's code so that all resources have a domain_id property (much like project_id today). Otherwise, no resource would have a mapping regarding to which domain it belongs, therefore the fix won't have any effect.
Is it possible to add domain_id to generic?

Thanks, regards.

Yes, this is a different (and complement bug) as I wrote earlier. We need to probably change the generic approach here.

nvlan, Openstack resources are belong project, not domain.

See 'https://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#projects-v3-projects'

So I'm not sure that resource must be owned by a domain since it already belong a project.
and a domain is just a particular domain.

For example a nova instance doesn't have user_id or domain_id but only project_id. Why should we add a domain_id for an instance if nova is not aware of this.

Hello Julien, Mehdi,

Perhaps I didn't make myself clear. What we wish to accomplish is the following: in a domain-enabled openstack deploy, a regular user belonging to a project should be able to see only the resources that belong to said project (that happens today). A domain admin should be able to see all resources that belong to that domain, but not the resources that belong to a different domain nor all resources.
I've created the resource-types with a domain_id value, and now have the ceilometer agents adding an arbitrary domain_id to the samples. I tried to modify the policy.json file so that a domain-scoped token results in listing only the resources for that domain, but to no avail. The rule I tried is:

    "domain_member": "domain_id:%(resource.domain_id)s",

How can I use X-Domain-Id in the policy.json file to limit the resources that gnocchi return?

That should work as far as I can tell Nicolas. Can you provide more info, such as your full policy.json for e.g. resources (where I expect you added usage of domain_member) and maybe some more debug log if any? (though I don't think oslo.policy is providing debug log)

Hello Julien,

I'm attaching a couple of files:

resources.txt show two resources that I created from two different domains, each resource has its domain_id as metadata.

policy.json is the current one I'm using, showing that "list resource" should be limited to the domain_id.

gnocchi_domain_log.txt is a log extract that I added to validate that the requests to gnocchi API contain the domain_id (I was calling it using two different users that each belong to a different domain).

So far I haven't been able to filter gnocchi's result, it looks as if the validation is performed about whether you can execute that call or not, but not to filter the results. Perhaps I'm missing something?

Thanks, regards.

To build on the policy.json example (list resource), what I would like to accomplish is for this function https://github.com/openstack/gnocchi/blob/master/gnocchi/rest/__init__.py#L99 to return a policy_filter with the specific domain_id that should be filtered (much like the created_by_project). Does that make any sense?

Thanks, regards.

Right, listing is a particular use case since oslo.policy is too limited for our use case which is building dynamic filter based on ACL…

The solution would be to create the ACL filter based on the rules described in oslo.policy. This might be possible, but it's a bigger piece of job :/

As a further comment, we'll be receiving samples from different customers. We wish to be able to group all resources from every project from a specific customer within a domain, and not let that customer to view/edit resources belonging to a different customer (each customer will be issued a domain-scoped project).
This scenario is the reason behind looking for domain rbac on gnocchi. When I edited the "created_by_project_id" value with a domain_id, and hardcode the domain-id in https://github.com/openstack/gnocchi/blob/master/gnocchi/rest/__init__.py#L123, the resource list shows only that resource. It would be perfect if we could limit all potentially destructive actions (update/delete a resource/metric) to the user's domain only (since in ceilometer.conf in [service_credentials] we configure that customer's domain credentials only).

Please let me know if I didn't make myself clear.

Thanks a lot, regards.

Hello Julien,

Do you have any update regarding this request?

Thanks, regards.

It's still in my backlog Nicolas, but it's not trivial. As said, we need to parse oslo.policy rules and see if we can map them to a query filter.

Hello Julien,

I've modified gnocchi code and got this to work, a user with a domain-scoped token can only list/get/delete resources that match the domain_id of the resource. Let me know if you'd like me to share what I did (it may not be pretty code, but it works).

Thanks, regards.

I'd suggest to share it because it can also help others. I doubt it's generic enough to be the solution we want to implement, but it might be a good first step.

This issue was fixed in the openstack/gnocchi 2.2.0 release.

Hello Julien,

I've attached a .tgz with the files I modified for making gnocchi to work with domains, with it every resource created have its corresponding domain_id from ceilometer.conf's [service_credentials], and the policy.json makes a "gnocchi resource list" show only the resources from the user's domain.

Regards.