feature: read-only users within openstack

Creation of read-only roles requires modification of policy.json, which is currently not available via the charm.

I tested it according to the following steps:

1, create a role viewer and a user hua

keystone role-create --name viewer
keystone user-create --name hua --pass password
keystone user-role-add --user hua --role viewer --tenant demo
keystone user-role-list --tenant demo --user hua

2, /etc/nova/policy.json needs to be modified for each of the services

diff --git a/etc/nova/policy.json b/etc/nova/policy.json
index c238393..012b051 100644
--- a/etc/nova/policy.json
+++ b/etc/nova/policy.json
@@ -1,7 +1,20 @@
 {
     "context_is_admin": "role:admin",
- "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
+ "context_is_member": "not role:viewer",
+ "admin_or_owner": "is_admin:True or (project_id:%(project_id)s and rule:context_is_member)",
     "default": "rule:admin_or_owner",
+ "default_or_viewer": "is_admin:True or (project_id:%(project_id)s and not role:viewer)",
+
+ "compute:get":"rule:default_or_viewer",
+ "compute:get_all": "rule:default_or_viewer",
+ "compute:get_all_tenants": "rule:default_or_viewer",
+ "compute:stop":"rule:default_or_viewer",
+ "compute:start":"rule:default_or_viewer",
+ "compute:reboot":"rule:default_or_viewer", "compute:get_vnc_console":"rule:default_or_viewer",
+ "compute:get_spice_console":"rule:default_or_viewer",
+ "compute:get_console_output":"rule:default_or_viewer",
+ "compute_extension:console_output": "rule:default_or_viewer",
+ "compute_extension:consoles": "rule:default_or_viewer",

     "cells_scheduler_filter:TargetCellFilter": "is_admin:True",

3, test it, it works

ubuntu@zhhuabj-bastion-xenial:~/openstack-charm-testing$ nova flavor-create test-flav 'auto' 1024 80 4
ERROR (Forbidden): Policy doesn't allow compute_extension:flavormanage to be performed. (HTTP 403) (Request-ID: req-5787298d-af70-432f-900c-121ed2c27eb2)
ubuntu@zhhuabj-bastion-xenial:~/openstack-charm-testing$ nova list
+----+------+--------+------------+-------------+----------+
| ID | Name | Status | Task State | Power State | Networks |
+----+------+--------+------------+-------------+----------+
+----+------+--------+------------+-------------+----------+

Will a change be merged into the compute charm to enable us to use this config?

Hi Jill, as previously mentioned policy.json management to allow arbitrary policies to be defined is not currently a supported feature in the charms. It is also not on the roadmap for this cycle so definitely won't be available in the upcoming 17.08 release. However, I do believe that this is something that is being considered for inclusion in a future release but the engineering team will need to comment on how this is going to fit in with their plans. To be clear though, even if this gets included for the next release it would not be available until 18.02 at the earliest.

Currently we only render default policy.json files from https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json and do not modify them in any way. The only diff in a template is handling of both v2 and v3.

I think we might provide an option to allow a completely custom config instead of listing each option in config.yaml.

Some clarification offered by the customer on what they are hoping to achieve (not sure this is the place for it, but thought if it was it would hurt not having it):
"We would like to have read only access group type account. When we assign any user to the group. The user permission right is read-only. e.g. The user account can't create, reboot instance. Of course the user also can't upload image or modify any network setting."

Added Keystone charm, another similar requirement has been requested, for a role which allows a user to add Member role to a single project, but not other Admin-like activities.

Also adding n-api charm, as we have a similar need -- configuring profiles for port binding (need admin_or_network_owner for port _create:binding:profile)

There is another request from one of the customers to add a generic readonly role with relevant policies in keystone, neutron and nova. Is this going to be included in the upcoming releases?

In doing research for one of my customer's who has run into this today, I discovered that this has actually impacted around 4 customers (3 BootStack, 1 UA) since this bug was originally filed in 2017.

This bug is currently impacting 5 customers now (4 Bootstack and 1 UA)

the nova-compute charm doesn't have policies as its not an API charm; it just handles the instances on the host (hypervisor). Adding nova-cloud-controller as that is the API charm that has policies.

This is possibly a duplicate of https://bugs.launchpad.net/charm-keystone/+bug/1741723 which is about policy overrides using the policy.d directory for a service charm. There is ongoing work (within the scope of the 19.10 charms delivery) to deliver this across a number of charms (including neutron-api, nova-cloud-controller and keystone).

The crafting of read-only users would be to create the users, and then create policy overrides around (say) roles, or other policy items.

So policy.d overrides as a feature has been added to these charms. Now, we just need to work out what the overrides are and then this bug can be completed. The feature is a bit "course" at the moment, in that the overrides have to be worked out manually, zipped into a ZIP file and attached to the charm. Please see https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-policy-overrides.html for more information.

We discussed this bug at some length on the 18th of December.

As indicated by the age of this bug this is a non-trivial feature to provide even with the new support in selected charms to provide policy override files.

Enabling a new type of role is a somewhat risky process for a couple of reasons:

a) New policy rules must be both positively and negatively tested to ensure both the intent of the new 'read-only' rules/role and to ensure that the existing functionality of the rules for members and admins is maintained.

b) Policies must be regression between OpenStack releases - its possible that an endpoint/function and associated rule will no longer be valid.

Based on IRC and email conversation this feels like a feature that is still required but in order to implement this in a risk free way, it needs proper validation and testing.

Policy Overrides may look like a neat way to implement this, and maybe the solution is to provide a set of override files for all services that provide this feature, but that's just part of the challenge - testing is probably the larger task here.