~openstack-gd/nova/lp785816-joinedload

 

.. _auth:

 

 

-----------------------

 

.. automodule:: nova.quota

    :undoc-members:

    :show-inheritance:

 

Auth Manager

------------

 

~~~~~~~~~~~~~~~~~~~~~~~~~

 

.. automodule:: nova.auth.manager

    :undoc-members:

    :show-inheritance:

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

.. automodule:: nova.auth.ldapdriver

    :undoc-members:

    :show-inheritance:

 

~~~~~~~~~~~~~~~~~~~~~~~~~~

 

.. automodule:: nova.auth.dbdriver

    :undoc-members:

    :show-inheritance:

 

 

The :mod:`auth_unittest` Module

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    :undoc-members:

    :show-inheritance:

 

The :mod:`access_unittest` Module

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

    :undoc-members:

    :show-inheritance:

 

The :mod:`quota_unittest` Module

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

    :undoc-members:

    :show-inheritance:

 

-----------

 

Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles:

Roles-Based Access Control of AWS-style APIs using SAML Assertions

“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”

 

Introduction

------------

 

We will investigate one method for integrating an AWS-style API with US eAuthentication-compatible federated authentication systems, to achieve access controls and limits based on traditional operational roles.

Additionally, we will look at how combining this approach, with an implementation of the CloudAudit APIs, will allow us to achieve a certification under FIPS 199 Moderate classification for a hybrid cloud environment.

 

Relationship of US eAuth to RBAC

--------------------------------

 

 

.. _auth_roles:

 

Roles

-----

 

 

*       All permissions

 

Enhancements

------------

 

Wrapping the SAML token into the API calls.

Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII.

 

CloudAudit APIs

---------------

 

CloudAudit queries may spawn long-running processes (similar to launching instances, etc.) They need to return a ReservationId in the same fashion, which can be returned in further queries for updates.

RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability.

 

Type declarations

-----------------

*       Data declarations – Volumes and Objects

 

These additional parameters would also apply to creation of block storage volumes (along with the existing parameter of ‘size’), and creation of object storage ‘buckets’. (C.I.A. classifications on a bucket would be inherited by the keys within this bucket.)

 

Request Brokering

-----------------

 

 

Establishing declarative semantics for individual API calls will allow the cloud environment to seamlessly proxy these API calls to external, third-party vendors – when the requested CIA levels match.

 

See related work within the Infrastructure 2.0 working group for more information on how the IMF Metadata specification could be utilized to manage registration of these vendors and their C&A credentials.

 

Dirty Cloud – Hybrid Data Centers

---------------------------------

 

 

Network discovery protocols (ARP, CDP) can be applied in this case, and existing protocols (SNMP location data, DNS LOC records) overloaded to provide CloudAudit information.

 

The Details

-----------

 

 

System limits

-------------

 

Further Challenges

------------------