Open Stack

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-image-api-v2.html
[1] 
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

> 
> regards
> Adivya Singh
> 
> On Tue, Jun 14, 2022 at 10:54 AM Takashi Kajinami <tkajinam at redhat.com 
> <mailto:tkajinam at 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 at gmail.com <mailto: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 <mailto:abishop at redhat.com>> wrote:
> 
> 
> 
>                 On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita
>                 <rosmaita.fossdev at gmail.com
>                 <mailto: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>
>                      > <mailto: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
>                      >
> 
>