Re: [openstack-dev] [Ceilometer] Event API Access Controls
On Sat, Aug 03 2013, Herndon, John Luke (HPCS - Ft. Collins) wrote: Hi John, Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? You should definitely use the policy system we has in Ceilometer to check that the user is authenticated and has admin privileges. We already have such a mechanism in ceilometer.api.acl. I don't see any point to expose raw operator system data to the users. That could even be dangerous security wise. -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Event API Access Controls
Hi Julien, On 8/5/13 2:04 AM, Julien Danjou jul...@danjou.info wrote: On Sat, Aug 03 2013, Herndon, John Luke (HPCS - Ft. Collins) wrote: Hi John, Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? You should definitely use the policy system we has in Ceilometer to check that the user is authenticated and has admin privileges. We already have such a mechanism in ceilometer.api.acl. I don't see any point to expose raw operator system data to the users. That could even be dangerous security wise. This plans sounds good to me. We can enable/disable the event api for users, but is there a way to restrict a user to viewing only his/her events using the policy system? Or do we not need to do that? -john -- Julien Danjou // Free Software hacker / freelance consultant // http://julien.danjou.info smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Event API Access Controls
On Mon, Aug 05 2013, Herndon, John Luke (HPCS - Ft. Collins) wrote: This plans sounds good to me. We can enable/disable the event api for users, but is there a way to restrict a user to viewing only his/her events using the policy system? Or do we not need to do that? There may be, but we don't want to do that. -- Julien Danjou ;; Free Software hacker ; freelance consultant ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Event API Access Controls
On 08/02/2013 06:26 PM, Herndon, John Luke (HPCS - Ft. Collins) wrote: Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? PS -I'm new to the ceilometer project, so let me introduce myself. My name is John Herndon, and I work for HP. I've been freed up from a different project and will be working on ceilometer. Thanks, looking forward to working with everyone! -john 0: https://blueprints.launchpad.net/ceilometer/+spec/specify-event-api Welcome to the contributor community, John. :) I think defaulting the access to the service's events API endpoints to just admins makes the most sense, and you can use the existing policy engine to make that access configurable with the policy.json file. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Event API Access Controls
Hello, I'm currently implementing the event api blueprint[0], and am wondering what access controls we should impose on the event api. The purpose of the blueprint is to provide a StackTach equivalent in the ceilometer api. I believe that StackTach is used as an internal tool which end with no access to end users. Given that the event api is targeted at administrators, I am currently thinking that it should be limited to admin users only. However, I wanted to ask for input on this topic. Any arguments for opening it up so users can look at events for their resources? Any arguments for not doing so? PS -I'm new to the ceilometer project, so let me introduce myself. My name is John Herndon, and I work for HP. I've been freed up from a different project and will be working on ceilometer. Thanks, looking forward to working with everyone! -john 0: https://blueprints.launchpad.net/ceilometer/+spec/specify-event-api smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
