I've taken a good look at this issue today. I'm not convinced its an issue with Horizon itself, rather with the policy.json file that's being configured by the deployment itself.
In order to display the Create User button, the user needs to be able to qualify for the following policies:
From the policy file provided in the deployment the list_roles, list_projects, and create_user policies easily passed because they simply require that the user is a domain scoped admin or cloud admin.
This leaves the create_grant rule as being problematic. The create_grant rule is fairly complex in that it requires that the user in this case be one of:
- cloud admin
- an admin in the domain that the user is being created in AND that the target's role is in the same domain
- an admin in the project that the user is being created in AND that the target's role is in the same project
The problem with this particular rule is that the target of the policy as it is evaluated as an empty dictionary (due to the target for the table not being defined). The current user information is eventually filled in as part of the evaluation (tenant_id, user_id, domain_id).
Now, it may be that the create_grant policy is intentionally required in order to display the Create User button (I need to check the history on it). However, the policy.json file that's written for the charm is essentially the same policy.json file used for keystone, which in turn requires that the target.role.domain_id is the same. That may not make sense due to the context targets that are referenced when evaluating the policies (as keystone and horizon are not guaranteed to provide the same context in all places).
I see viable work around options as follows:
- Update the keystonev3_policy.json file in the deployment to have a more appropriate set of rules
- Use the cli to manage users
"domain_admin_for_grants": "rule:admin_required and (domain_id:%(domain_id)s or domain_id:%(target.project.domain_id)s)",
"project_admin_for_grants": "rule:admin_required and project_id:%(project_id)s",
"identity:check_grant": "rule:cloud_admin or rule:domain_admin_for_grants or rule:project_admin_for_grants",
"identity:list_grants": "rule:cloud_admin or rule:domain_admin_for_grants or rule:project_admin_for_grants",
"identity:create_grant": "rule:cloud_admin or rule:domain_admin_for_grants or rule:project_admin_for_grants",
"identity:revoke_grant": "rule:cloud_admin or rule:domain_admin_for_grants or rule:project_admin_for_grants",
I've taken a good look at this issue today. I'm not convinced its an issue with Horizon itself, rather with the policy.json file that's being configured by the deployment itself.
In order to display the Create User button, the user needs to be able to qualify for the following policies:
- create_grant
- create_user
- list_roles
- list_projects
From the policy file provided in the deployment the list_roles, list_projects, and create_user policies easily passed because they simply require that the user is a domain scoped admin or cloud admin.
This leaves the create_grant rule as being problematic. The create_grant rule is fairly complex in that it requires that the user in this case be one of:
- cloud admin
- an admin in the domain that the user is being created in AND that the target's role is in the same domain
- an admin in the project that the user is being created in AND that the target's role is in the same project
The problem with this particular rule is that the target of the policy as it is evaluated as an empty dictionary (due to the target for the table not being defined). The current user information is eventually filled in as part of the evaluation (tenant_id, user_id, domain_id).
Now, it may be that the create_grant policy is intentionally required in order to display the Create User button (I need to check the history on it). However, the policy.json file that's written for the charm is essentially the same policy.json file used for keystone, which in turn requires that the target. role.domain_ id is the same. That may not make sense due to the context targets that are referenced when evaluating the policies (as keystone and horizon are not guaranteed to provide the same context in all places).
I see viable work around options as follows: policy. json file in the deployment to have a more appropriate set of rules
- Update the keystonev3_
- Use the cli to manage users
Note: the following policy works well for the grant oriented policies. Not only is it easier to read and understand imo, but it removes the role bits that are included. This comes from the provided grants in the in the horizon openstack_auth django plugin test policies - https:/ /github. com/openstack/ horizon/ blob/stable/ queens/ openstack_ auth/tests/ conf/policy. v3cloudsample. json#L85:
"domain_ admin_for_ grants" : "rule:admin_ required and (domain_ id:%(domain_ id)s or domain_ id:%(target. project. domain_ id)s)", admin_for_ grants" : "rule:admin_ required and project_ id:%(project_ id)s", check_grant" : "rule:cloud_admin or rule:domain_ admin_for_ grants or rule:project_ admin_for_ grants" , list_grants" : "rule:cloud_admin or rule:domain_ admin_for_ grants or rule:project_ admin_for_ grants" , create_ grant": "rule:cloud_admin or rule:domain_ admin_for_ grants or rule:project_ admin_for_ grants" , revoke_ grant": "rule:cloud_admin or rule:domain_ admin_for_ grants or rule:project_ admin_for_ grants" ,
"project_
"identity:
"identity:
"identity:
"identity: