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