Setting up roles (based on Diablo/Essex release):
Keystone:
1. create roles with keystone
keystone-manage -c <keystone.conf> role add <role>
2. Assign role to a user
keystone-manage -c <keystone.conf> role grant <role> <user> <tenant>
3. If not using default policy.json file:
nova.conf file should be set with “–policy_file=FILENAME”
4. If using the default /opt/stack/nova/etc/nova/policy.json file:
1. Sample policy.json file
Line #1 {
Line #2 “admin_or_owner”: [["role:admin"], ["project_id:%(project_id)s"]],
Line #3 “sysadmin_or_owner”: [["role:sysadmin"], ["project_id:%(project_id)s"]],
Line #4 “compute:create”: [["rule:admin_or_owner"]],
Line #5 “compute:create:attach_network”: [["rule:admin_or_owner"]],
Line #6 “compute:create:attach_volume”: [["rule:admin_or_owner"]],
Line #7 “compute:get”: [["rule:admin_or_owner"]],
Line #8 “compute:get_all” :[],
…..
…..
“compute:pause”: [["rule:admin_or_owner"], ["rule:sysadmin_or_owner"]],
Line #40 “network:get_dns_entries_by_name”: []
Line #41 }
Explanation:
The contents of the file are a JSON-encoded hash in the from of:
RULE : MATCH_LIST
The MATCH_LIST can be:
rule:*
role:*
KEY:%(CONTEXT_KEY)s
RULE will be in the form of the following for specific checks.
COMPONENT:ACTION
When a MATCH_LIST for a rule:* is found, it acts as a link to the other rule
to perform checking.
When a MATCH_LIST for a role:* is found, the auth context of the request is
checked and made sure it contains the named role.
When a KEY:%(CONTEXT_KEY)s check is found, the KEY for the checked object
(an instnace model, a network address, a volume, etc) is compared to the
CONTEXT_KEY from the checked context. The admin_or_owner uses this type
of check for project_id matching between the context and the checked object.
Line #1:
RULE can be a custom name that is referenced by a MATCH_LIST.
“admin_or_owner”: [["role:admin"], ["project_id:%(project_id)s"]]
“admin_or_owner” is just a RULE name
The rule defines that if the user has admin role OR he is the owner of the project
Note the box separating the role admin and the project id, that shows that it’s OR”
If you want to set a rule saying if the user is a member AND owner of the project
“admin_and_owner”: [["role:admin", "project_id:%(project_id)s"]], “admin_and_owner” is the rule name
Note there is no box separation between role member and project id that shows that it’s AND”
Line #4:
“compute:create”: [["rule:admin_or_owner"]],
“compute:create:attach_network”: [["rule:admin_or_owner"]],
This implies that an admin or owner can attach network.
“compute:get_all” :[],
All users can list instances
5. When users are created through dashboard, they default to a tenant. So, always a user would be a member of a project.
6. mysql > keystone> users table:
a. If users table has the tenant_id set to “NULL” and if the user has roles set in the keystone, then still would be able to do whatever that role is allowed to do
b. If users table has the tenant_id set to a tenant for eg., 1 or 2…, and if no role or object is set, still the user would be able to do the actions which are set as []
c. There is no concept of project manager by default as we had in bexar. Owner doesn’t mean that the user is the project manager of the project, it just means that the user is a member of the project.
