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: chu...@ca.ibm.com
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
