Open Stack

Glance has a separate policy rule (publicize_image) for creating/updating
public images.,
and you should define that policy rule instead of modify_image.

https://docs.openstack.org/glance/xena/admin/policies.html
~~~
publicize_image - Create or update public images
~~~

AFAIK The modify_image policy defaults to rule:default and is allowed for
any users
as long as the target image is owned by that user.


On Tue, Jun 14, 2022 at 2:01 PM Adivya Singh <adivya1.singh at gmail.com>
wrote:

>  Hi Brian,
>
> Please find the response
>
>
>> 1> i am using Xena release version 24.0.1
>>
>> Now the scenario is line below, my customer wants to have their login
>> access on setting up the properties of an image to the public. now what i
>> did is
>>
>> 1> i created a role in openstack using the admin credential name as "user"
>> 2> i assigned that user to a role user.
>> 3> i assigned those user to those project id, which they want to access
>> as a user role
>>
>> Then i went to Glance container which is controller by lxc and made a
>> policy.yaml file as below
>>
>> root at aio1-glance-container-724aa778:/etc/glance# cat policy.yaml
>>
>>  "modify_image": "role:user"
>>
>> then i went to utility container and try to set the properties of a image
>> using openstack command
>>
>> openstack image set --public <image id>
>>
>> and then i got this error
>>
>> HTTP 403 Forbidden: You are not authorized to complete publicize_image
>> action.
>>
>> Even when i am trying the upload image with this user , i get the above
>> error only
>>
>> export OS_ENDPOINT_TYPE=internalURL
>> export OS_INTERFACE=internalURL
>> export OS_USERNAME=adsingh
>> export OS_PASSWORD='adsingh'
>> export OS_PROJECT_NAME=adsingh
>> export OS_TENANT_NAME=adsingh
>> export OS_AUTH_TYPE=password
>> export OS_AUTH_URL=https://<Internal IP of horizon>:5000/v3
>> export OS_NO_CACHE=1
>> export OS_USER_DOMAIN_NAME=Default
>> export OS_PROJECT_DOMAIN_NAME=Default
>> export OS_REGION_NAME=RegionOne
>>
>> Regards
>> Adivya Singh
>>
>>
>>
>>
>> On Mon, Jun 13, 2022 at 6:41 PM Alan Bishop <abishop at redhat.com> wrote:
>>
>>>
>>>
>>> On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita <
>>> rosmaita.fossdev at gmail.com> wrote:
>>>
>>>> On 6/13/22 8:29 AM, Adivya Singh wrote:
>>>> > hi Team,
>>>> >
>>>> > Any thoughts on this
>>>>
>>>> H Adivya,
>>>>
>>>> Please supply some more information, for example:
>>>>
>>>> - which openstack release you are using
>>>> - the full API request you are making to modify the image
>>>> - the full API response you receive
>>>> - whether the user with "role:user" is in the same project that owns
>>>> the
>>>> image
>>>> - debug level log extract for this call if you have it
>>>> - anything else that could be relevant, for example, have you modified
>>>> any other policies, and if so, what values are you using now?
>>>>
>>>
>>> Also bear in mind that the default policy_file name is "policy.yaml"
>>> (not .json). You either
>>> need to provide a policy.yaml file, or override the policy_file setting
>>> if you really want to
>>> use policy.json.
>>>
>>> Alan
>>>
>>> cheers,
>>>> brian
>>>>
>>>> >
>>>> > Regards
>>>> > Adivya Singh
>>>> >
>>>> > On Sat, Jun 11, 2022 at 12:40 AM Adivya Singh <
>>>> adivya1.singh at gmail.com
>>>> > <mailto:adivya1.singh at gmail.com>> wrote:
>>>> >
>>>> >     Hi Team,
>>>> >
>>>> >     I have a use case where I have to give a user restriction on
>>>> >     updating the image properties as a member.
>>>> >
>>>> >     I have created a policy Json file and give the modify_image rule
>>>> to
>>>> >     the particular role, but still it is not working
>>>> >
>>>> >     "modify_image": "role:user", This role is created in OpenStack.
>>>> >
>>>> >     but still it is failing while updating properties with a
>>>> >     particular user assigned to a role as "access denied" and
>>>> >     unauthorized access
>>>> >
>>>> >     Regards
>>>> >     Adivya Singh
>>>> >
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220614/4e063ef6/attachment-0001.htm>