An overview of the Open Grid Forum's Open Cloud Computing Interface standards effort and the (non-OGF) CloudAudit ("A6") working group. Presented at CloudConnect on 17 March 2010.
1. The OGF Open Cloud Computing Interface andCloudAudit Shlomo Swidler OGF OCCI WG Member, CloudAudit WG Member March 17, 2009
2. Common OCCI & CloudAudit Vision:Open Cloud Ecosystem Open Formats Open Cloud Open Interfaces Open Data Open Source
3. Goal of OCCI Interoperability Let different cloud systemswork together Portability Move services between clouds Integration Wire up cloud with legacy At all levels of the stack
4. Who is OCCI Open Grid Forum Working Group OGF IP umbrella for copyrights, patents, trademarks More than 200 participants Industry: Rackspace, GoGrid, Sun/Oracle, RESERVOIR, … Academia: UCMadrid (OpenNebula), SLA@SOI w/Intel, … Service providers: CohesiveFT, RabbitMQ, … End users, developers
5. Current Status of OCCI Infrastructure layer spec finalized, in public review Reference implementation underway OpenNebula, other implementations in the works, too… Working on Extensions (reservations, snapshots, etc.) Building demo integrations with other standards SNIA CDMI - storage Proposed Roadmap: Draft Platform spec – October 2010 Final – late 2011
6. 20,000-foot Look at OCCI Protocol Lightweight, extensible Format-agnostic Built on HTTP, RESTful Create: HTTP POST Retrieve: HTTP GET Update: HTTP GET & HTTP PUT Delete: HTTP DELETE OCCI Application OCCI Platform OCCI Infrastructure HTTP Header Rendering XHTML5 + RDFa Rendering OCCI Core Extensions
7. 5,000-foot Look at OCCI GET http://abc.com/uid123foobar/ * Provider Instance * HTTP LINK header Compute * Storage * Links Network * Operations * Attributes OCCI Atom-like categories
8. REQUEST Eye-level Look at OCCI > GET /us-east/webapp/vm01 HTTP/1.1 > User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0 > Host: cloud.example.com > Accept: */* > < HTTP/1.1 200 OK < Date: Sat, 10 Oct 2009 12:56:51 GMT < Content-Type: application/ovf < Link: </us-east/webapp/vm01;start>; < rel="http://purl.org/occi/action/start"; < title="Start" < Link: </us-east/webapp/build.pdf>; < rel="related"; < title="Documentation"; < type="application/pdf" < Category: compute; < label="Compute Resource”; < scheme="http://purl.org/occi/kind/" < Server: occi-server/1.0 (linux) OCCI/1.0 < Connection: close < < <?xml version="1.0" encoding="UTF-8"?> < <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" < xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1" < xmlns="http://schemas.dmtf.org/ovf/envelope/1" < xml:lang="en-US” < ... Get the resource, in whatever format RESPONSE It’s in OVF format You can “start” it Related “documentation” It’s a “compute” resource The OVF payload
9. Goal of CloudAudit (“A6”) Provide a common interface that allows cloud computing providers to automate the audit, assertion, assessment, and assurance (“A6”) of their infrastructure (IaaS), platform (PaaS), and application (SaaS) environments. Allow authorized consumers of these services to do the same via an open, extensible, and secure interface and methodology.
10. Who is CloudAudit Over 250 participants across the industry Cloud operators Auditors Security professionals Developers, Integrators Affiliations include
11. CloudAudit Current Status Currently standardizing the data footprint Allows consistent automation for provider and consumer HTTP chosen as the protocol Format-agnostic, human or machine client Inspired by OCCI First draft expected in 90 days
12. A Look at CloudAudit Thinking http://www.cloudaudit.net/.well-known/cloudaudit/com/rackspace
13. A Look at CloudAudit Thinking http://www.cloudaudit.net/.well-known/cloudaudit/com/rackspace
14. Thank you! The OGF Open Cloud Computing Interface and CloudAudit Shlomo Swidler shlomo.swidler@orchestratus.com @ShlomoSwidler
15. Copyright Notice Copyright (C) Open Grid Forum (2009). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. The limited permissions granted above are perpetual and will not be revoked by the OGF or its successors or assignees.
Notas do Editor
Four key elements to ensuring an open ecosystem: Clouds must be accessible via open interfaces, use open formats, allow access to your data, and provide access via open source tools. Guarantees free market ecosystem without impinging on innovation/secret sauce. These four elements can be provided by choosing proper frameworks for Copyrights, Trademarks, Patents, and providing multiple, interoperable implementations.
CloudAudit has broad support across the industry, including the key roles of operators, auditors, security, and development. Believe it or not Amazon is represented in the group, which is quite remarkable – they’re normally very guarded and don’t participate in industry groups. In addition there are alliances in place with other related efforts and groups, such as ENISA (European Network & Information Security Agency), the CSA (Cloud Security Alliance), and more.
This is one possible way you can expose artifacts – and, as you can see, it’s simple for the provider to just place the needed items in the correct web server directory. This is an example of a SAS-70 report being exposed as a raw PDF, together with its PGP signature for verification.
Alternatively, the provider can expose a machine-readable xml document containing assertions within. It’s up to the provider what to expose – but the location will be standardized. Current efforts are focused on mapping existing assertions to proper namespaces, but in an extensible, non-invasive manner, allowing future assertions to be handled without any dependency the CloudAudit spec. The main message for both OCCI and CloudAudit is simplicity and ease of implementation/consumption - which we hope to achieve by getting as close as possible to HTTP and avoiding envelope formats (SOAP). It's also not too late to get involved/suggest improvements - developing standards by way of an open process takes longer but the result is almost always better.