Open Stack

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 at gazlene.net>
Sent: Monday, September 9, 2019 9:19 PM
To: openstack-discuss at 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
>
> > https://bugs.launchpad.net/keystone/+bug/1373599
>
> >
>
> 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 at everyware.ch
> web: http://www.everyware.ch
> Attachments:
> * smime.p7s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5230 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190910/08bc9458/attachment-0001.bin>