Managing Users and Projects
Managing Users and Projects
Basic Concepts
Users: A user is an individual or a service with login credentials to the OpenStack environment. A user has one or more roles and belongs to one or more projects.
Projects: Projects are organizational units in the cloud, and are also known as tenants or accounts. Each user is a member of one or more projects. Within a project, a user creates and manages resources such as instances and volumes. Administrators can set limits to how many resources (instances, vCPU, volumes, and more) that a project is allowed to create.
Roles: A role is a group of privileges that allow a user to perform a specific set of operations.
Groups: Groups work as the link between users and roles. A user can be a member of one or more groups and a group can have one or more roles associated with it.
Your IBM Bluemix Private Cloud installation comes with four predefined roles: cloud_admin, project_admin, _member_, and heat_stack_owner. A fifth role, heat_stack_user, is assigned automatically.
Role | Description |
---|---|
cloud_admin | This role allows cloud-level access control. It lets you perform API execution tasks, irrespective of your project. This role can create and manage quotas, groups, users and projects, and it can perform administrative volume actions. |
project_admin | This role allows project level access control. This user can perform user and project mangement within the specified project. |
_member_ | This role lets the user utilize the resources (such as instances and volumes) that are allocated for the project. |
heat_stack_owner | This role lets the user create Heat stacks in the project. This role must be assigned manually, and it never should be assigned to a user that also is assigned the heat_stack_user role. |
heat_stack_user | This is a role automatically assigned by Heat to the users it creates. This role is restricted from all API access, and it never should be assigned to any user explicitly. |
The cloud_admin
role is restricted to cloud and project management actions. A higher set of privileges is granted exclusively to the admin role, which includes administrative actions for services, domains and roles, networks, and identity providers. The admin role is restricted to IBM, and it is not granted to the customer.
With your IBM Bluemix Private Cloud installation you’ll receive one user with cloud_admin
privileges who can create other projects and users. The cloud_admin
can grant users cloud_admin
and lower privileged roles.
Identity Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Users | |||
Create user | Y | Y | N |
Update user | Y | Y | Y (Self) |
Get user | Y | Y | Y (Self) |
Delete user | Y | Y | N |
Change password | Y | Y | Y (Self) |
List user | Y | Y | N |
Roles | |||
Create role | N | N | N |
Update role | N | N | N |
Get role | Y | Y | N |
Delete role | N | N | N |
List role | Y | Y | N |
Projects | |||
Create project | Y | N | N |
Update project | Y | Y | N |
Get project | Y | Y | Y |
Delete project | Y | N | N |
List projects | Y | Y | Y (Self) |
List user projects | Y | Y | Y (Self) |
List users within projects | Y | Y | N |
Groups | |||
Create, update, or delete group | Y | N | N |
Get group | Y | Y | Y |
List groups | Y | Y | N |
List groups for user | Y | Y | Y (Self) |
List users in group | Y | Y | Y |
Add or remove user from group | Y | Y | N |
Compute Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Create instance | Y | Y | Y |
Delete instance | Y | Y | Y |
Attach network | Y | Y | Y |
Attach volume | Y | Y | Y |
Start/Stop instance | Y | Y | Y (owner) |
List instance | Y | Y | Y |
Lock/Unlock instance | Y | Y | Y (owner) |
Create flavor | Y | N | N |
Update flavor | Y | N | N |
Delete flavor | Y | N | N |
Update quotas | Y | N | N |
Delete quotas | Y | N | N |
List quotas | Y | Y | Y |
Get network IP availability | Y | N | N |
Get hosts | Y | N | N |
Volume Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Volumes | |||
Create volume | Y | Y | Y |
Extend volume | Y | Y | Y |
Get volume | Y | Y | Y |
List volumes | Y | Y | Y |
Delete volume | Y | Y | Y |
Add project access | Y | N | N |
Remove project access | Y | N | N |
Snapshots | |||
Create snapshot | Y | Y | Y |
List snapshots | Y | Y | Y |
Delete snapshot | Y | Y | Y |
Transfers | |||
Create transfer | Y | Y | Y |
Accept transfer | Y | Y | Y |
Delete transfer | Y | Y | Y |
List transfer s | Y | Y | Y |
Backups | |||
Create backup | Y | Y | Y |
Delete backup | Y | Y | Y |
List backups | Y | Y | Y |
Import backup | Y | N | N |
Export backup | Y | N | N |
Image Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Create image | Y | Y | Y |
Delete image | Y | Y | Y |
List images | Y | Y | Y |
Download image | Y | Y | Y |
Upload image | Y | Y | Y |
Publicize image | Y | N | N |
Manage image cache | N | N | N |
Network Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Create network | Y | Y | Y |
Create shared network | Y | N | N |
Update network | Y | Y | Y (owner) |
Delete network | Y | Y | Y (owner) |
Create port | Y | Y | Y |
Update port | Y | Y | Y (owner) |
Delete port | Y | Y | Y (owner) |
Create router | Y | Y | Y |
Update router | Y | Y | Y (owner) |
Delete router | Y | Y | Y (owner) |
Create subnet | Y | Y | Y (network owner) |
Update subnet | Y | Y | Y (owner) |
Delete subnet | Y | Y | Y (owner) |
Create floating IP | Y | Y | Y |
Delete floating IP | Y | Y | Y |
Object Storage Feature | cloud_admin | project_admin (within project) | _member_ |
---|---|---|---|
Accounts | |||
Create account | Y | N | N |
Delete account | Y (enabled) | N | N |
Containers | |||
Create container | Y | Y | Y |
Update container | Y | Y | Y |
Delete container | Y | Y | Y |
Objects | |||
Create object | Y | Y | Y |
Update object | Y | Y | Y |
Download object | Y | Y | Y |
Delete object | Y | Y | Y |
Requirements
This role structure requires Keystone API v3 to run. Using Keystone API v2 will result in a loss of privileges for the cloud_admin
and project_admin
roles, in addition to causing erratic permissions behavior for _member_
users.
Making API calls through the Horizon dashboard does not require any special action, but performing command line calls necessitates changes to the run command (RC) file depending on which version of IBM Bluemix Private Cloud you are running.
- In IBM Bluemix Private cloud version 2.1.1, the dashboard-generated RC files enable Keystone v2.
- Thus, in 2.1.1, switching to v3 requires changes to the standard RC file. The
OS_AUTH_URL
must be changed fromv2.0
tov3
, and theOS_IDENTITY_API_VERSION
must be created and set to3
. A sample RC file is shown below.
NOTE: With the latest update of the IBM Bluemix Private Cloud (Version 3.0.0), the Horizon dashboard will let you generate and download an Identity v3 RC file that does not require the changes highlighted above. However due to an unresolved upstream defect one modification is still required. Within the file generated by Horizon, one more line needs to be added:
Additionally, Keystone functions MUST be performed using the new python-openstackclient
CLI. This client can be installed by running sudo pip install python-openstackclient
. (There is a known issue that keystone
CLI commands currently do not function predictably as a part of V3.)
Using the Keystone v3 group function
Version 3 of the Keystone API with IBM Bluemix Private Cloud introduces the concept of groups. You can easily use groups to make multiple assignments simultaneously.
For example, you might have a support team that needs access to every project in your environment. Instead of individually adding each member to every project, you can create a group called Support, give the group the _member_
role on all of your projects, and then add all of your support staff to the group.
Another common use case would be to create a cloud_admin
group that is given the cloud_admin
role on every project on the environment. This arrangement lets the cloud_admin
elevate a user’s privileges easily, by temporarily adding them to the cloud_admin
group. It could be used in situations like vacation coverage.
You can see the difference in approach by these two illustrations.
This figure shows an example of traditional role assignments as supported by the Keystone v2 API. The cloud_admin
user has the cloud_admin
role for Project 1, Project 2, and Project 3. User 1 has the project_admin
role for Project 2. User 2 and Support User 1 have the _member_
role for Project 2. Support User 1 also has the _member_
role for Project 3.
Consequences of disabling projects
Users with the cloud_admin
role can enable and disable projects. When you disable a project, it has these consequences:
- In the dashboard, users no longer have access to the project from the CURRENT PROJECT list on the Project tab.
- Users who are members of only the disabled project can no longer log in.
- You cannot launch instances for a disabled project. Instances that are running already are not terminated automatically. You must stop them manually.
- The data for a disabled project is maintained so that you can re-enable the project at any time.
Using the dashboard
The next section tells you how to use the dashboard to add, update, modify, and delete a project or a user account.
Adding a project
- In the navigation bar, open the Identity panel and click on Projects.
- Click Create Project.
- On the Project Information tab in the Create Project window, enter a name and description for the project. By default, the project is enabled.
- On the Project Members tab, add members to the project and assign the appropriate roles.
- On the Project Groups tab, add groups of users to the project and assign the appropriate roles.
- On the Quota tab, edit quota values.
- Click Create Project. The Projects list shows the project, including its assigned ID.
Updating a project
You can update a project to change its name or description, and to enable or temporarily disable it.
- In the navigation bar, open the Identity panel and click on Projects.
- Select the project that you want to update.
- Select Edit Project from the drop down list under the Actions column.
- In the Edit Project window, you can update a project to change its name or description, and to enable or temporarily disable it. By default, the project is enabled. To temporarily disable it, clear the Enabled check box. To enable a disabled project, select the Enabled check box.
- Click Save.
Modifying user assignments for a project
If you have the cloud_admin
role you can assign roles on any project. If you have the project_admin
role you can modify assignments on projects where you have the project_admin
role applied.
- In the navigation bar, open the Identity panel and click on Projects.
- Click the Manage Members button for the project that you want to modify.
The Edit Project window shows these lists of users:
- All Users: Users that are available to be assigned to the current project.
- Project Members: Users that are assigned to the current project. You can also assign groups of users in the Project Groups tab.
Deleting projects
- In the navigation bar, open the Identity panel and click on Projects.
- Select the projects that you want to delete.
- Click Delete Projects to confirm the deletion.
Creating a user account
If you have the cloud_admin
or project_admin
roles, you can create new user accounts. When you create a user account, you must assign the account to a primary project. You also have the option of assigning the account to additional projects.
- In the navigation bar, open the Identity panel and click on Users.
- Click Create User.
- In the Create User window, enter a user name, email, and preliminary password for the user. Confirm the password. Select a project from the Primary Project list. Choose a role for the user from the Role list. Default is
_member_
. - Click Create User to confirm your changes. The dashboard assigns an ID to the user, and the user appears in the Users category.
Disabling or enabling a user
If you have the cloud_admin
or the project_admin
role you can enable and disable user accounts. When you disable a user account, the user can no longer log in. However, the data for the user is maintained so that you can re-enable the user at any time.
- In the navigation bar, open the Identity panel and click on Users.
- Locate the user that you want to disable or enable in the Users list.
- Select Disable User or Enable User from the drop down list under the Actions column. In the Enabled column, the enabled value updates to either Yes or No.