Regarding Policy.json entries for glance image update not working for a user
Brian Rosmaita
rosmaita.fossdev at gmail.com
Wed Jul 6 19:33:19 UTC 2022
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 at gmail.com <mailto: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
> <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
> <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 at redhat.com <mailto:tkajinam at redhat.com>
> > <mailto: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>
> > <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>
> <mailto: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>
> <mailto: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>
> > <mailto: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>>
> > > <mailto: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
> > >
> >
> >
>
>
More information about the openstack-discuss
mailing list