2
Copyright 2010-2011 United States Government as represented by the
3
Administrator of the National Aeronautics and Space Administration.
6
Licensed under the Apache License, Version 2.0 (the "License"); you may
7
not use this file except in compliance with the License. You may obtain
8
a copy of the License at
10
http://www.apache.org/licenses/LICENSE-2.0
12
Unless required by applicable law or agreed to in writing, software
13
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
14
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
15
License for the specific language governing permissions and limitations
20
Authentication and Authorization
21
================================
23
The :mod:`nova.quota` Module
24
----------------------------
26
.. automodule:: nova.quota
33
The :mod:`nova.auth.signer` Module
34
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
36
.. automodule:: nova.auth.signer
46
The :mod:`nova.auth.manager` Module
47
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
49
.. automodule:: nova.auth.manager
56
The :mod:`nova.auth.ldapdriver` Driver
57
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
59
.. automodule:: nova.auth.ldapdriver
65
The :mod:`nova.auth.dbdriver` Driver
66
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68
.. automodule:: nova.auth.dbdriver
79
The :mod:`auth_unittest` Module
80
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
82
.. automodule:: nova.tests.auth_unittest
89
The :mod:`access_unittest` Module
90
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
92
.. automodule:: nova.tests.access_unittest
99
The :mod:`quota_unittest` Module
100
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
102
.. automodule:: nova.tests.quota_unittest
112
Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles:
114
Roles-Based Access Control of AWS-style APIs using SAML Assertions
115
“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”
121
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.
122
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.
125
Relationship of US eAuth to RBAC
126
--------------------------------
128
Typical implementations of US eAuth authentication systems are structured as follows::
130
[ MS Active Directory or other federated LDAP user store ]
132
[ SUN Identity Manager or other SAML Policy Controller ]
133
--> maps URLs to groups…
134
[ Apache Policy Agent in front of eAuth-secured Web Application ]
136
In more ideal implementations, the remainder of the application-specific account information is stored either in extended schema on the LDAP server itself, via the use of a translucent LDAP proxy, or in an independent datastore keyed off of the UID provided via SAML assertion.
144
AWS API calls are traditionally secured via Access and Secret Keys, which are used to sign API calls, along with traditional timestamps to prevent replay attacks. The APIs can be logically grouped into sets that align with five typical roles:
147
* System Administrator/Developer (currently have the same permissions)
148
* Network Administrator
150
* Cloud Administrator/IT-Security (currently have the same permissions)
152
There is an additional, conceptual end-user that may or may not have API access:
154
* (EXTERNAL) End-user / Third-party User
156
Basic operations are available to any :
164
* Create, Upload, Delete: Buckets and Keys (Object Store)
166
System Administrators/Developers/Project Manager:
168
* Create, Attach, Delete Volume (Block Store)
169
* Launch, Reboot, Terminate Instance
170
* Register/Unregister Machine Image (project-wide)
171
* Request / Review CloudAudit Scans
175
* Add and remove other users (currently no api)
176
* Set roles (currently no api)
178
Network Administrator:
180
* Change Machine Image properties (public / private)
181
* Change Firewall Rules, define Security Groups
182
* Allocate, Associate, Deassociate Public IP addresses
184
Cloud Administrator/IT-Security:
196
Wrapping the SAML token into the API calls.
197
Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII.
205
* Stateless asynchronous queries
207
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.
208
RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability.
213
* Data declarations – Volumes and Objects
214
* System declarations – Instances
216
Existing API calls to launch instances specific a single, combined “type” flag. We propose to extend this with three additional type declarations, mapping to the “Confidentiality, Integrity, Availability” classifications of FIPS 199. An example API call would look like::
218
RunInstances type=m1.large number=1 secgroup=default key=mykey confidentiality=low integrity=low availability=low
220
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.)
227
* IMF Registration / PubSub
230
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.
232
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.
235
Dirty Cloud – Hybrid Data Centers
236
---------------------------------
238
* CloudAudit bridge interfaces
239
* Anything in the ARP table
241
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
243
This interconnect is typically a bridged VPN connection. Any machines that can be bridged into a hybrid environment in this fashion (at Layer 2) must implement a minimum version of the CloudAudit spec, such that they can be queried to provide a complete picture of the IT-sec runtime environment.
245
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.
251
* Preliminary Roles Definitions
252
* Categorization of available API calls
253
* SAML assertion vocabulary
259
The following limits need to be defined and enforced:
261
* Total number of instances allowed (user / project)
262
* Total number of instances, per instance type (user / project)
263
* Total number of volumes (user / project)
264
* Maximum size of volume
265
* Cumulative size of all volumes
266
* Total use of object storage (GB)
267
* Total number of Public IPs
273
* Prioritization of users / jobs in shared computing environments
274
* Incident response planning
275
* Limit launch of instances to specific security groups based on AMI
276
* Store AMIs in LDAP for added property control
added
removed
doc/source/devref/auth.rst
