2
Copyright [2010] [Anso Labs, LLC]
4
Licensed under the Apache License, Version 2.0 (the "License");
5
you may not use this file except in compliance with the License.
6
You may obtain a copy of the License at
8
http://www.apache.org/licenses/LICENSE-2.0
10
Unless required by applicable law or agreed to in writing, software
11
distributed under the License is distributed on an "AS IS" BASIS,
12
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13
See the License for the specific language governing permissions and
14
limitations under the License.
19
Nova provides RBAC (Role-based access control) of the AWS-type APIs. We define the following roles:
21
Roles-Based Access Control of AWS-style APIs using SAML Assertions
22
“Achieving FIPS 199 Moderate certification of a hybrid cloud environment using CloudAudit and declarative C.I.A. classifications”
27
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.
28
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.
30
Relationship of US eAuth to RBAC
31
--------------------------------
33
Typical implementations of US eAuth authentication systems are structured as follows::
35
[ MS Active Directory or other federated LDAP user store ]
37
[ SUN Identity Manager or other SAML Policy Controller ]
38
--> maps URLs to groups…
39
[ Apache Policy Agent in front of eAuth-secured Web Application ]
41
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.
43
Basic AWS API call structure
44
----------------------------
46
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:
49
* System Administrator
50
* Network Administrator
55
There is an additional, conceptual end-user that may or may not have API access:
57
* (EXTERNAL) End-user / Third-party User
59
Basic operations are available to any System User:
62
* Terminate Instance (their own)
65
* Create, Upload, Delete: Buckets and Keys (Object Store) – their own
66
* Create, Attach, Delete Volume (Block Store) – their own
68
System Administrators:
70
* Register/Unregister Machine Image (project-wide)
71
* Change Machine Image properties (public / private)
72
* Request / Review CloudAudit Scans
74
Network Administrator:
76
* Change Firewall Rules, define Security Groups
77
* Allocate, Associate, Deassociate Public IP addresses
81
* Launch and Terminate Instances (project-wide)
82
* CRUD of Object and Block store (project-wide)
86
* Register / Unregister Kernel and Ramdisk Images
87
* Register / Unregister Machine Image (any)
96
Wrapping the SAML token into the API calls.
97
Then store the UID (fetched via backchannel) into the instance metadata, providing end-to-end auditability of ownership and responsibility, without PII.
104
* Stateless asynchronous queries
106
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.
107
RBAC of CloudAudit API calls is critical, since detailed system information is a system vulnerability.
110
---------------------
111
* Data declarations – Volumes and Objects
112
* System declarations – Instances
114
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::
116
RunInstances type=m1.large number=1 secgroup=default key=mykey confidentiality=low integrity=low availability=low
118
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.)
124
* IMF Registration / PubSub
127
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.
129
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.
131
Dirty Cloud – Hybrid Data Centers
132
---------------------------------
134
* CloudAudit bridge interfaces
135
* Anything in the ARP table
137
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
139
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.
141
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.
146
* Preliminary Roles Definitions
147
* Categorization of available API calls
148
* SAML assertion vocabulary
153
The following limits need to be defined and enforced:
155
* Total number of instances allowed (user / project)
156
* Total number of instances, per instance type (user / project)
157
* Total number of volumes (user / project)
158
* Maximum size of volume
159
* Cumulative size of all volumes
160
* Total use of object storage (GB)
161
* Total number of Public IPs
166
* Prioritization of users / jobs in shared computing environments
167
* Incident response planning
168
* Limit launch of instances to specific security groups based on AMI
169
* Store AMIs in LDAP for added property control
173
The :mod:`access` Module
174
--------------------------
176
.. automodule:: nova.auth.access
181
The :mod:`signer` Module
182
------------------------
184
.. automodule:: nova.auth.signer
189
The :mod:`users` Module
190
-----------------------
192
.. automodule:: nova.auth.users
197
The :mod:`users_unittest` Module
198
--------------------------------
200
.. automodule:: nova.tests.users_unittest
205
The :mod:`access_unittest` Module
206
---------------------------------
208
.. automodule:: nova.tests.access_unittest