<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>