Open Stack

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/templates/mitaka/keystonev3_policy.json#b38 <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 at stackhpc.com> w dniu 30.03.2021, o godz. 12:51:
> 
> On Tue, 30 Mar 2021 at 10:52, Adam Tomas <bkslash at 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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210416/5b638f3f/attachment.html>