15
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
21
112
Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles:
23
114
Roles-Based Access Control of AWS-style APIs using SAML Assertions
24
115
“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”
29
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.
30
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.
32
125
Relationship of US eAuth to RBAC
33
126
--------------------------------
39
132
[ SUN Identity Manager or other SAML Policy Controller ]
40
133
--> maps URLs to groups…
41
134
[ Apache Policy Agent in front of eAuth-secured Web Application ]
43
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.
45
Basic AWS API call structure
46
----------------------------
48
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:
51
* System Administrator
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)
52
148
* Network Administrator
57
There is an additional, conceptual end-user that may or may not have API access:
59
* (EXTERNAL) End-user / Third-party User
61
Basic operations are available to any System User:
64
* Terminate Instance (their own)
67
* Create, Upload, Delete: Buckets and Keys (Object Store) – their own
68
* Create, Attach, Delete Volume (Block Store) – their own
70
System Administrators:
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
72
170
* Register/Unregister Machine Image (project-wide)
73
* Change Machine Image properties (public / private)
74
171
* Request / Review CloudAudit Scans
175
* Add and remove other users (currently no api)
176
* Set roles (currently no api)
76
178
Network Administrator:
180
* Change Machine Image properties (public / private)
78
181
* Change Firewall Rules, define Security Groups
79
182
* Allocate, Associate, Deassociate Public IP addresses
83
* Launch and Terminate Instances (project-wide)
84
* CRUD of Object and Block store (project-wide)
88
* Register / Unregister Kernel and Ramdisk Images
89
* Register / Unregister Machine Image (any)
184
Cloud Administrator/IT-Security:
98
196
Wrapping the SAML token into the API calls.
99
197
Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII.
120
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.)
122
223
Request Brokering
123
224
-----------------
126
* IMF Registration / PubSub
227
* IMF Registration / PubSub
129
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.
131
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.
133
235
Dirty Cloud – Hybrid Data Centers
134
236
---------------------------------
136
238
* CloudAudit bridge interfaces
137
239
* Anything in the ARP table
139
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
241
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
141
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.
143
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.
148
* Preliminary Roles Definitions
149
* Categorization of available API calls
150
* SAML assertion vocabulary
251
* Preliminary Roles Definitions
252
* Categorization of available API calls
253
* SAML assertion vocabulary
155
The following limits need to be defined and enforced:
259
The following limits need to be defined and enforced:
157
261
* Total number of instances allowed (user / project)
158
262
* Total number of instances, per instance type (user / project)
166
270
Further Challenges
167
271
------------------
168
* Prioritization of users / jobs in shared computing environments
169
* Incident response planning
170
* Limit launch of instances to specific security groups based on AMI
171
* Store AMIs in LDAP for added property control
175
The :mod:`signer` Module
176
------------------------
178
.. automodule:: nova.auth.signer
183
The :mod:`users` Module
184
-----------------------
186
.. automodule:: nova.auth.users
191
The :mod:`users_unittest` Module
192
--------------------------------
194
.. automodule:: nova.tests.users_unittest
199
The :mod:`access_unittest` Module
200
---------------------------------
202
.. automodule:: nova.tests.access_unittest
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
