[kolla-ansible][horizon] policy.yaml/json files
Hi, Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions: 1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files 2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it? 3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change? 4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project? Best regards Adam
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use: /etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
On Tue, 30 Mar 2021 at 09:24, Mark Goddard <mark@stackhpc.com> wrote:
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Proposed some docs improvements: https://review.opendev.org/c/openstack/kolla-ansible/+/783809
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use:
/etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
Hi, thank you for the answers, but I still have more questions :) Without any custom policies when I look inside the horizon container I see (in /etc/openstack-dashboard) current/default policies. If I override (for example keystone_policy.json) with a file placed in /etc/kolla/config/horizon which contains only 3 rules, then after kolla-ansible reconfigure inside horizon container there is of course keystone_police.json file, but only with my 3 rules - should I assume, that previously seen default rules (other than the ones overridden by my rules) still works, whether I see them in the file or not? And another question - I need a rule, that will allow some „special” user (which I call project_admin) to see,create, update and delete users inside a project (but not elsewhere). How should the policy look like? „project_admin_required”: „role:project_admin and default_project_id:%(target.project_id)s" „identity:list_user”: „rule: admin_required or project_admin_required” „identity:create_user”: „rule: admin_required or project_admin_required” „identity:update_user”: „rule: admin_required or project_admin_required” „identity:delete_user”: „rule: admin_required or project_admin_required” ? Best regards, Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 11:05:
On Tue, 30 Mar 2021 at 09:24, Mark Goddard <mark@stackhpc.com> wrote:
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Proposed some docs improvements: https://review.opendev.org/c/openstack/kolla-ansible/+/783809
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use:
/etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
On Tue, 30 Mar 2021 at 10:52, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi, thank you for the answers, but I still have more questions :)
Without any custom policies when I look inside the horizon container I see (in /etc/openstack-dashboard) current/default policies. If I override (for example keystone_policy.json) with a file placed in /etc/kolla/config/horizon which contains only 3 rules, then after kolla-ansible reconfigure inside horizon container there is of course keystone_police.json file, but only with my 3 rules - should I assume, that previously seen default rules (other than the ones overridden by my rules) still works, whether I see them in the file or not?
I'd assume Horizon works in the same way as other services, and you only need to include changes. Please test and report back.
And another question - I need a rule, that will allow some „special” user (which I call project_admin) to see,create, update and delete users inside a project (but not elsewhere). How should the policy look like?
„project_admin_required”: „role:project_admin and default_project_id:%(target.project_id)s" „identity:list_user”: „rule: admin_required or project_admin_required” „identity:create_user”: „rule: admin_required or project_admin_required” „identity:update_user”: „rule: admin_required or project_admin_required” „identity:delete_user”: „rule: admin_required or project_admin_required”
As I mentioned before, admin is global in OpenStack for now. There may be various ways to achieve what you want. One is to introduce a role, and use it in the rules. It's a bit of a can of worms though, since there are many API endpoints which might need to be updated to catch all corner cases. I added keystone to the subject, in case anyone from that team wants to comment.
? Best regards, Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 11:05:
On Tue, 30 Mar 2021 at 09:24, Mark Goddard <mark@stackhpc.com> wrote:
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Proposed some docs improvements: https://review.opendev.org/c/openstack/kolla-ansible/+/783809
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use:
/etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
(horizon)[root@controller1 /]# cd /etc/openstack-dashboard/ (horizon)[root@controller1 openstack-dashboard]# ls -la total 104 drwxr-xr-x 1 horizon horizon 186 Mar 30 13:17 . drwxr-xr-x 1 root root 59 Mar 30 12:56 .. -rw-r--r-- 1 horizon horizon 8560 Feb 7 08:13 cinder_policy.json -rw------- 1 horizon horizon 301 Mar 30 13:17 custom_local_settings -rw-r--r-- 1 horizon horizon 1388 Feb 7 08:13 glance_policy.json -rw-r--r-- 1 root root 4544 Feb 7 08:14 heat_policy.json -rw-r--r-- 1 horizon horizon 10144 Feb 7 08:13 keystone_policy.json -rw------- 1 horizon horizon 29710 Mar 30 13:17 local_settings -rw-r--r-- 1 root root 395 Feb 7 08:14 masakari_policy.json -rw-r--r-- 1 horizon horizon 12580 Feb 7 08:13 neutron_policy.json drwxr-xr-x 2 horizon horizon 33 Feb 7 08:13 nova_policy.d -rw------- 1 horizon horizon 269 Mar 30 13:17 nova_policy.json -rw-r--r-- 1 root root 1268 Feb 7 08:14 senlin_policy.json -rw-r--r-- 1 root root 1138 Feb 7 08:14 watcher_policy.json (horizon)[root@controller1 openstack-dashboard]# cat nova_policy.json { "context_is_admin": "role:admin", "admin_or": "is_admin:True" "os_compute_api:os-consoles:show": "rule:admin_or", "os_compute_api:servers:start": "rule:admin_or", "os_compute_api:servers:stop": "rule:admin_or" } So the file with overrides is properly placed inside horizon container. And the above policy should prevent non-admin user from starting/stopping instances and showing the console and… it does not work. Still as regular user I’m able to start and stop all instances in project from Horizon GUI. If the policy is in horizon configuration then it should work from horizon dashboard (without the same policy in nova it should be still possible to start/stop instances from CLI).
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 12:51:
On Tue, 30 Mar 2021 at 10:52, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi, thank you for the answers, but I still have more questions :)
Without any custom policies when I look inside the horizon container I see (in /etc/openstack-dashboard) current/default policies. If I override (for example keystone_policy.json) with a file placed in /etc/kolla/config/horizon which contains only 3 rules, then after kolla-ansible reconfigure inside horizon container there is of course keystone_police.json file, but only with my 3 rules - should I assume, that previously seen default rules (other than the ones overridden by my rules) still works, whether I see them in the file or not?
I'd assume Horizon works in the same way as other services, and you only need to include changes. Please test and report back.
And another question - I need a rule, that will allow some „special” user (which I call project_admin) to see,create, update and delete users inside a project (but not elsewhere). How should the policy look like?
„project_admin_required”: „role:project_admin and default_project_id:%(target.project_id)s" „identity:list_user”: „rule: admin_required or project_admin_required” „identity:create_user”: „rule: admin_required or project_admin_required” „identity:update_user”: „rule: admin_required or project_admin_required” „identity:delete_user”: „rule: admin_required or project_admin_required”
As I mentioned before, admin is global in OpenStack for now. There may be various ways to achieve what you want. One is to introduce a role, and use it in the rules. It's a bit of a can of worms though, since there are many API endpoints which might need to be updated to catch all corner cases. I added keystone to the subject, in case anyone from that team wants to comment.
? Best regards, Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 11:05:
On Tue, 30 Mar 2021 at 09:24, Mark Goddard <mark@stackhpc.com> wrote:
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Proposed some docs improvements: https://review.opendev.org/c/openstack/kolla-ansible/+/783809
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use:
/etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
Red Hat did really good documentation on security (and policies) which can be easily used with kolla - thanks to that my policies now work: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/... <https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13/pdf/security_and_hardening_guide/Red_Hat_OpenStack_Platform-13-Security_and_Hardening_Guide-en-US.pdf> Best regards, Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 12:51:
On Tue, 30 Mar 2021 at 10:52, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi, thank you for the answers, but I still have more questions :)
Without any custom policies when I look inside the horizon container I see (in /etc/openstack-dashboard) current/default policies. If I override (for example keystone_policy.json) with a file placed in /etc/kolla/config/horizon which contains only 3 rules, then after kolla-ansible reconfigure inside horizon container there is of course keystone_police.json file, but only with my 3 rules - should I assume, that previously seen default rules (other than the ones overridden by my rules) still works, whether I see them in the file or not?
I'd assume Horizon works in the same way as other services, and you only need to include changes. Please test and report back.
And another question - I need a rule, that will allow some „special” user (which I call project_admin) to see,create, update and delete users inside a project (but not elsewhere). How should the policy look like?
„project_admin_required”: „role:project_admin and default_project_id:%(target.project_id)s" „identity:list_user”: „rule: admin_required or project_admin_required” „identity:create_user”: „rule: admin_required or project_admin_required” „identity:update_user”: „rule: admin_required or project_admin_required” „identity:delete_user”: „rule: admin_required or project_admin_required”
As I mentioned before, admin is global in OpenStack for now. There may be various ways to achieve what you want. One is to introduce a role, and use it in the rules. It's a bit of a can of worms though, since there are many API endpoints which might need to be updated to catch all corner cases. I added keystone to the subject, in case anyone from that team wants to comment.
? Best regards, Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 11:05:
On Tue, 30 Mar 2021 at 09:24, Mark Goddard <mark@stackhpc.com> wrote:
On Mon, 29 Mar 2021 at 15:36, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Hi,
Hi, Looks like we need some more/better docs on this in Kolla.
Proposed some docs improvements: https://review.opendev.org/c/openstack/kolla-ansible/+/783809
Im not quite clear about policy.yaml/json files in kolla-ansible. Let assume, that I need to allow one of project users to add other users to the project. So I create „project_admin” role and assign it to this user. Then I found /etc/kolla/keystone/policy.json.test file, which I use as template. There is rule „identity:create_credential” : „(role:admin and system_scope:all)” so I add „or role:project_admin” and put file in /etc/kolla/config/keystone/ and reconfigure kolla. And now few questions:
1. policy.json (or policy.yaml) always overwrite all default policies? I mean if I only add one rule to this file then other rules will „disappear” or will have default values? Is there any way to only overwrite some default rules and leave rest with defaults? Like with .conf files
For a few releases now, OpenStack supports policy in code. This means that you only need to include the rules you want to override in your JSON/YAML file.
2. what about Horizon and visibility of options? In mentioned case putting the same policy.json file in /etc/kolla/config/keystone/ and /etc/kolla/config/horizon/ should „unblock” Add User button for user with project_admin role? Or how to achieve it?
For keystone policy in horizon, you need to use:
/etc/kolla/config/horizon/keystone_policy.json
3. does Horizon need the duplicated policy.json files from other services in it’s configuration folder or is it enough to write policy.json for services I want to change?
Only the ones you want to change.
4. when I assign admin role to a user with projectID (openstack role add —project PROJECT_ID —user SOME_USER admin) this user sees in Horizon everything systemwide, not only inside this project… Which rules should be created to allow him to see only users and resources which belongs to this project?
Currently admin is generally global in OpenStack. It's a known limitation, and currently being worked on.
Best regards Adam
Hi again, After some struggling I modified policies so most of them works fine. But I have problem with identity: create_user and identity: create_group. In the case of create group I can do it from Horizon (domain_admin user), but I can’t do it from CLI (with command Openstack group create —domain 3a08xxxx82c1 SOME_GROUP_NAME) and I was wondering why. After analyzing logs it turned out, that tokens from Horizon and CLI are different! The one from CLI does not contain domain_id (which I specify from CLI???), while the one from Horizon contains it, and there is a match for policy rules. Token from CLI: DEBUG keystone.server.flask.request_processing.middleware.auth_context [req-b00bccae-c3d2-4a53-a8e2-bd9b0bbdfd84 9adbxxxx02ef 61d4xxxx9c0f <- user default Project_ID here - 3a08xxxxb82c1 3a08xxxx82c1] RBAC: auth_context: {'token': <TokenModel (audit_id=1JdN5qJXReutPgsp5r0DMw, audit_chain_id=['1JdN5qJXReutPgsp5r0DMw']) at 0x7f38b2210ca0>, 'domain_id': None, <- no domain_id 'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_name': None, <- no domain name 'group_ids': [], 'user_id': '9adbxxxx02ef', 'user_domain_id': '3a08xxxx82c1', 'system_scope': None, 'project_id': '61d4xxxx9c0f',<- user default Project_ID here 'project_domain_id': '3a08xxxx82c1’, <- default user project domain_id 'roles': ['reader', 'member', 'project_admin', 'domain_admin'], 'is_admin_project': True, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_id': None, 'service_project_domain_id': None, 'service_roles': []} fill_context /var/lib/kolla/venv/lib/python3.8/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py:478 Token from Horizon: DEBUG keystone.server.flask.request_processing.middleware.auth_context [req-aeeec218-fe13-4048-98a7-3240df0dacae 9adbxxxxb02ef <- no user default Project_ID here - 3a08xxxx82c1 3a08xxxx82c1 -] RBAC: auth_context: {'token': <TokenModel (audit_id=8bHfrpZjQPihquFwJew7oQ, audit_chain_id=['8bHfrpZjQPihquFwJew7oQ', 'j0X6mtDHSFG8NDTBT52vcw']) at 0x7f38b205e880>, 'domain_id': '3a08xxxx82c1’, <- domain_id 'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_name': ’some_domain’, <- domain name 'group_ids': [], 'user_id': '9adbxxxx02ef', 'user_domain_id': '3a08xxxx82c1', 'system_scope': None, 'project_id': None,<- no user default Project_ID here 'project_domain_id': None,<- default user project domain_id 'roles': ['member', 'domain_admin', 'project_admin', 'reader'], 'is_admin_project': False, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_id': None, 'service_project_domain_id': None, 'service_roles': []} fill_context /var/lib/kolla/venv/lib/python3.8/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py:478 The policy rules: "identity:create_group": "rule:cloud_admin or rule:admin_and_matching_target_group_domain_id”, "admin_and_matching_target_group_domain_id": "rule:admin_required and domain_id:%(target.group.domain_id)s”, "admin_required": "role:admin or role:domain_admin or role:project_admin", CLI user openrc file: export OS_AUTH_URL=http://some-fancy-url:5000 export OS_PROJECT_ID=61d4xxxx9c0f export OS_PROJECT_NAME=„some_project_name" export OS_USER_DOMAIN_NAME=„some_domain" if [ -z "$OS_USER_DOMAIN_NAME" ]; then unset OS_USER_DOMAIN_NAME; fi export OS_PROJECT_DOMAIN_ID="3a08xxxx82c1" if [ -z "$OS_PROJECT_DOMAIN_ID" ]; then unset OS_PROJECT_DOMAIN_ID; fi unset OS_TENANT_ID unset OS_TENANT_NAME export OS_USERNAME=„some_user" echo "Please enter your OpenStack Password for project $OS_PROJECT_NAME as user $OS_USERNAME: " read -sr OS_PASSWORD_INPUT export OS_PASSWORD=$OS_PASSWORD_INPUT export OS_REGION_NAME="RegionOne" if [ -z "$OS_REGION_NAME" ]; then unset OS_REGION_NAME; fi export OS_INTERFACE=public export OS_IDENTITY_API_VERSION=3 How to put domain_id into CLI token if —domain xxxxx doesn’t do that? The same situation is with create_user. And the best part - ofcource cloud_admin=admin is able to do both, because he don’t need to be checked against domain_id. Ofcourse there is also some kind of a bug, that prevents displaying „Create user” button in the horizon interface, but when you eneter direct link (…/users/create) you can create user. After some struggling with horizon (as suggested here: https://review.opendev.org/c/openstack/charm-openstack-dashboard/+/575272/1/... <https://review.opendev.org/c/openstack/charm-openstack-dashboard/+/575272/1/templates/mitaka/keystonev3_policy.json#b38>) „create group” button showed up, but not "create user” - not even for admin user… What’s wrong?? Best regards Adam
Wiadomość napisana przez Mark Goddard <mark@stackhpc.com> w dniu 30.03.2021, o godz. 12:51:
On Tue, 30 Mar 2021 at 10:52, Adam Tomas <bkslash@poczta.onet.pl> wrote:
Without any custom policies when I look inside the horizon container I see (in /etc/openstack-dashboard) current/default policies. If I override (for example keystone_policy.json) with a file placed in /etc/kolla/config/horizon which contains only 3 rules, then after kolla-ansible reconfigure inside horizon container there is of course keystone_police.json file, but only with my 3 rules - should I assume, that previously seen default rules (other than the ones overridden by my rules) still works, whether I see them in the file or not?
participants (2)
-
Adam Tomas
-
Mark Goddard