[Openstack-operators] [ceilometer][keystone][billing] RBAC restrictions of Ceilometer's Event API prevents billing of Openstack cloud
Hi, my company is currently starting to implement a public Openstack cloud. I am part of the developer team creating a billing system towards our customers. We want to use Ceilometer's Event API (Liberty release) to retreive the usage information (as /v2/events) of our customers projects(aka tenants). Unfortunately, the RBAC filter prevents REST calls towards the /v2-Web-API from users who are not member of the project (or are their admin). But adding a user to all projects with a distinc ceilometer-reader role or admin role seems not fourtunate to us because to want to serve admin role users to their own domain to each customer. So the ceilometer-reader user could be removed by a customer. Due to this, we ran into some kind of deadlock of good solutions and would be happy to get any help: - Is there another/common way to retrieve the event based usage information in a way to generate billing information? For example volume A was created at t1 and deleted at t2. - Is there a way to get a project scope token from keystone through some kind of cloud admin user which is not part of the project? - Is there a way to change Ceilometers policy.json in a way to retrieve data from all projects with a admin on the default project or someone similiar? Thanks for your efforts. Greetings, Christian Brinker ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [ceilometer][keystone][billing] RBAC restrictions of Ceilometer's Event API prevents billing of Openstack cloud
I don't fully understand the architecture of our rating project, but as I understand it we use a service with rights to read ceilometer info (in our case, pollsters and notifications) and then aggregate that into another database which we query to get the actual billing information. We bill monthly, and getting a month's worth of data for each tenant in one hit would crush our older, Mongo based, Ceilometer into dust. The tiny database that contains the distilled information is quick and easy to query, to the point where we can display that information to customers as an extra panel in the dashboard. Just a side note - what would happen if you missed an event? Say, e.g., rabbit had a bad day... or something just wasn't running... We found pollsters gave us the assurance to mean we'd only lose up to 10 mins of data, which is generally OK when we bill by the hour. On 7 December 2015 at 23:01, Christian Brinkerwrote: > Hi, > > my company is currently starting to implement a public Openstack > cloud. I am part of the developer team creating a billing system > towards our customers. We want to use > Ceilometer's Event API (Liberty release) to retreive the usage > information (as /v2/events) of our customers projects(aka tenants). > Unfortunately, the RBAC filter > prevents REST calls towards the /v2-Web-API from users who are not > member of the project (or are their admin). But adding a user to all > projects with a distinc > ceilometer-reader role or admin role seems not fourtunate to us > because to want to serve admin role users to their own domain to each > customer. So the ceilometer-reader > user could be removed by a customer. Due to this, we ran into some > kind of deadlock of good solutions and would be happy to get any help: > > - Is there another/common way to retrieve the event based usage > information in a way to generate billing information? For example > volume A was created at t1 and deleted > at t2. > - Is there a way to get a project scope token from keystone through > some kind of cloud admin user which is not part of the project? > - Is there a way to change Ceilometers policy.json in a way to > retrieve data from all projects with a admin on the default project or > someone similiar? > > Thanks for your efforts. > > Greetings, > Christian Brinker > > ___ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [ceilometer][keystone][billing] RBAC restrictions of Ceilometer's Event API prevents billing of Openstack cloud
On 12/07/2015 05:01 AM, Christian Brinker wrote: Hi, my company is currently starting to implement a public Openstack cloud. I am part of the developer team creating a billing system towards our customers. We want to use Ceilometer's Event API (Liberty release) to retreive the usage information (as /v2/events) of our customers projects(aka tenants). Unfortunately, the RBAC filter prevents REST calls towards the /v2-Web-API from users who are not member of the project (or are their admin). But adding a user to all projects with a distinc ceilometer-reader role or admin role seems not fourtunate to us because to want to serve admin role users to their own domain to each customer. So the ceilometer-reader user could be removed by a customer. Due to this, we ran into some kind of deadlock of good solutions and would be happy to get any help: - Is there another/common way to retrieve the event based usage information in a way to generate billing information? For example volume A was created at t1 and deleted at t2. - Is there a way to get a project scope token from keystone through some kind of cloud admin user which is not part of the project? - Is there a way to change Ceilometers policy.json in a way to retrieve data from all projects with a admin on the default project or someone similiar? See the commit that just merged: https://review.openstack.org/#/c/240719/ You could create a role called "observer" or "auditor" on the admin project, and modify the policy files for the services you want so that users with "auditor" with tokens that have "is_admin_project" set can read the data for that API. Can you enumerate the APIS you want to call this way? Thanks for your efforts. Greetings, Christian Brinker ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators