<div>- все</div><div> </div><div>Hi!</div><div> </div><div>In OSA I've already started topic [1] quite a while ago, that adds service role in addition to admin one for the migration purposes.</div><div>It was intended, that admin can be revoked later on if needed.</div><div> </div><div>So I based on my understanding of the thread, that is exactly the plan for keystone as well.</div><div> </div><div> </div><div>[1] https://review.opendev.org/q/topic:%22osa%252Fservice_tokens%22+(status:open%20OR%20status:merged)</div><div> </div><div>19.01.2022, 12:43, "Mark Goddard" <mark@stackhpc.com>:</div><blockquote><p>Hi,<br /><br />If you haven't been paying close attention, it would be easy to miss<br />some of the upcoming RBAC changes which will have an impact on<br />deployment projects. I thought I'd start a thread so that we can share<br />how we are approaching this, get answers to open questions, and<br />ideally all end up with a fairly consistent approach.<br /><br />The secure RBAC work has a long history, and continues to evolve.<br />According to [1], we should start to see some fairly substantial<br />changes over the next few releases. That spec is fairly long, but<br />worth a read.<br /><br />In the yoga timeline [2], there is one change in particular that has<br />an impact on deployment projects, "3. Keystone enforces scope by<br />default". After this change, all of the deprecated policies that many<br />still rely on in Keystone will be removed.<br /><br />In kolla-ansible, we have an etherpad [5] with some notes, questions<br />and half-baked plans. We made some changes in Xena [3] to use system<br />scope in some places when interacting with system APIs in Ansible<br />tasks.<br /><br />The next change we have staged is to add the service role to all<br />service users [4], in preparation for [2].<br /><br />Question: should the role be added with system scope or in the<br />existing service project? The obvious main use for this is token<br />validation, which seems to allow system or project scope.<br /><br />We anticipate that some service users may still require some<br />project-scoped roles, e.g. when creating resources for octavia. We'll<br />deal with those on a case by case basis.<br /><br />In anticipation of keystone setting enforce_scope=True and removing<br />old default policies (which I assume effectively removes<br />enforce_new_defaults?), we will set this in kolla-ansible, and try to<br />deal with any fallout. Hopefully the previous work will make this<br />minimal.<br /><br />How does that line up with other projects' approaches? What have we missed?<br /><br />Mark<br /><br />[1] <a href="https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst" rel="noopener noreferrer">https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst</a><br />[2] <a href="https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022" rel="noopener noreferrer">https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022</a><br />[3] <a href="https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7" rel="noopener noreferrer">https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7</a><br />[4] <a href="https://review.opendev.org/c/openstack/kolla-ansible/+/815577" rel="noopener noreferrer">https://review.opendev.org/c/openstack/kolla-ansible/+/815577</a><br />[5] <a href="https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible" rel="noopener noreferrer">https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible</a><br /> </p></blockquote><div> </div><div> </div><div>-- <br />Kind Regards,</div><div>Dmitriy Rabotyagov</div><div> </div>