Manual Openstack Install: WARNING: … No Policy rules for service 'identity'

Question

Installed Openstack Train release manually.

When logged into the Horizon Dashboard as a non-admin role and clicking through the dashboard there are errors that pop up on the top right hand corner.

Specifically, Under Compute > Images there are two errors that occur:

1. Error: Forbidden. Insufficient permissions of the requested operation
2. Error: Unable to retrieve the project

Looking in the error_log for httpd it shows these errors over and over again:

WARNING openstack_auth.policy No policy rules for service 'network' in /usr/share/openstack-dashboard/openstack_dashboard/conf/neutron_policy.json 
WARNING openstack_auth.policy No policy rules for service 'identity' in /usr/share/openstack-dashboard/openstack_dashboard/conf/keystone_policy.json

When attempting to go to /usr/share/openstack-dashboard/openstack_dashboard/ and look at keystone_policy.json or neutron_policy.json the conf directory is missing and so are the files.

Openstack states that each service has their own policy.json file(or yaml if using the newer version). Openstack Documentation However, when I go to the services files they are empty. My question is does one simply create these policy.json files? Openstack documentation states it is not recommended to change the policy.json files which makes me think this is a bug. Have others experienced similar issues?

UPDATE

I have since created the conf directory under /usr/share/openstack-dashboard/openstack_dashboard . I then used the oslo generator to create new policy files for each service using the following command: oslopolicy-policy-generator --namespace keystone --output-file keystone_policy.json

I restarted apache and logged into horizon as an admin and realized my admin user is not able to create projects, users, or roles.

Currently been stuck on this for about a week.

Anyone having similar issues?

Answer 1

I myself went through partial of this problem.

For example on glance part all policies are defined in glancs-api/registry hosts /etc/glance/policy.json and same file exists in my dashboard cluster under path /etc/openstack-dashboard . In local_settings look for section POLICY_FILES = and comment it out, so as role = user you won't face the errors.

As for identity under policy

POLICY_FILES = {
   'identity': 'keystone_policy.json',
}

You have to make sure keystone_policy.json exist under openstack-dashboard path.

And as user role you gonna see projects that you own/member without errors.

I've made those changes and now running in test environment before moving to production to make sure all changes won't make damages.

Answer 2

So it looks like yaml files may not be working properly in the Train release.

The oslopolicy-policy-generator --namespace keystone --output-file keystone_policy.json command generates a file ending in.json but looks like actually yaml snytax.

When placed in the /usr/share/openstack-dashboard/openstack_dashboard/conf folder the policy file isnt applied correctly.

The following command is what finally fixed all of my issues with policy files:

oslopolicy-policy-upgrade \
--config-file /etc/keystone/keystone.conf \
--format json \
--namespace keystone \
--output-file keystone_policy_2.json \
--policy keystone_policy.json

When checking /var/log/keystone/keystone.log the following message was noticed:
Deprecated policy rules found. Use oslopolicy-policy-generator and oslopolicy-policy-upgrade to detect and resolve deprecated policies in your configuration. That is what prompted the use of oslopolicy-policy-upgrade -h

Also made sure that /openstack_dashboard/defaults.py said the following:

POLICY_FILES = {
    'identity': 'keystone_policy.json',
    'compute': 'nova_policy.json',
    'volume': 'cinder_policy.json',
    'image': 'glance_policy.json',
    'network': 'neutron_policy.json',
}

I want to point out that those two different commands ouputed two different keystone_policy.json files. The first command has a lot of mention about system_scope:all and the second command has simpler rules like: "identity:list_users_in_group": "rule:admin_required". So maybe this had to do with using IdentityV3 vs V2?

That much I am not sure. But I am glad permissions are being applied correctly.