<div dir="ltr"><div>Thanks again !</div><div><br></div><div>Out of curiosity, why the operation to access the console of an instance wasn't considered a "destructive action" ?</div><div>This allows to send a ctrl-alt-del ...</div><div><br></div><div>Cheers, Massimo</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 7:18 PM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.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 Wed, 03 Jun 2020 11:17:41 -0500 Massimo Sgaravatto <<a href="mailto:massimo.sgaravatto@gmail.com" target="_blank">massimo.sgaravatto@gmail.com</a>> wrote ----<br>
 > Thank you !<br>
 > The "destructive actions" I guess are the ones listed here:<br>
 > <a href="https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/user-id-based-policy-enforcement.html</a><br>
 > <br>
 > In this page there is also the link to the ML thread you were talking about<br>
 > So the user_id based policy enforcement for those destructive actions is supposed to work till Train ? Did I get it right ?<br>
<br>
Yes, that is the exact list we kept the user_id restriction support for backword compatilbity. They will keep running till Ussuri for sure.<br>
Please ntoe, we might cleanup those in Victoria cycle in favor of new defaults.<br>
<br>
-gmann <br>
<br>
 > Thanks, Massimo<br>
 > <br>
 > On Wed, Jun 3, 2020 at 3:53 PM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>> wrote:<br>
 >  ---- On Wed, 03 Jun 2020 01:18:41 -0500 Massimo Sgaravatto <<a href="mailto:massimo.sgaravatto@gmail.com" target="_blank">massimo.sgaravatto@gmail.com</a>> wrote ----<br>
 >  > Hi<br>
 >  > In my Rocky installation I am preventing users from deleting instances created by other users of the same project.This was implemented setting in the nova policy file:<br>
 >  > <br>
 >  > "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s"<br>
 >  > <br>
 >  > This works, even if in the nova log file I see:<br>
 >  > The user_id attribute isn't supported in the rule 'os_compute_api:servers:delete'. All the user_id based policy enforcement will be removed in the future.<br>
 >  > <br>
 >  > Now I would also like preventing user to see the console log file of instances created by other users. I set in the nova policy file:<br>
 >  > "os_compute_api:os-console-output" : "rule:admin_api or user_id:%(user_id)s"<br>
 > <br>
 > Nova does not restrict the policy by user_id except keypairs API or a few of the destructive actions( which I think we supported for backwards compatiblity and<br>
 > intent to remove it later that is why you can see the warning).  I remember we discussed this in 2016 but I could not find the ML thread for that but<br>
 > the consensus that time was we do not intend to support user_id based restriction permission in the API.<br>
 > <br>
 > On the same note,  ussuri onwards you can enforce some user-level restriction based on the role, but not by user_id. In the Ussuri cycle, we have implemented<br>
 > the keystone new defaults roles in nova policy. You can assign read and write roles for users and achieve the user's isolation within same project. <br>
 > Please refer this doc to know more details on those new policies<br>
 > - <a href="https://docs.openstack.org/nova/latest/configuration/policy-concepts.html" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/policy-concepts.html</a><br>
 > <br>
 > -gmann<br>
 > <br>
 >  > <br>
 >  > but this doesn't work<br>
 >  > Any hints ?<br>
 >  > More in general: were the user_id based policy eventually removed in latest OpenStack releases ?Which are then the  possible alternatives to implement my use case ?<br>
 >  > Thanks, Massimo<br>
 > <br>
</blockquote></div></div>