The OpenStack Dashboard provides a graphical interface to manage users. This section describes user management with the Dashboard.
You can also manage projects, users, and roles from the command-line clients.
In addition, many sites write custom tools for local needs to enforce local policies and provide levels of self-service to users that are not currently available with packaged tools.
To create a user, you need the following information:
Username and email address are self-explanatory, though your site may have local conventions you should observe. The primary project is simply the first project the user is associated with and must exist prior to creating the user. Role is almost always going to be “member.” Out of the box, OpenStack comes with two roles defined:
It is possible to define other roles, but doing so is uncommon.
Once you’ve gathered this information, creating the user in the dashboard is just another web form similar to what we’ve seen before and can be found by clicking the Users link in the Identity navigation bar and then clicking the Create User button at the top right.
Modifying users is also done from this Users page. If you have a large number of users, this page can get quite crowded. The Filter search box at the top of the page can be used to limit the users listing. A form very similar to the user creation dialog can be pulled up by selecting Edit from the actions drop-down menu at the end of the line for the user you are modifying.
Many sites run with users being associated with only one project. This is a more conservative and simpler choice both for administration and for users. Administratively, if a user reports a problem with an instance or quota, it is obvious which project this relates to. Users needn’t worry about what project they are acting in if they are only in one project. However, note that, by default, any user can affect the resources of any other user within their project. It is also possible to associate users with multiple projects if that makes sense for your organization.
Associating existing users with an additional project or removing them from an older project is done from the Projects page of the dashboard by selecting Manage Members from the Actions column, as shown in the screenshot below.
From this view, you can do a number of useful things, as well as a few dangerous ones.
The first column of this form, named All Users, includes a list of all the users in your cloud who are not already associated with this project. The second column shows all the users who are. These lists can be quite long, but they can be limited by typing a substring of the username you are looking for in the filter field at the top of the column.
From here, click the + icon to add users to the project. Click the - to remove them.
The dangerous possibility comes with the ability to change member roles.
This is the dropdown list below the username in the
Project Members list. In virtually all cases,
this value should be set to Member. This example purposefully
shows an administrative user where this value is
The admin is global, not per project, so granting a user the
role in any project gives the user administrative rights across the
Typical use is to only create administrative users in a single project, by convention the admin project, which is created by default during cloud setup. If your administrative users also use the cloud to launch and manage instances, it is strongly recommended that you use separate user accounts for administrative access and normal operations and that they be in distinct projects.
Users on your cloud can disrupt other users, sometimes intentionally and maliciously and other times by accident. Understanding the situation allows you to make a better decision on how to handle the disruption.
For example, a group of users have instances that are utilizing a large amount of compute resources for very compute-intensive tasks. This is driving the load up on compute nodes and affecting other users. In this situation, review your user use cases. You may find that high compute scenarios are common, and should then plan for proper segregation in your cloud, such as host aggregation or regions.
Another example is a user consuming a very large amount of bandwidth. Again, the key is to understand what the user is doing. If she naturally needs a high amount of bandwidth, you might have to limit her transmission rate as to not affect other users or move her to an area with more bandwidth available. On the other hand, maybe her instance has been hacked and is part of a botnet launching DDOS attacks. Resolution of this issue is the same as though any other server on your network has been hacked. Contact the user and give her time to respond. If she doesn’t respond, shut down the instance.
A final example is if a user is hammering cloud resources repeatedly. Contact the user and learn what he is trying to do. Maybe he doesn’t understand that what he’s doing is inappropriate, or maybe there is an issue with the resource he is trying to access that is causing his requests to queue or lag.