updates to auth, concepts, and network, fix of docstring
This commit is contained in:
Vishvananda Ishaya
parent
55a0cfc96b
commit
0211ec7d61
@ -1,6 +1,6 @@
|
||||
..
|
||||
Copyright 2010 United States Government as represented by the
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
All Rights Reserved.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
@ -15,9 +15,10 @@
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
|
||||
Auth Documentation
|
||||
==================
|
||||
.. _auth:
|
||||
|
||||
Auth Documentation
|
||||
==================
|
||||
|
||||
from etherpad todo
|
||||
------------------
|
||||
@ -39,7 +40,7 @@ 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.
|
||||
@ -54,24 +55,26 @@ Typical implementations of US eAuth authentication systems are structured as fol
|
||||
[ SUN Identity Manager or other SAML Policy Controller ]
|
||||
--> maps URLs to groups…
|
||||
[ Apache Policy Agent in front of eAuth-secured Web Application ]
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Basic AWS API call structure
|
||||
----------------------------
|
||||
.. _auth_roles:
|
||||
|
||||
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:
|
||||
Roles
|
||||
-----
|
||||
|
||||
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:
|
||||
|
||||
* System User
|
||||
* System Administrator
|
||||
* Network Administrator
|
||||
* Project Manager
|
||||
* Cloud Administrator
|
||||
* (IT-Sec?)
|
||||
* IT-Security
|
||||
|
||||
There is an additional, conceptual end-user that may or may not have API access:
|
||||
There is an additional, conceptual end-user that may or may not have API access:
|
||||
|
||||
* (EXTERNAL) End-user / Third-party User
|
||||
* (EXTERNAL) End-user / Third-party User
|
||||
|
||||
Basic operations are available to any System User:
|
||||
|
||||
@ -106,7 +109,7 @@ Cloud Administrator:
|
||||
Enhancements
|
||||
------------
|
||||
|
||||
* SAML Token passing
|
||||
* SAML Token passing
|
||||
* REST interfaces
|
||||
* SOAP interfaces
|
||||
|
||||
@ -151,7 +154,7 @@ Dirty Cloud – Hybrid Data Centers
|
||||
* CloudAudit bridge interfaces
|
||||
* Anything in the ARP table
|
||||
|
||||
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
|
||||
A hybrid cloud environment provides dedicated, potentially co-located physical hardware with a network interconnect to the project or users’ cloud virtual network.
|
||||
|
||||
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.
|
||||
|
||||
@ -167,7 +170,7 @@ The Details
|
||||
System limits
|
||||
-------------
|
||||
|
||||
The following limits need to be defined and enforced:
|
||||
The following limits need to be defined and enforced:
|
||||
|
||||
* Total number of instances allowed (user / project)
|
||||
* Total number of instances, per instance type (user / project)
|
||||
@ -195,18 +198,18 @@ The :mod:`signer` Module
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`users` Module
|
||||
The :mod:`auth` Module
|
||||
-----------------------
|
||||
|
||||
.. automodule:: nova.auth.users
|
||||
.. automodule:: nova.auth.manager
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`users_unittest` Module
|
||||
The :mod:`auth_unittest` Module
|
||||
--------------------------------
|
||||
|
||||
.. automodule:: nova.tests.users_unittest
|
||||
.. automodule:: nova.tests.auth_unittest
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
@ -219,4 +222,11 @@ The :mod:`access_unittest` Module
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
The :mod:`ec2` Module
|
||||
------------------------
|
||||
|
||||
.. automodule:: nova.api.ec2
|
||||
:members:
|
||||
:undoc-members:
|
||||
:show-inheritance:
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
..
|
||||
Copyright 2010 United States Government as represented by the
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
All Rights Reserved.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
@ -61,25 +61,33 @@ Concept: Virtualization
|
||||
* qemu
|
||||
|
||||
|
||||
Concept: Instances
|
||||
------------------
|
||||
|
||||
An 'instance' is a word for a virtual machine that runs inside the cloud.
|
||||
|
||||
Concept: Volumes
|
||||
----------------
|
||||
|
||||
Volumes
|
||||
A 'volume' is a detachable block storage device. You can think of it as a usb hard drive. It can only be attached to one instance at a time, and it behaves
|
||||
|
||||
|
||||
Concept: Quotas
|
||||
---------------
|
||||
|
||||
* Defaults
|
||||
* Override for project
|
||||
Nova supports per-project quotas. There are currently quotas for number of instances, total number of cores, number of volumes, total number of gigabytes, and number of floating ips.
|
||||
|
||||
|
||||
Concept: RBAC
|
||||
-------------
|
||||
|
||||
* Intersecting Roles
|
||||
* cloudadmin vs. user admin flag
|
||||
Nova provides roles based access control (RBAC) for access to api commands. A user can have a number of different :ref:`roles <auth_roles>`. Roles define which api_commands a user can perform.
|
||||
|
||||
It is important to know that there are user-specific (sometimes called global) roles and project-specific roles. A user's actual permissions in a particular project are the INTERSECTION of his user-specific roles and is project-specific roles.
|
||||
|
||||
For example: A user can access api commands allowed to the netadmin role (like allocate_address) only if he has the user-specific netadmin role AND the project-specific netadmin role.
|
||||
|
||||
More information about RBAC can be found in the :ref:`auth`.
|
||||
|
||||
Concept: API
|
||||
------------
|
||||
@ -91,14 +99,31 @@ Concept: API
|
||||
Concept: Networking
|
||||
-------------------
|
||||
|
||||
* VLAN
|
||||
* Cloudpipe
|
||||
* Certificates (See also: CA)
|
||||
* Flat Networking
|
||||
* Flat with DHCP
|
||||
* How to generate addresses
|
||||
* Floating Addresses
|
||||
Nova has a concept of Fixed Ips and Floating ips. Fixed ips are assigned to an instance on creation and stay the same until the instance is explicitly terminated. Floating ips are ip addresses that can be dynamically associated with an instance. This address can be disassociated and associated with another instance at any time.
|
||||
|
||||
There are multiple strategies available for implementing fixed ips:
|
||||
|
||||
Flat Mode
|
||||
^^^^^^^^^
|
||||
|
||||
The simplest networking mode. Each instance receives a fixed ip from the pool. All instances are attached to the same bridge (br100) by default. The bridge must be configured manually. The networking configuration is injected into the instance before it is booted. Note that this currently only works on linux-style systems that keep networking configuration in /etc/network/interfaces.
|
||||
|
||||
Flat DHCP Mode
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This is similar to the flat mode, in that all instances are attached to the same bridge. In this mode nova does a bit more configuration, it will attempt to bridge into an ethernet device (eth0 by default). It will also run dnsmasq as a dhcpserver listening on this bridge. Instances receive their fixed ips by doing a dhcpdiscover.
|
||||
|
||||
VLAN DHCP Mode
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This is the default networking mode and supports the most features. For multiple machine installation, it requires a switch that supports host-managed vlan tagging. In this mode, nova will create a vlan and bridge for each project. The project gets a range of private ips that are only accessible from inside the vlan. In order for a user to access the instances in their project, a special vpn instance (code name cloudpipe) needs to be created. Nova generates a certificate and key for the userto access the vpn and starts the vpn automatically.
|
||||
|
||||
The following diagram illustrates how the communication that occurs between the vlan (the dashed box) and the public internet (represented by the two clouds)
|
||||
|
||||
.. image:: /images/cloudpipe.png
|
||||
:width: 100%
|
||||
|
||||
..
|
||||
|
||||
Concept: Services
|
||||
-----------------
|
||||
@ -114,7 +139,7 @@ Concept: Services
|
||||
Concept: nova-manage
|
||||
--------------------
|
||||
|
||||
nova manage
|
||||
nova-manage is a command line utility for performing administrative tasks and checking on the health of the system.
|
||||
|
||||
|
||||
Concept: Flags
|
||||
|
||||
@ -16,7 +16,7 @@ import sys, os
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
sys.path.append([os.path.abspath('../nova'), os.path.abspath('..'), os.path.abspath('../bin')])
|
||||
sys.path.append([os.path.abspath('../../'), os.path.abspath('../../bin')])
|
||||
|
||||
|
||||
# -- General configuration -----------------------------------------------------
|
||||
|
||||
BIN
doc/source/images/cloudpipe.png
Normal file
BIN
doc/source/images/cloudpipe.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 88 KiB |
@ -1,6 +1,6 @@
|
||||
..
|
||||
Copyright 2010 United States Government as represented by the
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
Administrator of the National Aeronautics and Space Administration.
|
||||
All Rights Reserved.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
@ -43,65 +43,65 @@ Components
|
||||
----------
|
||||
There are several key components:
|
||||
|
||||
* NetworkController (Manages address and vlan allocation)
|
||||
* NetworkController (Manages address and vlan allocation)
|
||||
* RoutingNode (NATs public IPs to private IPs, and enforces firewall rules)
|
||||
* AddressingNode (runs DHCP services for private networks)
|
||||
* BridgingNode (a subclass of the basic nova ComputeNode)
|
||||
* TunnelingNode (provides VPN connectivity)
|
||||
|
||||
|
||||
Component Diagram
|
||||
-----------------
|
||||
|
||||
Overview::
|
||||
|
||||
(PUBLIC INTERNET)
|
||||
(PUBLIC INTERNET)
|
||||
| \
|
||||
/ \ / \
|
||||
[RoutingNode] ... [RN] [TunnelingNode] ... [TN]
|
||||
| \ / | |
|
||||
| < AMQP > | |
|
||||
[AddressingNode]-- (VLAN) ... | (VLAN)... (VLAN) --- [AddressingNode]
|
||||
[AddressingNode]-- (VLAN) ... | (VLAN)... (VLAN) --- [AddressingNode]
|
||||
\ | \ /
|
||||
/ \ / \ / \ / \
|
||||
[BridgingNode] ... [BridgingNode]
|
||||
|
||||
|
||||
|
||||
|
||||
[NetworkController] ... [NetworkController]
|
||||
\ /
|
||||
< AMQP >
|
||||
|
|
||||
/ \
|
||||
[CloudController]...[CloudController]
|
||||
[CloudController]...[CloudController]
|
||||
|
||||
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).
|
||||
While this diagram may not make this entirely clear, nodes and controllers communicate exclusively across the message bus (AMQP, currently).
|
||||
|
||||
State Model
|
||||
-----------
|
||||
Network State consists of the following facts:
|
||||
|
||||
* VLAN assignment (to a project)
|
||||
* Private Subnet assignment (to a security group) in a VLAN
|
||||
* Private Subnet assignment (to a security group) in a VLAN
|
||||
* Private IP assignments (to running instances)
|
||||
* Public IP allocations (to a project)
|
||||
* Public IP associations (to a private IP / running instance)
|
||||
|
||||
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP). The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.
|
||||
While copies of this state exist in many places (expressed in IPTables rule chains, DHCP hosts files, etc), the controllers rely only on the distributed "fact engine" for state, queried over RPC (currently AMQP). The NetworkController inserts most records into this datastore (allocating addresses, etc) - however, individual nodes update state e.g. when running instances crash.
|
||||
|
||||
The Public Traffic Path
|
||||
-----------------------
|
||||
|
||||
|
||||
Public Traffic::
|
||||
|
||||
(PUBLIC INTERNET)
|
||||
|
|
||||
<NAT> <-- [RoutingNode]
|
||||
<NAT> <-- [RoutingNode]
|
||||
|
|
||||
[AddressingNode] --> |
|
||||
( VLAN )
|
||||
( VLAN )
|
||||
| <-- [BridgingNode]
|
||||
|
|
||||
<RUNNING INSTANCE>
|
||||
<RUNNING INSTANCE>
|
||||
|
||||
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.
|
||||
The RoutingNode is currently implemented using IPTables rules, which implement both NATing of public IP addresses, and the appropriate firewall chains. We are also looking at using Netomata / Clusto to manage NATting within a switch or router, and/or to manage firewall rules within a hardware firewall appliance.
|
||||
|
||||
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).
|
||||
Similarly, the AddressingNode currently manages running DNSMasq instances for DHCP services. However, we could run an internal DHCP server (using Scapy ala Clusto), or even switch to static addressing by inserting the private address into the disk image the same way we insert the SSH keys. (See compute for more details).
|
||||
|
||||
@ -89,7 +89,6 @@ class AuthBase(object):
|
||||
This method will return the id of the object if the object
|
||||
is of this class, otherwise it will return the original object.
|
||||
This allows methods to accept objects or ids as paramaters.
|
||||
|
||||
"""
|
||||
if isinstance(obj, cls):
|
||||
return obj.id
|
||||
|
||||
Loading…
Reference in New Issue
Block a user