← Back to branch summary

~ubuntu-branches/ubuntu/saucy/nova/saucy-proposed

« back to all changes in this revision

Viewing changes to doc/source/runnova/managing.users.rst

  • Committer: Package Import Robot
  • Author(s): Chuck Short
  • Date: 2012-05-24 13:12:53 UTC
  • mfrom: (1.1.55)
  • Revision ID: package-import@ubuntu.com-20120524131253-ommql08fg1en06ut
Tags: 2012.2~f1-0ubuntu1
https://launchpad.net/bugs/907197
* New upstream release.
* Prepare for quantal:
  - Dropped debian/patches/upstream/0006-Use-project_id-in-ec2.cloud._format_image.patch
  - Dropped debian/patches/upstream/0005-Populate-image-properties-with-project_id-again.patch
  - Dropped debian/patches/upstream/0004-Fixed-bug-962840-added-a-test-case.patch
  - Dropped debian/patches/upstream/0003-Allow-unprivileged-RADOS-users-to-access-rbd-volumes.patch
  - Dropped debian/patches/upstream/0002-Stop-libvirt-test-from-deleting-instances-dir.patch
  - Dropped debian/patches/upstream/0001-fix-bug-where-nova-ignores-glance-host-in-imageref.patch 
  - Dropped debian/patches/0001-fix-useexisting-deprecation-warnings.patch
* debian/control: Add python-keystone as a dependency. (LP: #907197)
* debian/patches/kombu_tests_timeout.patch: Refreshed.
* debian/nova.conf, debian/nova-common.postinst: Convert to new ini
  file configuration
* debian/patches/nova-manage_flagfile_location.patch: Refreshed

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/source/runnova/managing.users.rst
1
 
Managing Users
2
 
==============
3
 
 
4
 
 
5
 
Users and Access Keys
6
 
---------------------
7
 
 
8
 
Access to the ec2 api is controlled by an access and secret key.  The user's access key needs to be included in the request, and the request must be signed with the secret key.  Upon receipt of api requests, nova will verify the signature and execute commands on behalf of the user.
9
 
 
10
 
In order to begin using nova, you will need a to create a user.  This can be easily accomplished using the user create or user admin commands in nova-manage. `user create` will create a regular user, whereas `user admin` will create an admin user. The syntax of the command is nova-manage user create username [access] [secret]. For example::
11
 
 
12
 
  nova-manage user create john my-access-key a-super-secret-key
13
 
 
14
 
If you do not specify an access or secret key, a random uuid will be created automatically.
15
 
 
16
 
Credentials
17
 
-----------
18
 
 
19
 
Nova can generate a handy set of credentials for a user.  These credentials include a CA for bundling images and a file for setting environment variables to be used by euca2ools.  If you don't need to bundle images, just the environment script is required.  You can export one with the `project environment` command.  The syntax of the command is nova-manage project environment project_id user_id [filename]. If you don't specify a filename, it will be exported as novarc.  After generating the file, you can simply source it in bash to add the variables to your environment::
20
 
 
21
 
  nova-manage project environment john_project john
22
 
  . novarc
23
 
 
24
 
If you do need to bundle images, you will need to get all of the credentials using `project zipfile`. Note that zipfile will give you an error message if networks haven't been created yet.  Otherwise zipfile has the same syntax as environment, only the default file name is nova.zip.  Example usage::
25
 
 
26
 
  nova-manage project zipfile john_project john
27
 
  unzip nova.zip
28
 
  . novarc
29
 
 
30
 
Role Based Access Control
31
 
-------------------------
32
 
Roles control the api actions that a user is allowed to perform.  For example, a user cannot allocate a public ip without the `netadmin` role. It is important to remember that a users de facto permissions in a project is the intersection of user (global) roles and project (local) roles.  So for john to have netadmin permissions in his project, he needs to separate roles specified.  You can add roles with `role add`.  The syntax is nova-manage role add user_id role [project_id]. Let's give john the netadmin role for his project::
33
 
 
34
 
  nova-manage role add john netadmin
35
 
  nova-manage role add john netadmin john_project
36
 
 
37
 
Role-based access control (RBAC) is an approach to restricting system access to authorized users based on an individual’s role within an organization.  Various employee functions require certain levels of system access in order to be successful.  These functions are mapped to defined roles and individuals are categorized accordingly.  Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of assigning appropriate roles to the user.  This simplifies common operations, such as adding a user, or changing a user's department.
38
 
 
39
 
Nova’s rights management system employs the RBAC model and currently supports the following five roles:
40
 
 
41
 
* **Cloud Administrator.**  (cloudadmin) Users of this class enjoy complete system access.
42
 
* **IT Security.** (itsec) This role is limited to IT security personnel.  It permits role holders to quarantine instances.
43
 
* **System Administrator.** (sysadmin) The default for project owners, this role affords users the ability to add other users to a project, interact with project images, and launch and terminate instances.
44
 
* **Network Administrator.** (netadmin) Users with this role are permitted to allocate and assign publicly accessible IP addresses as well as create and modify firewall rules.
45
 
* **Developer.**  (developer) This is a general purpose role that is assigned to users by default.
46
 
 
47
 
RBAC management is exposed through the dashboard for simplified user management.
48
 
 
49
 
 
50
 
User Commands
51
 
~~~~~~~~~~~~~
52
 
 
53
 
Users, including admins, are created through the ``user`` commands.
54
 
 
55
 
* user admin: creates a new admin and prints exports
56
 
    * arguments: name [access] [secret]
57
 
* user create: creates a new user and prints exports
58
 
    * arguments: name [access] [secret]
59
 
* user delete: deletes an existing user
60
 
    * arguments: name
61
 
* user exports: prints access and secrets for user in export format
62
 
    * arguments: name
63
 
* user list: lists all users
64
 
    * arguments: none
65
 
* user modify: update a users keys & admin flag
66
 
    *  arguments: accesskey secretkey admin
67
 
    *  leave any field blank to ignore it, admin should be 'T', 'F', or blank
68
 
 
69
 
 
70
 
User Role Management
71
 
~~~~~~~~~~~~~~~~~~~~
72
 
 
73
 
* role add: adds role to user
74
 
    * if project is specified, adds project specific role
75
 
    * arguments: user, role [project]
76
 
* role has: checks to see if user has role
77
 
    * if project is specified, returns True if user has
78
 
      the global role and the project role
79
 
    * arguments: user, role [project]
80
 
* role remove: removes role from user
81
 
    * if project is specified, removes project specific role
82
 
    * arguments: user, role [project]