[keystone] cannot use 'openstack trust list' without admin role
Dear Keystone Experts,
I have an issue with the openstack client in stage (using Rocky), using a user 'fsc' without 'admin' role and with password auth.
'openstack trust create/show' works.
'openstack trust list' is denied.
But keystone policy.json says:
"identity:create_trust": "user_id:%(trust.trustor_user_id)s", "identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", "identity:get_trust": "",
So "openstack list trusts" is always allowed.
In keystone log (I replaced the uid's by names in the ouput below) I see that 'identity:list_trusts()' was actually granted but just after that a_*admin_required()*_ is getting checked and fails... I wonder why...
There is also a flag*is_admin_project=True* in the rbac creds for some reason...
Any clue? Many thanks in advance!
Cheers Francois
#openstack --os-cloud stage-fsc trust create --project fscproject --role creator fsc fsc #=> fail because of the names and policy rules, but using uid's it works openstack --os-cloud stage-fsc trust create --project aeac4b07d8b144178c43c65f29fa9dac --role 085180eeaf354426b01908cca8e82792 3e9b1a4fe95048a3b98fb5abebd44f6c 3e9b1a4fe95048a3b98fb5abebd44f6c +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
openstack --os-cloud stage-fsc trust show e74bcdf125e049c69c2e0ab1b182df5b +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
#this fails: openstack --os-cloud stage-fsc trust list *You are not authorized to perform the requested action: admin_required. (HTTP 403)*
Hello
I think this old link is explaining the reason behind this "inconsistency" with the policy.json rules:
https://bugs.launchpad.net/keystone/+bug/1373599
So to summarize, the RBAC is allowing identity:list_trusts for a non admin user (cf. policy.json) but then hard coded policies deny the request if non admin.
Quote:
The policies in policy.json can make these operations more restricted, but not less restricted than the hard-coded restrictions. We can't simply remove these settings from policy.json, as that would cause the "default" rule to be used which makes trusts unusable in the case of the default "default" rule of "admin_required".
Cheers
Francois
On 9/9/19 1:57 PM, Francois Scheurer wrote:
Hi All
I found an answer here
On 9/6/19 5:59 PM, Francois Scheurer wrote:
Dear Keystone Experts, I have an issue with the openstack client in stage (using Rocky), using a user 'fsc' without 'admin' role and with password auth. 'openstack trust create/show' works. 'openstack trust list' is denied. But keystone policy.json says: "identity:create_trust": "user_id:%(trust.trustor_user_id)s", "identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", "identity:get_trust": "", So "openstack list trusts" is always allowed. In keystone log (I replaced the uid's by names in the ouput below) I see that 'identity:list_trusts()' was actually granted but just after that a_*admin_required()*_ is getting checked and fails... I wonder why... There is also a flag*is_admin_project=True* in the rbac creds for some reason...
Any clue? Many thanks in advance!
Cheers Francois
#openstack --os-cloud stage-fsc trust create --project fscproject --role creator fsc fsc #=> fail because of the names and policy rules, but using uid's it works openstack --os-cloud stage-fsc trust create --project aeac4b07d8b144178c43c65f29fa9dac --role 085180eeaf354426b01908cca8e82792 3e9b1a4fe95048a3b98fb5abebd44f6c 3e9b1a4fe95048a3b98fb5abebd44f6c +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
openstack --os-cloud stage-fsc trust show e74bcdf125e049c69c2e0ab1b182df5b +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
#this fails: openstack --os-cloud stage-fsc trust list *You are not authorized to perform the requested action: admin_required. (HTTP 403)*
Hi François,
On Mon, Sep 9, 2019, at 08:36, Francois Scheurer wrote:
Hello
I think this old link is explaining the reason behind this "inconsistency" with the policy.json rules:
https://bugs.launchpad.net/keystone/+bug/1373599
So to summarize, the RBAC is allowing identity:list_trusts for a non admin user (cf. policy.json) but then hard coded policies deny the request if non admin.
Quote:
The policies in policy.json can make these operations more restricted, but not less restricted than the hard-coded restrictions. We can't simply remove these settings from policy.json, as that would cause the "default" rule to be used which makes trusts unusable in the case of the default "default" rule of "admin_required".
I wish I had known about this bug, as I would have reopened and closed it. You're correct that the trusts API was doing some unusal RBAC hardcoding, which we have just addressed by moving that logic into policy and then updating the policy defaults to be more sensible:
https://review.opendev.org/#/q/topic:trust-policies
That series is making its way through CI now and so will be available in the Train release. Unfortunately I don't think we can backport any of it because it introduces new functionality in the policies.
Colleen
Cheers
Francois
On 9/9/19 1:57 PM, Francois Scheurer wrote:
Hi All
I found an answer here
On 9/6/19 5:59 PM, Francois Scheurer wrote:
Dear Keystone Experts, I have an issue with the openstack client in stage (using Rocky), using a user 'fsc' without 'admin' role and with password auth. 'openstack trust create/show' works. 'openstack trust list' is denied. But keystone policy.json says: "identity:create_trust": "user_id:%(trust.trustor_user_id)s",
"identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", "identity:get_trust": "",
So "openstack list trusts" is always allowed. In keystone log (I
replaced the uid's by names in the ouput below) I see that 'identity:list_trusts()' was actually granted but just after that a _*admin_required()*_ is getting checked and fails... I wonder why...
There is also a flag* is_admin_project=True* in the rbac creds for some reason...
Any clue? Many thanks in advance!
Cheers Francois
#openstack --os-cloud stage-fsc trust create --project fscproject
--role creator fsc fsc #=> fail because of the names and policy rules, but using uid's it works openstack --os-cloud stage-fsc trust create --project aeac4b07d8b144178c43c65f29fa9dac --role 085180eeaf354426b01908cca8e82792 3e9b1a4fe95048a3b98fb5abebd44f6c 3e9b1a4fe95048a3b98fb5abebd44f6c +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
openstack --os-cloud stage-fsc trust show e74bcdf125e049c69c2e0ab1b182df5b +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
#this fails: openstack --os-cloud stage-fsc trust list
*You are not authorized to perform the requested action: admin_required. (HTTP 403)*
--
EveryWare AG François Scheurer Senior Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich
tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: francois.scheurer@everyware.ch web: http://www.everyware.ch Attachments:
- smime.p7s
Hi Colleen
Thank you for your message.
They also mentioned this in the patch proposal: https://review.opendev.org/#/c/123862/4/doc/source/configuration.rst : " I initially had the same reaction, but it arguably is desired to have hard-coded restrictions in some cases. The hard-coded restrictions prevent one from making a mistake in the policy file that opens up access to something that should never be authorized."
So one should also take this into account.
Best Regards Francois
________________________________________ From: Colleen Murphy colleen@gazlene.net Sent: Monday, September 9, 2019 9:19 PM To: openstack-discuss@lists.openstack.org Subject: Re: [keystone] cannot use 'openstack trust list' without admin role
Hi François,
On Mon, Sep 9, 2019, at 08:36, Francois Scheurer wrote:
Hello
I think this old link is explaining the reason behind this "inconsistency" with the policy.json rules:
https://bugs.launchpad.net/keystone/+bug/1373599
So to summarize, the RBAC is allowing identity:list_trusts for a non admin user (cf. policy.json) but then hard coded policies deny the request if non admin.
Quote:
The policies in policy.json can make these operations more restricted, but not less restricted than the hard-coded restrictions. We can't simply remove these settings from policy.json, as that would cause the "default" rule to be used which makes trusts unusable in the case of the default "default" rule of "admin_required".
I wish I had known about this bug, as I would have reopened and closed it. You're correct that the trusts API was doing some unusal RBAC hardcoding, which we have just addressed by moving that logic into policy and then updating the policy defaults to be more sensible:
https://review.opendev.org/#/q/topic:trust-policies
That series is making its way through CI now and so will be available in the Train release. Unfortunately I don't think we can backport any of it because it introduces new functionality in the policies.
Colleen
Cheers
Francois
On 9/9/19 1:57 PM, Francois Scheurer wrote:
Hi All
I found an answer here
On 9/6/19 5:59 PM, Francois Scheurer wrote:
Dear Keystone Experts, I have an issue with the openstack client in stage (using Rocky), using a user 'fsc' without 'admin' role and with password auth. 'openstack trust create/show' works. 'openstack trust list' is denied. But keystone policy.json says: "identity:create_trust": "user_id:%(trust.trustor_user_id)s",
"identity:list_trusts": "", "identity:list_roles_for_trust": "", "identity:get_role_for_trust": "", "identity:delete_trust": "", "identity:get_trust": "",So "openstack list trusts" is always allowed. In keystone log (I
replaced the uid's by names in the ouput below) I see that 'identity:list_trusts()' was actually granted but just after that a _*admin_required()*_ is getting checked and fails... I wonder why...
There is also a flag* is_admin_project=True* in the rbac creds for some reason...
Any clue? Many thanks in advance!
Cheers Francois
#openstack --os-cloud stage-fsc trust create --project fscproject
--role creator fsc fsc #=> fail because of the names and policy rules, but using uid's it works openstack --os-cloud stage-fsc trust create --project aeac4b07d8b144178c43c65f29fa9dac --role 085180eeaf354426b01908cca8e82792 3e9b1a4fe95048a3b98fb5abebd44f6c 3e9b1a4fe95048a3b98fb5abebd44f6c +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
openstack --os-cloud stage-fsc trust show e74bcdf125e049c69c2e0ab1b182df5b +--------------------+----------------------------------+ | Field | Value | +--------------------+----------------------------------+ | deleted_at | None | | expires_at | None | | id | e74bcdf125e049c69c2e0ab1b182df5b | | impersonation | False | | project_id | fscproject | | redelegation_count | 0 | | remaining_uses | None | | roles | creator | | trustee_user_id | fsc | | trustor_user_id | fsc | +--------------------+----------------------------------+
#this fails: openstack --os-cloud stage-fsc trust list
*You are not authorized to perform the requested action: admin_required. (HTTP 403)*
--
EveryWare AG François Scheurer Senior Systems Engineer Zurlindenstrasse 52a CH-8003 Zürich
tel: +41 44 466 60 00 fax: +41 44 466 60 10 mail: francois.scheurer@everyware.ch web: http://www.everyware.ch Attachments:
- smime.p7s
participants (3)
-
Colleen Murphy
-
Francois Scheurer
-
Scheurer François