<div dir="ltr">hi Brian,<div><br></div><div>Regarding the Policy.Json, it is working fine for 3 Controllers have a individual Glance Container</div><div><br></div><div>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.</div><div><br></div><div>Regards</div><div>Adivya Singh</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 15, 2022 at 2:04 AM Brian Rosmaita <<a href="mailto:rosmaita.fossdev@gmail.com">rosmaita.fossdev@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/14/22 2:18 PM, Adivya Singh wrote:<br>
> Hi Takashi,<br>
> <br>
> when a user upload images which is a member , The image will be set to <br>
> private.<br>
> <br>
> This is what he is asking for access to make it public, The above rule <br>
> applies for only public images<br>
Alan and Takashi have both given you good advice:<br>
<br>
- By default, Glance assumes that your custom policy file is named <br>
"policy.yaml". If it doesn't have that name, Glance will assume it does <br>
not exist and will use the defaults defined in code. You can change the <br>
filename glance will look for in your glance-api.conf -- look for <br>
[oslo_policy]/policy_file<br>
<br>
- We recommend that you use YAML instead of JSON to write your policy <br>
file because YAML allows comments, which you will find useful in <br>
documenting any changes you make to the file<br>
<br>
- You want to keep the permissions on modify_image at their default <br>
value, because otherwise users won't be able to do simple things like <br>
add image properties to their own images<br>
<br>
- Some image properties can affect the system or other users. Glance <br>
will not allow *any* user to modify some system properties (for example, <br>
'id', 'status'), and it requires additional permission along with <br>
modify_image to set 'public' or 'community' for image visibility.<br>
<br>
- It's also possible to configure property protections to require <br>
additional permission to CRUD specific properties (the default setting <br>
is *not* to do this).<br>
<br>
For your particular use case, where you want a specific user to be able <br>
to publicize_image, I would encourage you to think more carefully about <br>
what exactly you want to accomplish. Traditionally, images with <br>
'public' visibility are provided by the cloud operator, and this gives <br>
image consumers some confidence that there's nothing malicious on the <br>
image. Public images are accessible to all users, and they will show up <br>
in the default image-list call for all users, so if a public image <br>
contains something nasty, it can spread very quickly.<br>
<br>
Glance provides four levels of image visibility:<br>
<br>
- private: only visible to users in the project that owns the image<br>
<br>
- shared: visible to users in the project that owns the image *plus* any <br>
projects that are added to the image as "members". (A shared image with <br>
no members is effectively a private image.) See [0] for info about how <br>
image sharing is designed and what API calls are associated with it. <br>
There are a bunch of policies around this; the defaults are basically <br>
what you'd expect, with the image owner being able to add and delete <br>
members, and image members being able to 'accept' or 'reject' shared images.<br>
<br>
- community: accessible to everyone, but only visible if you look for <br>
them. See [1] for an explanation of what that means. The ability to <br>
set 'community' visibility on an image is controlled by the <br>
"communitize_image" policy (default is admin-or-owner).<br>
<br>
- public: accessible to everyone, and easily visible to all users. <br>
Controlled by the "publicize_image" policy (default is admin-only).<br>
<br>
You're running your own cloud, so you can configure things however you <br>
like, but I encourage you to think carefully before handing out <br>
publicize_image permission, and consider whether one of the other <br>
visibilities can accomplish what you want.<br>
<br>
For more info, the introductory section on "Images" in the api-ref [2] <br>
has a useful discussion of image properties and image visibility.<br>
<br>
The final thing I want to stress is that you should be sure to test <br>
carefully any policies you define in a custom policy file. You are <br>
actually having a good problem, that is, someone can't do something you <br>
would like them to. The way worse problem happens when in addition to <br>
that someone being able to do what you want them to, a whole bunch of <br>
other users can also do that same thing.<br>
<br>
OK, so to get to your particular issue:<br>
<br>
- you don't want to change the "modify_image" policy in the way you <br>
proposed in your email, because no one (other than the person having the <br>
'user role) will be able to do any kind of image updates.<br>
<br>
- if you decide to give that user publicize_image permissions, be <br>
careful how you do it. For example,<br>
"publicize_image": "role:user"<br>
won't allow an admin to make images public (unless you also give each <br>
admin the 'user' role). If you look at most of the policies in the Xena <br>
policy.yaml.sample, they begin "role:admin or ...".<br>
<br>
- the reason you were seeing the 403 when you tried to do<br>
openstack image set --public <image id><br>
as the user with the 'user' property is that you were allowed to <br>
modify_image but when you tried to change the visibility, you did not <br>
have permission (because the default for that is role:admin)<br>
<br>
Hope this helps! Once you get this figured out, you may want to put up <br>
a patch to update the Glance documentation around policies. I think <br>
everything said above is in there somewhere, but it may not be in the <br>
most obvious places.<br>
<br>
Actually, there is one more thing. The above all applies to Xena, but <br>
there's been some work around policies in Yoga and more happening in <br>
Zed, so be sure to read the Glance release notes when you eventually <br>
upgrade.<br>
<br>
<br>
[0] <br>
<a href="https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html</a><br>
[1] <br>
<a href="https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html#sharing-images-with-all-users" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/glance-specs/specs/api/v2/sharing-image-api-v2.html#sharing-images-with-all-users</a><br>
[2] <a href="https://docs.openstack.org/api-ref/image/v2/index.html#images" rel="noreferrer" target="_blank">https://docs.openstack.org/api-ref/image/v2/index.html#images</a><br>
<br>
> <br>
> regards<br>
> Adivya Singh<br>
> <br>
> On Tue, Jun 14, 2022 at 10:54 AM Takashi Kajinami <<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a> <br>
> <mailto:<a href="mailto:tkajinam@redhat.com" target="_blank">tkajinam@redhat.com</a>>> wrote:<br>
> <br>
> Glance has a separate policy rule (publicize_image) for<br>
> creating/updating public images.,<br>
> and you should define that policy rule instead of modify_image.<br>
> <br>
> <a href="https://docs.openstack.org/glance/xena/admin/policies.html" rel="noreferrer" target="_blank">https://docs.openstack.org/glance/xena/admin/policies.html</a><br>
> <<a href="https://docs.openstack.org/glance/xena/admin/policies.html" rel="noreferrer" target="_blank">https://docs.openstack.org/glance/xena/admin/policies.html</a>><br>
> ~~~<br>
> |publicize_image| - Create or update public images<br>
> ~~~<br>
> <br>
> AFAIK The modify_image policy defaults to rule:default and is<br>
> allowed for any users<br>
> as long as the target image is owned by that user.<br>
> <br>
> <br>
> On Tue, Jun 14, 2022 at 2:01 PM Adivya Singh<br>
> <<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a> <mailto:<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a>>> wrote:<br>
> <br>
> Hi Brian,<br>
> <br>
> Please find the response<br>
> <br>
> 1> i am using Xena release version 24.0.1<br>
> <br>
> Now the scenario is line below, my customer wants to have<br>
> their login access on setting up the properties of an image<br>
> to the public. now what i did is<br>
> <br>
> 1> i created a role in openstack using the admin credential<br>
> name as "user"<br>
> 2> i assigned that user to a role user.<br>
> 3> i assigned those user to those project id, which they<br>
> want to access as a user role<br>
> <br>
> Then i went to Glance container which is controller by lxc<br>
> and made a policy.yaml file as below<br>
> <br>
> root@aio1-glance-container-724aa778:/etc/glance# cat policy.yaml<br>
> <br>
> "modify_image": "role:user"<br>
> <br>
> then i went to utility container and try to set the<br>
> properties of a image using openstack command<br>
> <br>
> openstack image set --public <image id><br>
> <br>
> and then i got this error<br>
> <br>
> HTTP 403 Forbidden: You are not authorized to complete<br>
> publicize_image action.<br>
> <br>
> Even when i am trying the upload image with this user , i<br>
> get the above error only<br>
> <br>
> export OS_ENDPOINT_TYPE=internalURL<br>
> export OS_INTERFACE=internalURL<br>
> export OS_USERNAME=adsingh<br>
> export OS_PASSWORD='adsingh'<br>
> export OS_PROJECT_NAME=adsingh<br>
> export OS_TENANT_NAME=adsingh<br>
> export OS_AUTH_TYPE=password<br>
> export OS_AUTH_URL=https://<Internal IP of horizon>:5000/v3<br>
> export OS_NO_CACHE=1<br>
> export OS_USER_DOMAIN_NAME=Default<br>
> export OS_PROJECT_DOMAIN_NAME=Default<br>
> export OS_REGION_NAME=RegionOne<br>
> <br>
> Regards<br>
> Adivya Singh<br>
> <br>
> <br>
> <br>
> On Mon, Jun 13, 2022 at 6:41 PM Alan Bishop<br>
> <<a href="mailto:abishop@redhat.com" target="_blank">abishop@redhat.com</a> <mailto:<a href="mailto:abishop@redhat.com" target="_blank">abishop@redhat.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On Mon, Jun 13, 2022 at 6:00 AM Brian Rosmaita<br>
> <<a href="mailto:rosmaita.fossdev@gmail.com" target="_blank">rosmaita.fossdev@gmail.com</a><br>
> <mailto:<a href="mailto:rosmaita.fossdev@gmail.com" target="_blank">rosmaita.fossdev@gmail.com</a>>> wrote:<br>
> <br>
> On 6/13/22 8:29 AM, Adivya Singh wrote:<br>
> > hi Team,<br>
> ><br>
> > Any thoughts on this<br>
> <br>
> H Adivya,<br>
> <br>
> Please supply some more information, for example:<br>
> <br>
> - which openstack release you are using<br>
> - the full API request you are making to modify the<br>
> image<br>
> - the full API response you receive<br>
> - whether the user with "role:user" is in the same<br>
> project that owns the<br>
> image<br>
> - debug level log extract for this call if you have it<br>
> - anything else that could be relevant, for example,<br>
> have you modified<br>
> any other policies, and if so, what values are you<br>
> using now?<br>
> <br>
> <br>
> Also bear in mind that the default policy_file name is<br>
> "policy.yaml" (not .json). You either<br>
> need to provide a policy.yaml file, or override the<br>
> policy_file setting if you really want to<br>
> use policy.json.<br>
> <br>
> Alan<br>
> <br>
> cheers,<br>
> brian<br>
> <br>
> ><br>
> > Regards<br>
> > Adivya Singh<br>
> ><br>
> > On Sat, Jun 11, 2022 at 12:40 AM Adivya Singh<br>
> <<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a><br>
> <mailto:<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a>><br>
> > <mailto:<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a><br>
> <mailto:<a href="mailto:adivya1.singh@gmail.com" target="_blank">adivya1.singh@gmail.com</a>>>> wrote:<br>
> ><br>
> > Hi Team,<br>
> ><br>
> > I have a use case where I have to give a user<br>
> restriction on<br>
> > updating the image properties as a member.<br>
> ><br>
> > I have created a policy Json file and give<br>
> the modify_image rule to<br>
> > the particular role, but still it is not working<br>
> ><br>
> > "modify_image": "role:user", This role is<br>
> created in OpenStack.<br>
> ><br>
> > but still it is failing while updating<br>
> properties with a<br>
> > particular user assigned to a role as "access<br>
> denied" and<br>
> > unauthorized access<br>
> ><br>
> > Regards<br>
> > Adivya Singh<br>
> ><br>
> <br>
> <br>
<br>
<br>
</blockquote></div>