In the OpenStack user interface and some documents, sometimes you see "project" as a group of users, and sometimes you see it as a substitute for "tenant", both of which can be used for general purposes.
2. Manage the project
A user must belong to at least one project, or it can belong to multiple projects. Therefore, you should add at least one item and then add the user.
2.1 Adding items
To create a project from a dashboard:
Log on with the administrator user.
Select the Project button in the left navigation bar.
In the upper-right corner, click the "Create Item" button.
This will pop up a dialog box with the project name and an optional description, and a check box at the bottom to set the status of the item, which is turned on by default.
The interface lets you see the quota for adding project members and adjusting items. After we have discussed these, we are making changes, of course, you can also handle the above operation at once.
To create a project (CLI) from the command line:
To add a project from the command line, you need to use the Keystone tool and "tenant" instead of "project":
# Keystone Tenant-create--name=demo
This will create a new project named "Demo". It is useful to add a few descriptions with the –description <tenant-description> parameters. You can also create a disabled tenant with the –enable false parameter, and do not specify the default open state.
# Keystone Help Tenant-create
You can also get help for this command.
2.2 Quotas
OpenStack provides a large number of quota options and is intended for tenants (not users). As a management user you can see (but not edit) a default quota for the quota navigation bar in the dashboard.
These default project quotas are default on the cloud controller nova.conf.
If you do not change the quota limit, the following default quotas are used.
Description of quota configuration options in nova.conf file:
Option default value (type) description
Quota_cores=20 (intopt) The number of CPU cores allowed to be used by tenants
QUOTA_FLOATING_IPS=10 (intopt) allows tenants to use the number of floating IP
quota_gigabytes=1000 (intopt) Set the tenant's network bandwidth
quota_injected_file_content_bytes=10240 (intopt) number of bytes allowed to inject files
quota_injected_file_path_bytes=255 (intopt) The number of bytes allowed to inject a file path
Quota_injected_files=5 (intopt) Number of files allowed to be injected
QUOTA_INSTANCES=10 (intopt) allows tenants to create the number of instances
QUOTA_KEY_PAIRS=100 (intopt) allows the number of key pairs per user
quota_metadata_items=128 (intopt) allows the number of metadata items per instance
QUOTA_RAM=51200 (intopt) allows the tenant to use the size of memory
QUOTA_SECURITY_GROUP_RULES=20 (intopt) number of rules in each security group
quota_security_groups=10 (intopt) Number of security groups created per tenant
quota_volumes=10 (intopt) Number of logical volumes used per tenant
Additional configuration options (http://docs.openstack.org/folsom/openstack-compute/admin/content/list-of-compute-config-options.html)
The easiest way to change the default project quota is to edit the nova.conf file on your cloud controller. Quotas are performed by the Nova-schedler service, so once you change the default quota option, you must restart the service.
To view and edit quotas for individual items through a dashboard:
Use the Project navigation button link to obtain a list of your existing items.
Locate the item you want to modify and select "Modify Quotas" from the Drop-down menu, modify the appropriate quota, and then click "Save" to complete the change.
To view and edit quotas for individual items by command line, follow these steps: You can access and modify quotas at the command-line, but this is a bit complicated. This is done by using Keystone to get the tenant's ID, and then using Nova-manage to view it.
1. To list quotas for a project, you must first use the Keystone Client tool to find its ID:
# Keystone Tenant-list | grep <tenant-name>
98333a1a28e746fa8c629c83a818ad57 | <tenant-name> | True |
2. In order to view the project quota, we must use the ID obtained in the example above:
# Nova-manage Project Quota 98333a1a28e746fa8c629c83a818ad57
metadata_items:128
Volumes:10
gigabytes:1000
ram:6291456
Security_group_rules:20
instances:1024
Security_groups:10
injected_file_content_bytes:10240
Floating_ips:10
Injected_files:5
cores:2048
Note: The ID must be specified after Nova-manage project quota, and the entry name will be an error.
Now to increase the number of floating_ips to 20, we can use –key and –value to increase the number of IP:
# nova-manage Project Quota 98333a1a28e746fa8c629c83a818ad57--key floating_ips--value 20
metadata_items:128
Volumes:10
gigabytes:1000
ram:6291456
Security_group_rules:20
instances:1024
Security_groups:10
injected_file_content_bytes:10240
Floating_ips:20
Injected_files:5
cores:2048
3, User management
It is very inconvenient for users to manage users on the command line. You need more than one command to complete a task, and if you use a UUID instead of a symbolic name. In practice, people usually do not use the command line to manage users.
Fortunately, the OpenStack dashboard provides a reasonable interface. In addition, custom scripts written by many Web sites may also be appropriate for you.
3.1 Creating users
To create a new user, you will need the following information:
User name
Mailbox
Password
Main projects
Role
User name and email are self-evident, setting and changing the Password Authentication Service requires administrator privileges.
In the Folsom version, the user cannot change his or her password. After you create the user and password, you must keep in mind the assigned username and password. The project must exist before a user is created.
The optional roles include
"Member": a typical user.
Admin: Super Admin user, in all projects, you should use it sparingly.
You can define other roles, but rarely do so.
Create a user just a Web form on the dashboard, the user link is on the Admin navigation bar, and then click the Create User button in the upper-right corner.
Modify the user also from the "Users" page. If you have a large number of users, this page will be very crowded. At the top of the page there is "Filter" that you can use to search for a list of related users, similar to the Create User dialog box, through the Edit
or Drop-down menu to modify the user information.
3.2 Associating users to projects
Users can associate a project, or they can associate multiple items.
On the Dashboard project page, you can associate existing users to an additional item or delete them from an old project by selecting the "Project" page on the dashboard "Modify user":
All users of this project will be listed in the "All Users" table. Too many users, the display may be very long, at the top of the filter can be limited to enter the user name to search.
Click on "+" to add a user to the item and then click "-" to delete them.
The danger here is that the role of the member may be changed. In the Drop-down list after the user name in the Project members list, in general, this value should be set to "member", which is intended to indicate that the administrator user value is "admin". It is very important that "admin" is a global user, not every project, so granting the user Admin role is tantamount to giving the user the right to manage the entire cloud in any project.
3.3 Custom Authorization (policy)
In simple terms, policy is used to control the permissions of a user in a tenant. What the user can do, what not to do, is done through the policy mechanism. Intuitively, policy is a JSON file, located in/etc/[service_codename]/policy.json, each service has a corresponding Policy.json file, through the configuration of this file, to achieve user rights management.
For example, two lines in a Policy.json file:
...
"Admin_or_owner": [["Is_admin:true"], ["project_id:% (PROJECT_ID) S"]],
"Compute:create": [["Rule:admin_or_owner"]],
...
This is the policy that defines the creation of a virtual machine operation. Indicates that only users within admin or tenant can create virtual machine operations.
The default authorization setting allows only administrative users to create project resources that represent no use. OpenStack handles two types of authorization policies:
Based on actions: Policies specify access rights for specific actions.
Resource based: Whether access to a specific resource may be authorized based on the permissions of the configured resource.
The policy engine reads the entries for the Policy.json file. The actual location of this file may be different, it is usually in/etc/nova/policy.json. When the system is running, you can update the entries without restarting the service.
The only way to update these currently is to edit the policy file.
The policy engine of the OpenStack service directly matches the policy, and a rule indicates the elements of these policies. For example, in a compute:create:[["Rule:admin_or_owner"] statement, this policy is compute:create and the rule is admin_or_owner.
An authorization policy can consist of one or more rules.
Rules:
Role-based rule: The user who successfully submits the request has the specified role. For example, the need for Administrator role "Role:admin" is successful.
Field Rules: Evaluates success if the resource specified by the field matches a specific value at the current request. For example, the Field:networks:shared=true shared network resource is set to true.
Common rules: Comparing attributes to a property extracted from the user's security credentials and evaluating the outcome of the resource is relatively successful. For example, "tenant_id:% (tenant_id) S" is successful if the tenant identifier in the resource equals the tenant identity user submitting the request.
The following is the contents of a default Policy.json file in Nova:
[1] A rule if the current user is the administrator or the owner of the requested resource (tenant identification story, etc.).
[2] The default policy, if the API operation does not match any of the policies in Policy.json, always evaluates this policy.
[3] A policy that only allows administrators to manipulate flavors when using the administration APIs.
In many cases, when users destroy other users in your cloud, sometimes deliberately and maliciously, others can be unexpected. Knowing the situation allows you to make better decisions about how to handle it.
For example: A group of users with very computationally intensive tasks, using a large number of computational resources. At this point, the compute node of the load affects other users. In this case, see what your users are using. In this case, high-density computing schemes are common and can be used to aggregate your cloud hosts or should be properly planned for isolation.
Another example is a user consuming a very large amount of bandwidth. Again, the key is to understand what the user is doing. If they naturally require a large amount of bandwidth, you may want to limit their transfer rates so that they do not affect other users or move them to more available bandwidth in one area. On the other hand, perhaps the user's instance is hacked and a DDoS attack is launched as part of a botnet. The solution to this problem is the same if any other server on the network has been hacked. Contact users so they have time to respond. If they do not respond, close the instance.
The last example is if a user uses the cloud resources over and over again. Contact users and learn what they are trying to do. Perhaps they do not understand what they are doing is inappropriate or may have problems with the resources they are trying to access that are causing them to request queues or lag.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
