Keystone角色配置

Basic Concepts

The Identity services has two primary functions:

1. User management: keep track of users and what they are permitted to do

2. Service catalog: Provide a catalog of what services are available and where their API endpoints are located

 User management

The three main concepts of Identity user management are:

• Users

• Tenants

• Roles

A user represents a human user, and has associated information such as username, password and email. This example creates a user named "alice":

$ keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com

A tenant can be thought of as a project, group, or organization. Whenever you make requests to OpenStack services, you must specify a tenant. For example, if you query the Compute service for a list of running instances, you will receive a list of all of the running instances in the tenant you specified in your query. This example creates a tenant named "acme":

$ keystone tenant-create --name=acmeNote

Because the term project was used in instead of tenant in earlier versions of OpenStack Compute, some command-line tools use --project_id instead of --tenant_id to refer to a tenant ID.

A role captures what operations a user is permitted to perform in a given tenant. This example creates a tenant named "compute-user":

$ keystone role-create --name=compute-userNote

It is up to individual services such as the Compute service and Image service to assign meaning to these roles. As far as the Identity service is concerned, a role is simply a name.

The Identity service associates a user with a tenant and a role. To continue with our previous examples, we may wish to assign the "alice" user the "compute-user" role in the "acme" tenant:

$ keystone user-list
+----------------------------------+---------+-------+--------+
| id | enabled | email | name |
+----------------------------------+---------+-------+--------+
| 96a6ebba0d4c441887aceaeced892585 | True | ... | alice |
+----------------------------------+---------+-------+--------+
$ keystone role-list
+----------------------------------+--------------+
| id | name |
+----------------------------------+--------------+
| f8dd5a2e4dc64a41b96add562d9a764e | compute-user |
+----------------------------------+--------------+
$ keystone tenant-list
+----------------------------------+--------------+---------+
| id | name | enabled |
+----------------------------------+--------------+---------+
| 2395953419144b67955ac4bab96b8fd2 | acme | True |
+----------------------------------+--------------+---------+
$ keystone user-role-add \
--user=96a6ebba0d4c441887aceaeced892585 \
--role=f8dd5a2e4dc64a41b96add562d9a764e \
--tenant_id=2395953419144b67955ac4bab96b8fd2

A user can be assigned different roles in different tenants: for example, Alice may also have the "admin" role in the "Cyberdyne" tenant. A user can also be assigned multiple roles in the same tenant.

The /etc/[SERVICE_CODENAME]/policy.json controls what users are allowed to do for a given service. For example, /etc/nova/policy.json specifies the access policy for the Compute service, /etc/glance/policy.json specifies the access policy for the Image service, and /etc/keystone/policy.json specifies the access policy for the Identity service.

The default policy.json files in the Compute, Identity, and Image service recognize only the admin role: all operations that do not require the admin role will be accessible by any user that has any role in a tenant.

If you wish to restrict users from performing operations in, say, the Compute service, you need to create a role in the Identity service and then modify /etc/nova/policy.json so that this role is required for Compute operations.

For example, this line in /etc/nova/policy.json specifies that there are no restrictions on which users can create volumes: if the user has any role in a tenant, they will be able to create volumes in that tenant.

1"volume:create":[],

If we wished to restrict creation of volumes to users who had the compute-user role in a particular tenant, we would add "role:compute-user", like so:

1"volume:create":["role:compute-user"],

If we wished to restrict all Compute service requests to require this role, the resulting file would look like:

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102{    "admin_or_owner":  [["role:admin"], ["project_id:%(project_id)s"]],    "default":[["rule:admin_or_owner"]],      "compute:create": ["role":"compute-user"],    "compute:create:attach_network": ["role":"compute-user"],    "compute:create:attach_volume": ["role":"compute-user"],    "compute:get_all": ["role":"compute-user"],      "admin_api":[["role:admin"]],    "compute_extension:accounts":[["rule:admin_api"]],    "compute_extension:admin_actions":[["rule:admin_api"]],    "compute_extension:admin_actions:pause":[["rule:admin_or_owner"]],    "compute_extension:admin_actions:unpause":[["rule:admin_or_owner"]],    "compute_extension:admin_actions:suspend":[["rule:admin_or_owner"]],    "compute_extension:admin_actions:resume":[["rule:admin_or_owner"]],    "compute_extension:admin_actions:lock":[["rule:admin_api"]],    "compute_extension:admin_actions:unlock":[["rule:admin_api"]],    "compute_extension:admin_actions:resetNetwork":[["rule:admin_api"]],    "compute_extension:admin_actions:injectNetworkInfo":[["rule:admin_api"]],    "compute_extension:admin_actions:createBackup":[["rule:admin_or_owner"]],    "compute_extension:admin_actions:migrateLive":[["rule:admin_api"]],    "compute_extension:admin_actions:migrate":[["rule:admin_api"]],    "compute_extension:aggregates":[["rule:admin_api"]],    "compute_extension:certificates": ["role":"compute-user"],    "compute_extension:cloudpipe":[["rule:admin_api"]],    "compute_extension:console_output": ["role":"compute-user"],    "compute_extension:consoles": ["role":"compute-user"],    "compute_extension:createserverext": ["role":"compute-user"],    "compute_extension:deferred_delete": ["role":"compute-user"],    "compute_extension:disk_config": ["role":"compute-user"],    "compute_extension:extended_server_attributes":[["rule:admin_api"]],    "compute_extension:extended_status": ["role":"compute-user"],    "compute_extension:flavorextradata": ["role":"compute-user"],    "compute_extension:flavorextraspecs": ["role":"compute-user"],    "compute_extension:flavormanage":[["rule:admin_api"]],    "compute_extension:floating_ip_dns": ["role":"compute-user"],    "compute_extension:floating_ip_pools": ["role":"compute-user"],    "compute_extension:floating_ips": ["role":"compute-user"],    "compute_extension:hosts":[["rule:admin_api"]],    "compute_extension:keypairs": ["role":"compute-user"],    "compute_extension:multinic": ["role":"compute-user"],    "compute_extension:networks":[["rule:admin_api"]],    "compute_extension:quotas": ["role":"compute-user"],    "compute_extension:rescue": ["role":"compute-user"],    "compute_extension:security_groups": ["role":"compute-user"],    "compute_extension:server_action_list":[["rule:admin_api"]],    "compute_extension:server_diagnostics":[["rule:admin_api"]],    "compute_extension:simple_tenant_usage:show":[["rule:admin_or_owner"]],    "compute_extension:simple_tenant_usage:list":[["rule:admin_api"]],    "compute_extension:users":[["rule:admin_api"]],    "compute_extension:virtual_interfaces": ["role":"compute-user"],    "compute_extension:virtual_storage_arrays": ["role":"compute-user"],    "compute_extension:volumes": ["role":"compute-user"],    "compute_extension:volumetypes": ["role":"compute-user"],      "volume:create": ["role":"compute-user"],    "volume:get_all": ["role":"compute-user"],    "volume:get_volume_metadata": ["role":"compute-user"],    "volume:get_snapshot": ["role":"compute-user"],    "volume:get_all_snapshots": ["role":"compute-user"],      "network:get_all_networks": ["role":"compute-user"],    "network:get_network": ["role":"compute-user"],    "network:delete_network": ["role":"compute-user"],    "network:disassociate_network": ["role":"compute-user"],    "network:get_vifs_by_instance": ["role":"compute-user"],    "network:allocate_for_instance": ["role":"compute-user"],    "network:deallocate_for_instance": ["role":"compute-user"],    "network:validate_networks": ["role":"compute-user"],    "network:get_instance_uuids_by_ip_filter": ["role":"compute-user"],     "network:get_floating_ip": ["role":"compute-user"],    "network:get_floating_ip_pools": ["role":"compute-user"],    "network:get_floating_ip_by_address": ["role":"compute-user"],    "network:get_floating_ips_by_project": ["role":"compute-user"],    "network:get_floating_ips_by_fixed_address": ["role":"compute-user"],    "network:allocate_floating_ip": ["role":"compute-user"],    "network:deallocate_floating_ip": ["role":"compute-user"],    "network:associate_floating_ip": ["role":"compute-user"],    "network:disassociate_floating_ip": ["role":"compute-user"],     "network:get_fixed_ip": ["role":"compute-user"],    "network:add_fixed_ip_to_instance": ["role":"compute-user"],    "network:remove_fixed_ip_from_instance": ["role":"compute-user"],    "network:add_network_to_project": ["role":"compute-user"],    "network:get_instance_nw_info": ["role":"compute-user"],     "network:get_dns_domains": ["role":"compute-user"],    "network:add_dns_entry": ["role":"compute-user"],    "network:modify_dns_entry": ["role":"compute-user"],    "network:delete_dns_entry": ["role":"compute-user"],    "network:get_dns_entries_by_address": ["role":"compute-user"],    "network:get_dns_entries_by_name": ["role":"compute-user"],    "network:create_private_dns_domain": ["role":"compute-user"],    "network:create_public_dns_domain": ["role":"compute-user"],    "network:delete_dns_domain": ["role":"compute-user"]} Service management

The two main concepts of Identity service management are:

• Services

• Endpoints

The Identity service also maintains a user that corresponds to each service (e.g., a user named nova, for the Compute service) and a special service tenant, which is called service.

The commands for creating services and endpoints are described in a later section.