Open Stack

On 07/04/2013 04:50 PM, Gordon Chung wrote:
> hi Folks,
>
> just wanted to bring everyone's attention to this blueprint we have in
> Ceilometer:
> _https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats_(detailed
> bp:
> _https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-standard-audit-formats#Provide_support_for_auditing_events_in_standardized_formats_)
>
> as a little background, there are many projects that use Ceilometer to
> track usage information for statistical usage analysis and billing.
>   these projects are seeing similar auditing requirements which are
> missing currently.  the above blueprint's proposal is to add support for
> auditing APIs access using the Distributed Mgmt. Task Force’s (DMTF)
> “Cloud Audit” standard (CADF).  you can read further into the spec via
> the latest public draft here:
> http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0a_0.pdf but
> to highlight the standard, it is an open standard developed by multiple
> enterprises -- IBM, NetIQ, Microsoft, VMware, and Fujitsu to name a few.
>   Also, the model is regulatory compliant (e.g. PCI-DSS, SoX, ISO 27017,
> etc.) and extensible so it should adapt to a broad range of uses.
>
> initially, we drafted this to be part of Ceilometer but as we've worked
> through it, we've noticed it is applicable in multiple projects. during
> the course of our discussions with Keystone developers to assure we were
> recording the correct data for audit, we found that Keystone itself had
> a blueprint to add notifications and log audit data for their APIs:
> _https://blueprints.launchpad.net/keystone/+spec/notifications_.

After reading the detailed spec, I don't understand why this would 
belong anywhere other than Ceilometer. There's no need to push a 
different source event notification format on all the other projects. 
All that the proposed spec would really add is a translation middleware 
endpoint in the Ceilometer REST API to translate query results from the 
(simpler and more intuitive) Ceilometer resource REST API to the (more 
complicated but thankfully not XML) resource results of the CADF format.

In other words, the entire thing can be constructed as a simple piece of 
Python WSGI middleware that transforms requests and responses from one 
format to another. FWICT, Ceilometer already collects all of the base 
data elements that are needed by CADF, and all that really would be 
happening is changing the object key names for some of the elements and 
adding in tag bindings for source and project.

So, -1 on adding this to Oslo. I don't think it needs to go in there, 
since I don't think other projects need it.

Best,
-jay

> i thought i'd present this on the mailing list to gather feedback on the
> idea of adopting CADF and discuss possibly its inclusion in Oslo so that
> all the projects can use the same open standard when capturing events.
>
> cheers,
>
> gordon chung
>
> openstack, ibm software standards
> email: chungg at ca.ibm.com
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>