On 6/14/22 2:18 PM, Adivya Singh wrote:

Hi Takashi,

when a user upload images which is a member , The image will be set to private.

This is what he is asking for access to make it public,  The above rule applies for only public images Alan and Takashi have both given you good advice:

- By default, Glance assumes that your custom policy file is named "policy.yaml". If it doesn't have that name, Glance will assume it does not exist and will use the defaults defined in code. You can change the filename glance will look for in your glance-api.conf -- look for [oslo_policy]/policy_file - We recommend that you use YAML instead of JSON to write your policy file because YAML allows comments, which you will find useful in documenting any changes you make to the file - You want to keep the permissions on modify_image at their default value, because otherwise users won't be able to do simple things like add image properties to their own images - Some image properties can affect the system or other users. Glance will not allow *any* user to modify some system properties (for example, 'id', 'status'), and it requires additional permission along with modify_image to set 'public' or 'community' for image visibility. - It's also possible to configure property protections to require additional permission to CRUD specific properties (the default setting is *not* to do this). For your particular use case, where you want a specific user to be able to publicize_image, I would encourage you to think more carefully about what exactly you want to accomplish. Traditionally, images with 'public' visibility are provided by the cloud operator, and this gives image consumers some confidence that there's nothing malicious on the image. Public images are accessible to all users, and they will show up in the default image-list call for all users, so if a public image contains something nasty, it can spread very quickly. Glance provides four levels of image visibility: - private: only visible to users in the project that owns the image - shared: visible to users in the project that owns the image *plus* any projects that are added to the image as "members". (A shared image with no members is effectively a private image.) See [0] for info about how image sharing is designed and what API calls are associated with it. There are a bunch of policies around this; the defaults are basically what you'd expect, with the image owner being able to add and delete members, and image members being able to 'accept' or 'reject' shared images. - community: accessible to everyone, but only visible if you look for them. See [1] for an explanation of what that means. The ability to set 'community' visibility on an image is controlled by the "communitize_image" policy (default is admin-or-owner). - public: accessible to everyone, and easily visible to all users. Controlled by the "publicize_image" policy (default is admin-only). You're running your own cloud, so you can configure things however you like, but I encourage you to think carefully before handing out publicize_image permission, and consider whether one of the other visibilities can accomplish what you want. For more info, the introductory section on "Images" in the api-ref [2] has a useful discussion of image properties and image visibility. The final thing I want to stress is that you should be sure to test carefully any policies you define in a custom policy file. You are actually having a good problem, that is, someone can't do something you would like them to. The way worse problem happens when in addition to that someone being able to do what you want them to, a whole bunch of other users can also do that same thing. OK, so to get to your particular issue: - you don't want to change the "modify_image" policy in the way you proposed in your email, because no one (other than the person having the 'user role) will be able to do any kind of image updates. - if you decide to give that user publicize_image permissions, be careful how you do it. For example, "publicize_image": "role:user" won't allow an admin to make images public (unless you also give each admin the 'user' role). If you look at most of the policies in the Xena policy.yaml.sample, they begin "role:admin or ...". - the reason you were seeing the 403 when you tried to do openstack image set --public <image id> as the user with the 'user' property is that you were allowed to modify_image but when you tried to change the visibility, you did not have permission (because the default for that is role:admin) Hope this helps! Once you get this figured out, you may want to put up a patch to update the Glance documentation around policies. I think everything said above is in there somewhere, but it may not be in the most obvious places. Actually, there is one more thing. The above all applies to Xena, but there's been some work around policies in Yoga and more happening in Zed, so be sure to read the Glance release notes when you eventually upgrade. [0] https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-imag... [1] https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-imag... [2] https://docs.openstack.org/api-ref/image/v2/index.html#images

regards Adivya Singh

On Tue, Jun 14, 2022 at 10:54 AM Takashi Kajinami <tkajinam@redhat.com <mailto:tkajinam@redhat.com>> wrote:

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 <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@gmail.com <mailto:adivya1.singh@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@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@redhat.com <mailto:abishop@redhat.com>> wrote:

On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita <rosmaita.fossdev@gmail.com <mailto:rosmaita.fossdev@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@gmail.com <mailto:adivya1.singh@gmail.com> > <mailto:adivya1.singh@gmail.com <mailto:adivya1.singh@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 >

On 7/5/22 8:52 AM, Adivya Singh wrote:

hi Brian,

Regarding the Policy.Json, it is working fine for 3 Controllers have a individual Glance Container

But I have another scenario, where only One controller holds the Glance Image , but the same steps I do for the same, it fails with error code 403.

Since the 403 is the default behavior, it sounds to me like your custom policy.yaml file isn't being found in your single-controller setup. Check the [oslo_policy]/policy_file config option in your glance-api.conf to make sure it's got the correct value. That's all I can think of at the moment; maybe someone else will have a better idea. cheers, brian

Regards Adivya Singh

On Wed, Jun 15, 2022 at 2:04 AM Brian Rosmaita <rosmaita.fossdev@gmail.com <mailto:rosmaita.fossdev@gmail.com>> wrote:

On 6/14/22 2:18 PM, Adivya Singh wrote: > Hi Takashi, > > when a user upload images which is a member , The image will be set to > private. > > This is what he is asking for access to make it public,  The above rule > applies for only public images Alan and Takashi have both given you good advice:

- By default, Glance assumes that your custom policy file is named "policy.yaml".  If it doesn't have that name, Glance will assume it does not exist and will use the defaults defined in code.  You can change the filename glance will look for in your glance-api.conf -- look for [oslo_policy]/policy_file

- We recommend that you use YAML instead of JSON to write your policy file because YAML allows comments, which you will find useful in documenting any changes you make to the file

- You want to keep the permissions on modify_image at their default value, because otherwise users won't be able to do simple things like add image properties to their own images

- Some image properties can affect the system or other users.  Glance will not allow *any* user to modify some system properties (for example, 'id', 'status'), and it requires additional permission along with modify_image to set 'public' or 'community' for image visibility.

- It's also possible to configure property protections to require additional permission to CRUD specific properties (the default setting is *not* to do this).

For your particular use case, where you want a specific user to be able to publicize_image, I would encourage you to think more carefully about what exactly you want to accomplish.  Traditionally, images with 'public' visibility are provided by the cloud operator, and this gives image consumers some confidence that there's nothing malicious on the image.  Public images are accessible to all users, and they will show up in the default image-list call for all users, so if a public image contains something nasty, it can spread very quickly.

Glance provides four levels of image visibility:

- private: only visible to users in the project that owns the image

- shared: visible to users in the project that owns the image *plus* any projects that are added to the image as "members".  (A shared image with no members is effectively a private image.)  See [0] for info about how image sharing is designed and what API calls are associated with it. There are a bunch of policies around this; the defaults are basically what you'd expect, with the image owner being able to add and delete members, and image members being able to 'accept' or 'reject' shared images.

- community: accessible to everyone, but only visible if you look for them.  See [1] for an explanation of what that means.  The ability to set 'community' visibility on an image is controlled by the "communitize_image" policy (default is admin-or-owner).

- public: accessible to everyone, and easily visible to all users. Controlled by the "publicize_image" policy (default is admin-only).

You're running your own cloud, so you can configure things however you like, but I encourage you to think carefully before handing out publicize_image permission, and consider whether one of the other visibilities can accomplish what you want.

For more info, the introductory section on "Images" in the api-ref [2] has a useful discussion of image properties and image visibility.

The final thing I want to stress is that you should be sure to test carefully any policies you define in a custom policy file.  You are actually having a good problem, that is, someone can't do something you would like them to.  The way worse problem happens when in addition to that someone being able to do what you want them to, a whole bunch of other users can also do that same thing.

OK, so to get to your particular issue:

- you don't want to change the "modify_image" policy in the way you proposed in your email, because no one (other than the person having the 'user role) will be able to do any kind of image updates.

- if you decide to give that user publicize_image permissions, be careful how you do it.  For example,    "publicize_image": "role:user" won't allow an admin to make images public (unless you also give each admin the 'user' role).  If you look at most of the policies in the Xena policy.yaml.sample, they begin "role:admin or ...".

- the reason you were seeing the 403 when you tried to do      openstack image set --public <image id> as the user with the 'user' property is that you were allowed to modify_image but when you tried to change the visibility, you did not have permission (because the default for that is role:admin)

Hope this helps!  Once you get this figured out, you may want to put up a patch to update the Glance documentation around policies.  I think everything said above is in there somewhere, but it may not be in the most obvious places.

Actually, there is one more thing.  The above all applies to Xena, but there's been some work around policies in Yoga and more happening in Zed, so be sure to read the Glance release notes when you eventually upgrade.

[0] https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-imag... <https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html> [1] https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-imag... <https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html#sharing-images-with-all-users> [2] https://docs.openstack.org/api-ref/image/v2/index.html#images <https://docs.openstack.org/api-ref/image/v2/index.html#images>

> > regards > Adivya Singh > > On Tue, Jun 14, 2022 at 10:54 AM Takashi Kajinami <tkajinam@redhat.com <mailto:tkajinam@redhat.com> > <mailto:tkajinam@redhat.com <mailto:tkajinam@redhat.com>>> wrote: > >     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 <https://docs.openstack.org/glance/xena/admin/policies.html> >     <https://docs.openstack.org/glance/xena/admin/policies.html <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@gmail.com <mailto:adivya1.singh@gmail.com> <mailto:adivya1.singh@gmail.com <mailto:adivya1.singh@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@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@redhat.com <mailto:abishop@redhat.com> <mailto:abishop@redhat.com <mailto:abishop@redhat.com>>> wrote: > > > >                 On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita >                 <rosmaita.fossdev@gmail.com <mailto:rosmaita.fossdev@gmail.com> >                 <mailto:rosmaita.fossdev@gmail.com <mailto:rosmaita.fossdev@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@gmail.com <mailto:adivya1.singh@gmail.com> >                     <mailto:adivya1.singh@gmail.com <mailto:adivya1.singh@gmail.com>> >                      > <mailto:adivya1.singh@gmail.com <mailto:adivya1.singh@gmail.com> >                     <mailto:adivya1.singh@gmail.com <mailto:adivya1.singh@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 >                      > > >