Open Stack

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.

Regards
Adivya Singh

On Wed, Jun 15, 2022 at 2:04 AM Brian Rosmaita <rosmaita.fossdev at 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-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
> >                      >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220705/fa60b843/attachment-0001.htm>