RBAC, keystone and openstack

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.

About these ads
This entry was posted in Uncategorized. Bookmark the permalink.

6 Responses to RBAC, keystone and openstack

  1. sante says:

    Hi,

    is your tutorial still valid when not using Keystone as authentication layer?

    Thanks

  2. Renier says:

    How do I find the appropriate COMPONENT:ACTION keys for the keystone policy file? I can guess the COMPONENT name will be “identity”, but I how do I find the ACTIONs?

  3. ssujai says:

    Is this valid for havanna release? The said imputs are not being accepted by the keystone-manage command. It is throwing this error:

    root@localhost:/etc/keystone# keystone-manage -c keystone.conf role add tenantadm
    usage: keystone-manage [db_sync|db_version|pki_setup|ssl_setup|token_flush]
    keystone-manage: error: argument command: invalid choice: ‘keystone.conf’ (choose from ‘db_sync’, ‘db_version’, ‘pki_setup’, ‘ssl_setup’, ‘token_flush’)
    root@localhost:/etc/keystone#

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s