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?