| *** mhen_ is now known as mhen | 01:48 | |
| opendevreview | Dmitriy Rabotyagov proposed openstack/keystone master: [DNM] Ensure that upgrade test fails https://review.opendev.org/c/openstack/keystone/+/932513 | 07:29 |
|---|---|---|
| opendevreview | Dmitriy Rabotyagov proposed openstack/keystone master: [DNM] Ensure that upgrade test fails https://review.opendev.org/c/openstack/keystone/+/932513 | 07:33 |
| mhen | admiyo: fwiw, the policy rule you quoted has changed as we recently introduced the domain manager persona. If you have the "manager" role in domain scope, you can now assign/revoke roles (except admin) between users/projects/groups within the domain you have the "manager" role on. | 08:04 |
| mhen | you can check https://review.opendev.org/q/topic:%22domain-manager%22 for more details | 08:07 |
| mhen | (it's available starting with the 2024.2 release) | 08:13 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/keystone master: [DNM] Ensure that upgrade test fails https://review.opendev.org/c/openstack/keystone/+/932513 | 09:49 |
| stephenfin | d34dh0r53: Not sure if you saw my post on openstack-discuss, but I'd like your input on https://review.opendev.org/c/openstack/devstack/+/932198/ when you've a moment | 10:29 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/keystone master: [DNM] Ensure that upgrade test fails https://review.opendev.org/c/openstack/keystone/+/932513 | 13:57 |
| admiyo | mhen, what I quoted was right out of the policy generated from the master branch. So it has not been implemented yet. But it sounds like a step in the right direction. A further step would be to limit role assignments to roles that the assigner themself has assigned. So a manager can assign no-higher than manager, and, if you let members assign roles, they can assign the member role. Or Reader. That is the power | 14:47 |
| admiyo | of implied role assignments | 14:47 |
| mhen | admiyo: it has been implemented, for SRBAC at least (enforce_new_defaults=True): | 14:57 |
| mhen | https://github.com/openstack/keystone/blob/master/keystone/common/policies/grant.py#L252 | 14:57 |
| mhen | https://github.com/openstack/keystone/blob/master/keystone/common/policies/grant.py#L64-L91 | 14:57 |
| mhen | this is on master as well as stable/2024.2 | 14:57 |
| mhen | did you generate with the new SRBAC disabled? | 14:58 |
| mhen | (then it wouldn't appear I guess) | 14:58 |
| admiyo | I just generated with defaults | 14:59 |
| mhen | is SRBAC not default yet in Keystone? I thought it was ... | 14:59 |
| admiyo | mhen, I also have a test failing due to a missing rule in policy. | 14:59 |
| admiyo | Seems odd | 14:59 |
| admiyo | I think I might be out of sync....trying again | 15:00 |
| admiyo | But GRANTS_DOMAIN_ADMIN in the rule ADMIN_OR_DOMAIN_ADMIN_OR_DOMAIN_MANAGER, is useless. it will never get evaluated. since role:admin passes, there is no reason to also check "role:admin and DOMAIN_MATCHES_USER_DOMAIN + ' and' ' ' + DOMAIN_MATCHES_PROJECT_DOMAIN " | 15:05 |
| admiyo | All of the admin rules should go away, except for the global one | 15:06 |
| admiyo | The more I think about it, the more I am convinced that you are also going to want to add the is_admin_project flag. | 15:07 |
| admiyo | Right now, you have a proliferation of people assigned the admin role all over the place. You need a transition plan to remove that power from people that should not have it. | 15:07 |
| admiyo | Its like everyone running on a linux box with root | 15:07 |
| admiyo | or the good old days of Windows NT with everything done as Administrator | 15:08 |
| admiyo | If you start by saying all projects are admin projects, you can then selectively remove that flag until on the the real admins have the admin role. | 15:08 |
| admiyo | OK this is what I get for the generated policy for create grant.... | 15:09 |
| admiyo | #"identity:create_grant": "(rule:admin_required) or ((role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.user.domain_id)s and domain_id:%(target.domain.id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:admin and domain_id:%(target.group.domain_id)s and domain_id:%(target.domai | 15:09 |
| admiyo | n.id)s)) and (domain_id:%(target.role.domain_id)s or None:%(target.role.domain_id)s) or ((role:manager and domain_id:%(target.user.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:manager and domain_id:%(target.user.domain_id)s and domain_id:%(target.domain.id)s) or (role:manager and domain_id:%(target.group.domain_id)s and domain_id:%(target.project.domain_id)s) or (role:manager and domain_id:%(target.gr | 15:09 |
| admiyo | oup.domain_id)s and domain_id:%(target.domain.id)s)) and rule:domain_managed_target_role" | 15:09 |
| admiyo | so you can safely drop half that rule and make it more legible | 15:10 |
| admiyo | Why is there None:%(target.role.domain_id)s) in the middle there? | 15:12 |
| admiyo | DOMAIN_MATCHES_ROLE = ( | 15:12 |
| admiyo | 'domain_id:%(target.role.domain_id)s or None:%(target.role.domain_id)s' | 15:12 |
| admiyo | ) | 15:12 |
| admiyo | INteresting. Not sure I get that | 15:13 |
| mhen | oh that one, one second | 15:21 |
| admiyo | I think it is the default rule | 15:22 |
| admiyo | https://opendev.org/openstack/oslo.policy/src/branch/master/oslo_policy/policy.py#L213 | 15:23 |
| admiyo | policy_default_rule` from the config file then takes over.... | 15:23 |
| mhen | it's from here I believe: https://github.com/openstack/keystone/blob/master/keystone/common/policies/grant.py#L30-L32 | 15:25 |
| admiyo | #policy_default_rule = default | 15:25 |
| mhen | the None:%(target.role.domain_id)s) checks if the role is either a role within the same domain or a global role (global role has no domain_id attribute) | 15:25 |
| admiyo | Yeah I found that. I think it resolves to default | 15:25 |
| admiyo | and that is not in the policy file generated, so must be in the enforcement somewhere. It is a strange rule, I wonder what lbragstad was thinking. | 15:26 |
| admiyo | policy.RuleDefault( | 15:27 |
| admiyo | name="domain_managed_target_role", | 15:27 |
| admiyo | check_str=DOMAIN_MANAGER_ALLOWED_ROLES, | 15:27 |
| admiyo | ), | 15:27 |
| admiyo | ] | 15:27 |
| admiyo | So maybe he is trying to say that only non-admin roles can be assigned? | 15:27 |
| mhen | yes, this is the part that I added to restrict the roles a domain-manager can assign/revoke so that he cannot escalate privileges beyond their own (e.g. assign admin role) | 15:29 |
| admiyo | None is a strange way to specify it. | 15:31 |
| mhen | what? | 15:31 |
| mhen | I was referring to the DOMAIN_MANAGER_ALLOWED_ROLES part | 15:31 |
| mhen | not the None rule | 15:31 |
| admiyo | Yeah. I have no idea what that None is doing | 15:31 |
| admiyo | DOMAIN_MANAGER_ALLOWED_ROLES should be generated from implied roles. You cannot assign a role you do not have. And manager should then imply the other two. | 15:32 |
| admiyo | keeps you from having someone break policy by using a different name than domain mananager | 15:32 |
| admiyo | The only hard coded inference rule is that no rule can imply admin | 15:33 |
| mhen | "I have no idea what that None is doing" - are you referring to https://github.com/openstack/keystone/blob/master/keystone/common/policies/grant.py#L30-L32 ? | 15:34 |
| admiyo | Yeah | 15:34 |
| admiyo | I feel like I am reading Lewis Carroll | 15:35 |
| mhen | as I said, I believe this means "... or the role has no domain_id set, which means it is a global role, not bound to a domain" in plain words | 15:35 |
| admiyo | By default, the rule | 15:35 |
| admiyo | associated with the rule name of ``default`` will be used as the default | 15:35 |
| admiyo | rule. It is possible to use a different rule name as the default rule | 15:35 |
| admiyo | by setting the ``policy_default_rule`` | 15:35 |
| admiyo | I believe you beieve that. I do not see how the code enforces that | 15:36 |
| mhen | you mean that "global role means that the role object has domain_id=None" is not how it is actually implemented? | 15:37 |
| mhen | (role object during the Enforcer call, to be specific) | 15:38 |
| admiyo | None:%(target.role.domain_id)s seems to match the rule https://opendev.org/openstack/oslo.policy/src/branch/master/oslo_policy/_checks.py#L285 | 15:38 |
| admiyo | I just don't understand what it means to have None: in a policy | 15:39 |
| mhen | we have a similar thing (a negative None check) here: https://github.com/openstack/keystone/blob/master/keystone/common/policies/role.py#L23-L29 | 15:40 |
| admiyo | That is different | 15:40 |
| admiyo | :None is the value looked up in a dictionary. I know what that means. | 15:40 |
| admiyo | But when the rule is None: I think it means use the default rule | 15:40 |
| admiyo | @register(None) | 15:41 |
| admiyo | But the rule name is then supposed to be used as the key name in a dictionary lookup, and there will never be a key named None | 15:41 |
| admiyo | so I am missing somehting | 15:41 |
| mhen | https://docs.openstack.org/oslo.policy/latest/admin/policy-yaml-file.html#examples | 15:43 |
| mhen | See the "A simple comparison can be done using a literal value" part | 15:43 |
| mhen | from that I'd deduce that it's a literal None value as in Python's None | 15:43 |
| mhen | But I have to admit, I found it very hard to understand all the intricate details of the oslo policy language just from that documentation | 15:44 |
| admiyo | SO you are saying that it is doing the rule None == attribute | 15:44 |
| admiyo | And it might be written that way because of the dictionary lookup can fail at any step of the path... | 15:44 |
| admiyo | https://opendev.org/openstack/oslo.policy/src/branch/master/oslo_policy/_checks.py#L318 | 15:45 |
| admiyo | Nope: a key error returns false | 15:45 |
| admiyo | hmmm | 15:45 |
| admiyo | None = Dict()[None] | 15:46 |
| admiyo | x = dict()[None] | 15:47 |
| admiyo | Traceback (most recent call last): | 15:47 |
| admiyo | File "<stdin>", line 1, in <module> | 15:47 |
| admiyo | KeyError: None | 15:47 |
| mhen | sorry, that's way over my head right now - I would need to read the oslo_policy implementation closely | 15:48 |
| admiyo | I have never seen None: as a key before. | 15:49 |
| mhen | doing a quick search there seem to be more: https://github.com/openstack/keystone/blob/6433f1ae1c094e58216360d191a21d956a80f658/keystone/common/policies/limit.py#L26 | 15:50 |
| admiyo | I blame Henry | 15:50 |
| admiyo | and not | 15:51 |
| admiyo | That is fine, If it is the dictionary lookup.. THat is saying that target.limit.project_id | 15:51 |
| admiyo | so, if the first part does not match, the or is evaluated, and if there is nothing in target.limit.project_id it is OK. It is abuse, but it kinda makes sense. The Not makes it pass. But in the case above it will never pass | 15:53 |
| admiyo | a None: check can never pass IIUC | 15:53 |
| admiyo | And I doubt IUC | 15:54 |
| admiyo | OK, back to my day job | 15:54 |
| cardoe | mnaser: (poking you here since it's keystone related and not sure what better channel to use) could you review my two keystoneauth-websso PRs and possibly cut a new release? | 17:14 |
| admiyo | cardoe, links? | 17:26 |
| cardoe | admiyo: https://github.com/vexxhost/keystoneauth-websso/pull/11 adds Python 3.13 support and https://github.com/vexxhost/keystoneauth-websso/pull/12 is just a niceness factor for me. | 17:33 |
| cardoe | The other reason I asked for a release is https://github.com/vexxhost/keystoneauth-websso/pull/10 which replaced Python 2 only code with Python 3 since it fails in Python 3 and it says the code is only for Python 3. | 17:33 |
| admiyo | Ah...github and websso. New project for me. | 17:35 |
| cardoe | It's really something quite old. There's an older project its based on and at least one person in here uses it for their setup. But it makes using OIDC from the CLI quite smooth. | 17:48 |
| cardoe | I've asked about including it in keystoneauth proper and there were some yays and some nays. | 17:48 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON Schema to `application credentials` and validation decorators to application credential resource. https://review.opendev.org/c/openstack/keystone/+/925517 | 20:11 |
| opendevreview | Antonia Gaete proposed openstack/keystone master: Add JSON schema to `trust` and validation decorators to trust resource. https://review.opendev.org/c/openstack/keystone/+/930361 | 21:56 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!