| prometheanfire | tonyb: ya | 00:17 |
|---|---|---|
| *** itlinux has joined #openstack-keystone | 00:17 | |
| prometheanfire | tonyb: https://github.com/openstack/ldappool/commit/459000d7aa3fa1ace05c800ff1273b99fbd8babe in https://github.com/openstack/ldappool/compare/2.2.0...2.3.1 | 00:17 |
| prometheanfire | tonyb: deps got updated, python-ldap>=3.0.0 which is not in queens upper-constraints | 00:18 |
| lbragstad | tonyb yep! | 00:22 |
| tonyb | prometheanfire: Interesting so we can't use that release on queens and possibly need to revert that change? | 00:22 |
| tonyb | the github UI is confusing for that kind of thing | 00:23 |
| prometheanfire | tonyb: no, just can't bump the version in queens because the deps of ldap-pool changed | 00:25 |
| prometheanfire | 15:12 < prometheanfire > dep was updated python-ldap>=3.0.0, not sure if that'll conflict with other stuff in queens | 00:26 |
| tonyb | prometheanfire: Okay that sounds wrong | 00:26 |
| prometheanfire | namely that python-ldap doesn't exist in queens | 00:26 |
| tonyb | Okay now I;m really confused | 00:26 |
| prometheanfire | ya, looking at pike it's not there too... | 00:27 |
| prometheanfire | https://github.com/openstack/ldappool/commit/f1d30bce9b48cd01f8421afe72a220662ce5f8ed | 00:28 |
| prometheanfire | that was part of 2.3.0, and the fix they want to consume is in 2.3.1 | 00:29 |
| prometheanfire | I'm still not sure how we don't have it | 00:30 |
| prometheanfire | python-ldap is in master at least | 00:30 |
| tonyb | prometheanfire: but that chnage is part of 2.3.X which is for rocky not queens why are we talking about queens? | 00:31 |
| tonyb | queens should be comsuming ldappool 2.2.X releases, rocky 2.3.X and stein 2.4.X | 00:32 |
| prometheanfire | ldappool in queens is 2.2 | 00:32 |
| prometheanfire | they want to updated it to at least the rocky version | 00:32 |
| tonyb | Oh | 00:32 |
| prometheanfire | because it contains https://github.com/openstack/ldappool/commit/459000d7aa3fa1ace05c800ff1273b99fbd8babe | 00:32 |
| tonyb | they can't | 00:32 |
| prometheanfire | yep | 00:32 |
| tonyb | they need to backport that to 2.2 without needed python-ldap | 00:33 |
| prometheanfire | yep | 00:33 |
| prometheanfire | nwilburn is gone from here though | 00:33 |
| tonyb | Okay. | 00:34 |
| tonyb | prometheanfire: I was confused becauise I said | 00:34 |
| tonyb | "so we can't use that release on queens" and you said "no" which I thought menat you were okay with using that release on queens | 00:35 |
| prometheanfire | oh, 'no, we can't use it on queens' | 00:35 |
| tonyb | prometheanfire: Okay | 00:35 |
| prometheanfire | yay:D | 00:35 |
| tonyb | Seems to me if pyldap exposes INVALID_CREDENTIALS then it's a simple backport + release | 00:37 |
| tonyb | and then bump to 2.2.1 on queens | 00:37 |
| prometheanfire | anyway, off to kill a dragon or lich or something | 00:38 |
| *** gmann_pto is now known as gmann | 01:07 | |
| *** markvoelker has joined #openstack-keystone | 01:40 | |
| *** markvoelker has quit IRC | 01:45 | |
| *** gyee has quit IRC | 01:50 | |
| *** erus_ has joined #openstack-keystone | 02:10 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 02:28 | |
| *** whoami-rajat has joined #openstack-keystone | 02:31 | |
| openstackgerrit | Adrian Turjak proposed openstack/keystone master: Add documentation for Auth Receipts and MFA https://review.openstack.org/580535 | 02:34 |
| *** markvoelker has joined #openstack-keystone | 02:51 | |
| *** raildo has quit IRC | 02:51 | |
| *** mhen has quit IRC | 02:57 | |
| *** mhen has joined #openstack-keystone | 02:58 | |
| *** jdennis has quit IRC | 03:29 | |
| *** jdennis has joined #openstack-keystone | 03:34 | |
| *** markvoelker has quit IRC | 03:53 | |
| *** Dinesh_Bhor has quit IRC | 04:07 | |
| *** eandersson has joined #openstack-keystone | 04:29 | |
| *** annp_ has joined #openstack-keystone | 04:42 | |
| eandersson | Anyone know an obvious reason why we would get a ton of "user is not a trustee" errors after upgrading to Rocky? | 04:51 |
| *** jrist has quit IRC | 04:54 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 04:55 | |
| *** markvoelker has joined #openstack-keystone | 04:59 | |
| *** vishakha has joined #openstack-keystone | 05:01 | |
| *** jrist has joined #openstack-keystone | 05:07 | |
| *** xek_ has joined #openstack-keystone | 05:11 | |
| *** xek has quit IRC | 05:12 | |
| *** lbragstad has quit IRC | 05:12 | |
| *** erus_ has quit IRC | 05:16 | |
| *** itlinux has quit IRC | 05:18 | |
| *** shyamb has joined #openstack-keystone | 05:42 | |
| *** markvoelker has quit IRC | 06:03 | |
| *** markvoelker has joined #openstack-keystone | 06:05 | |
| *** dave-mccowan has quit IRC | 06:41 | |
| *** Dinesh_Bhor has quit IRC | 06:41 | |
| *** prometheanfire has left #openstack-keystone | 06:43 | |
| *** Dinesh_Bhor has joined #openstack-keystone | 06:44 | |
| *** rcernin has quit IRC | 06:44 | |
| *** rcernin has joined #openstack-keystone | 06:44 | |
| *** Dinesh_Bhor has quit IRC | 06:58 | |
| *** rcernin has quit IRC | 07:03 | |
| *** shyamb has quit IRC | 07:09 | |
| *** pcaruana has joined #openstack-keystone | 07:51 | |
| *** shyamb has joined #openstack-keystone | 08:45 | |
| *** nsmeds has quit IRC | 08:51 | |
| *** markvoelker has quit IRC | 08:52 | |
| *** shyam89 has joined #openstack-keystone | 08:54 | |
| *** shyamb has quit IRC | 08:57 | |
| *** shyam89 has quit IRC | 09:05 | |
| *** shyam89 has joined #openstack-keystone | 09:05 | |
| openstackgerrit | wangxiyuan proposed openstack/keystone master: Fix app_cred schema spell nit https://review.openstack.org/629800 | 09:17 |
| *** shyam89 has quit IRC | 09:29 | |
| *** shyamb has joined #openstack-keystone | 09:38 | |
| *** markvoelker has joined #openstack-keystone | 09:49 | |
| *** markvoelker has quit IRC | 09:51 | |
| *** jaosorior has quit IRC | 10:00 | |
| *** itlinux has joined #openstack-keystone | 10:01 | |
| *** shyamb has quit IRC | 10:02 | |
| *** itlinux has quit IRC | 10:05 | |
| *** shyamb has joined #openstack-keystone | 10:06 | |
| *** yan0s has joined #openstack-keystone | 10:45 | |
| yan0s | Hi all | 10:46 |
| yan0s | I have a question on keystone federation | 10:46 |
| yan0s | should mappings be modified dynamically? | 10:47 |
| yan0s | for example if I want to extend a whitelist | 10:47 |
| yan0s | or should they be defined once and never change? | 10:48 |
| cmurphy | yan0s: you can change them after you define them | 10:51 |
| *** jaosorior has joined #openstack-keystone | 11:01 | |
| *** openstackgerrit has quit IRC | 11:05 | |
| yan0s | and this ok as a practice too? | 11:06 |
| *** shyamb has quit IRC | 11:29 | |
| cmurphy | yan0s: yes I would say so, same as regular users need new role assignments or new groups. you can use keystone-manage mapping_engine to test the new rules before you apply them for a tiny bit of extra safety | 11:30 |
| *** shyamb has joined #openstack-keystone | 11:42 | |
| *** shyamb has quit IRC | 11:44 | |
| *** shyamb has joined #openstack-keystone | 11:44 | |
| *** itlinux has joined #openstack-keystone | 12:01 | |
| *** itlinux has quit IRC | 12:06 | |
| *** shyamb has quit IRC | 12:12 | |
| *** shyamb has joined #openstack-keystone | 12:12 | |
| *** raildo has joined #openstack-keystone | 12:29 | |
| *** shyamb has quit IRC | 12:57 | |
| *** nwilburn has joined #openstack-keystone | 12:59 | |
| *** raildo has quit IRC | 13:13 | |
| *** dave-mccowan has joined #openstack-keystone | 13:18 | |
| *** raildo has joined #openstack-keystone | 13:24 | |
| *** vishakha has quit IRC | 13:39 | |
| *** dave-mccowan has quit IRC | 13:48 | |
| *** GregWaines has joined #openstack-keystone | 13:49 | |
| *** lbragstad has joined #openstack-keystone | 13:56 | |
| *** ChanServ sets mode: +o lbragstad | 13:56 | |
| *** lbragstad has quit IRC | 13:56 | |
| *** lbragstad has joined #openstack-keystone | 13:58 | |
| *** ChanServ sets mode: +o lbragstad | 13:58 | |
| lbragstad | o/ | 14:02 |
| cmurphy | \o | 14:02 |
| *** jmlowe has quit IRC | 14:16 | |
| *** mvkr has quit IRC | 14:29 | |
| *** jmlowe has joined #openstack-keystone | 14:33 | |
| *** vishakha has joined #openstack-keystone | 14:44 | |
| *** erus_ has joined #openstack-keystone | 14:49 | |
| *** jmlowe has quit IRC | 14:58 | |
| *** jmlowe has joined #openstack-keystone | 14:59 | |
| *** itlinux has joined #openstack-keystone | 15:01 | |
| *** itlinux has quit IRC | 15:06 | |
| *** mvkr has joined #openstack-keystone | 15:15 | |
| *** prometheanfire has joined #openstack-keystone | 15:39 | |
| prometheanfire | I'm not sure when it happened, but was requests-oauthlib a dep that was removed? | 15:41 |
| lbragstad | we had an interesting case there | 15:42 |
| lbragstad | we had issues with linting | 15:42 |
| lbragstad | https://github.com/oauthlib/oauthlib/issues/558 | 15:43 |
| prometheanfire | lbragstad: specifically talking about requests-oauthlib, I guess it's a dep of a dep since it's in upper-constraints and not in gr | 15:44 |
| prometheanfire | https://github.com/requests/requests-oauthlib/issues/356 | 15:44 |
| prometheanfire | that said, oauthlib-3.0.0 is released (but held back due to co-installability) | 15:45 |
| * prometheanfire needs to make a new etherpad for all the caps deps are putting in place... | 15:45 | |
| lbragstad | ahh - nevermind | 15:47 |
| prometheanfire | I could hold requests-oauthlib back instead (and will) | 15:47 |
| *** GregWaines has quit IRC | 15:53 | |
| *** openstackgerrit has joined #openstack-keystone | 16:13 | |
| openstackgerrit | Vishakha Agarwal proposed openstack/keystone master: Implement scope_type checking for role_assignments https://review.openstack.org/609210 | 16:13 |
| *** jmlowe has quit IRC | 16:25 | |
| gagehugo | lbragstad: additionalproperties defaults to true | 16:26 |
| *** jmlowe has joined #openstack-keystone | 16:32 | |
| *** itlinux has joined #openstack-keystone | 16:34 | |
| *** nsmeds has joined #openstack-keystone | 16:37 | |
| *** erus_ has quit IRC | 16:43 | |
| *** imacdonn has quit IRC | 16:51 | |
| aning_ | In keystonemiddleware/auth_token/__init__.py, when a request is processed, there is code to check "service token". What is "service token"? | 16:51 |
| *** imacdonn has joined #openstack-keystone | 16:51 | |
| aning_ | I know what user token is, but a bit confused by the "service token" | 16:52 |
| *** prometheanfire has left #openstack-keystone | 16:52 | |
| aning_ | And I haven't seen the service token checking code get executed in log. | 16:53 |
| *** aning_ is now known as aning | 16:53 | |
| aning | jamielennox: I saw your comments in keystonemiddleware/auth_token/__init__.py, any idea what's a service token? | 17:01 |
| *** yan0s has quit IRC | 17:03 | |
| lbragstad | a service token is a token that is used by an openstack service | 17:21 |
| lbragstad | or - a user that represents an openstack service (e.g., nova, cinder, neutron, glance, etc...) | 17:21 |
| aning | lbragstad: so this is the token presented by the service (nova for example) to keystone when it verify a client request? | 17:23 |
| lbragstad | we have a bug to add more documentation around service tokens, and how to use them https://bugs.launchpad.net/keystone/+bug/1779889 | 17:23 |
| openstack | Launchpad bug 1779889 in OpenStack Identity (keystone) "Lack of documentation for validating expired tokens with service users" [Medium,In progress] - Assigned to Irina Anyusheva (anyushevai) | 17:23 |
| *** gyee has joined #openstack-keystone | 17:24 | |
| lbragstad | aning right - for example, a service token for nova would be used for nova to get information over the API from another service | 17:24 |
| lbragstad | if nova needed an image from glance in order to boot an instance | 17:26 |
| lbragstad | it could grab that information from glance via the API, which it would need a token to do | 17:26 |
| aning | lbragstad: I'm not sure ... in this case, is nova's token becomes the user token to the other service? And would be passed as "X-Auth-Token"? | 17:26 |
| lbragstad | when that happens, we call the token that nova grabs to make that request a "service token" | 17:26 |
| lbragstad | i believe nova sends it's own token when making that request | 17:32 |
| aning | lbragstad: well, good enough for now ... will be back on this if I see issues. :) | 17:32 |
| lbragstad | you have to modify keystonemiddleware configuration if you want to use service tokens though | 17:33 |
| lbragstad | just as a heads up | 17:33 |
| lbragstad | and that's the part we need to document better | 17:33 |
| aning | lbragstad: oh, that's something new to me ... | 17:35 |
| aning | waiting for the documentation to have this info in it ... | 17:37 |
| aning | lbragstad: reading from the bug, looks like token service is seldomly used ... | 17:38 |
| lbragstad | service tokens are useful, especially for long-running operations | 17:38 |
| aning | right | 17:38 |
| lbragstad | for example, if you're taking a backup | 17:38 |
| lbragstad | or anything that takes longer than the token expiration window | 17:38 |
| aning | and during the operation, user's token expires ... | 17:39 |
| lbragstad | yeah - exaclty | 17:39 |
| lbragstad | service tokens can validate expired users tokens to get around that issue | 17:39 |
| aning | then? | 17:39 |
| aning | Eh? the expired user token still valid? | 17:40 |
| lbragstad | not directly | 17:40 |
| lbragstad | but if an operation was started with it and it expires during that operation, we handle that case by checking to see if it is still valid | 17:40 |
| lbragstad | if so - the service operation can continue | 17:40 |
| lbragstad | http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/allow-expired.html | 17:41 |
| aning | lbragstad: ok, got it. The service token is from "X-Service-Token" header, and if it presends, the middleware will use it. | 17:44 |
| lbragstad | yeah | 17:45 |
| lbragstad | i believe so - i need to dig into the implementation a bit more so we can actually document it | 17:45 |
| lbragstad | (that document is specification) | 17:45 |
| aning | In not configured, the "X-Service-Token" doesn't exist. | 17:46 |
| aning | lbragstad: all makes sense so far. | 17:46 |
| aning | lbragstad: thx | 17:46 |
| lbragstad | yep | 17:46 |
| *** jrist is now known as jrist__ | 18:16 | |
| *** jrist has joined #openstack-keystone | 18:17 | |
| *** jrist__ has quit IRC | 18:18 | |
| *** mvkr has quit IRC | 18:19 | |
| gyee | lbragstad, can you please help me understand system scope? I am trying to sort out this patch https://review.openstack.org/#/c/629692/1 | 18:20 |
| gyee | system scope is optional right? | 18:20 |
| gyee | and how do we express that in the policy rules? | 18:20 |
| gyee | I don't think we should hardcode that check | 18:21 |
| lbragstad | gyee system scope is an attempt at solving 968696 | 18:51 |
| gyee | lbragstad, but we can optionally specify that in the rules, it's a global thing right? | 18:51 |
| lbragstad | or the Bug That Shall Not Be Named | 18:52 |
| gyee | I mean we can't specify it in the rules | 18:52 |
| lbragstad | we can specify it in rules, yes | 18:52 |
| gyee | if I understand the code correctly, its basically hardcoded in the code, which dictates which scope should be used | 18:52 |
| lbragstad | yes and no | 18:52 |
| lbragstad | unfortunately | 18:52 |
| gyee | can you give me an example on how to do that in the rules? | 18:53 |
| lbragstad | sure | 18:53 |
| lbragstad | give me one minute | 18:53 |
| lbragstad | ok - so | 18:54 |
| lbragstad | most of the policies we use in keystone rely on something like rule:admin_required, right? | 18:54 |
| lbragstad | which is really just a wrapper around making sure the user has a role called 'admin' | 18:54 |
| lbragstad | right? | 18:54 |
| gyee | right | 18:55 |
| lbragstad | but - that makes us susceptible to the admin issue we've fought for so long | 18:55 |
| lbragstad | where project administrators can do whatever, when that's not the behavior we want | 18:56 |
| lbragstad | so - system scope is another authorization target | 18:56 |
| gyee | understood | 18:56 |
| lbragstad | and it's meant to protect system-level operations | 18:56 |
| lbragstad | like protecting the /v3/services endpoint | 18:56 |
| lbragstad | or /v3/endpoints | 18:57 |
| lbragstad | or /v2/hypervisors | 18:57 |
| gyee | but how do I express the scope in the rule? and I don't mean the rule registration code | 18:57 |
| gyee | in policy.json/yml | 18:57 |
| lbragstad | right - so | 18:57 |
| lbragstad | when we get a token we use it to populate an oslo.context RequestContext object | 18:57 |
| lbragstad | and we added support to oslo.context to understand system scope | 18:57 |
| lbragstad | making it a first-class attribute of context | 18:58 |
| lbragstad | in the policy check string, you can do something like `role:reader and system_scope:all` | 18:58 |
| gyee | that part I get | 18:58 |
| lbragstad | which means, this policy can only be accessed by someone who has the reader role on the system | 18:58 |
| gyee | bingo! that's what I am looking for | 18:59 |
| lbragstad | or `role:admin and system_scope:all` would be the same thing but for what we traditionally called cloud admins | 18:59 |
| lbragstad | there is a large caveat though | 18:59 |
| lbragstad | and that is the scope check is still in the check string, which isn't what we want | 18:59 |
| lbragstad | (long term) | 18:59 |
| gyee | so the allowed values are "all" or "project" | 19:00 |
| lbragstad | but, putting that scope check in the check string of each policy protects us and operators if oslo_policy enforce_scope=False | 19:00 |
| lbragstad | no - right now the only value is "all" | 19:00 |
| gyee | what does this mean? https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L928-L931 | 19:01 |
| lbragstad | eventually, when keystone defaults `keystone.conf [oslo_policy] enforce_scope = True` we can remove the system_scope:all bits from all the policy check strings because we define acceptable scope types in the actual rule definitions | 19:01 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/common/policies/service.py#L21 | 19:02 |
| *** vishakha has quit IRC | 19:02 | |
| lbragstad | enforce_scope is an option in oslo_policy that tells the enforcer if it should make sure the policies defined in the rule objects needs to match | 19:02 |
| lbragstad | (e.g., ERROR: you attempted to call an API that requires a system-scoped token with a project-scoped token) | 19:02 |
| gyee | understood | 19:03 |
| lbragstad | enforce_scope is going to be how operators upgrade to using system scope | 19:03 |
| gyee | what should we do with this patch then? https://review.openstack.org/#/c/629692/ | 19:03 |
| gyee | its basically allow project admin to access its own domain | 19:03 |
| gyee | project-scoped token to fetch its own domain | 19:03 |
| gyee | without it, some openstack CLI call will fail I think | 19:04 |
| lbragstad | that might be fine - vishakha may have thought you made that against master | 19:05 |
| lbragstad | and not a stable branch? | 19:05 |
| gyee | master has this problem too | 19:05 |
| gyee | right now project admin can't fetch its own domain | 19:05 |
| lbragstad | but we landed a fix for that | 19:06 |
| gyee | we did? | 19:06 |
| lbragstad | or we have one up for review | 19:06 |
| gyee | this one? https://review.openstack.org/#/c/605876/ | 19:06 |
| lbragstad | https://review.openstack.org/#/c/605851/ | 19:06 |
| lbragstad | https://review.openstack.org/#/c/605871/8 | 19:07 |
| gyee | that won't fix the issue | 19:07 |
| lbragstad | the two before that - yeah | 19:07 |
| lbragstad | not on stable/rocky, no | 19:07 |
| gyee | which two? | 19:09 |
| gyee | this one? https://review.openstack.org/#/c/605871/8 | 19:09 |
| gyee | ahhh, sorry | 19:09 |
| gyee | this is still wrong, 'token.project.domain.id:%(target.domain.id)s' | 19:10 |
| gyee | should be 'token.project.domain_id' | 19:10 |
| gyee | I commented on the patch | 19:12 |
| lbragstad | weird - https://review.openstack.org/#/c/605871/8/keystone/tests/unit/protection/v3/test_domains.py@133 appears to pass | 19:13 |
| lbragstad | with the current check string | 19:13 |
| lbragstad | using token.project.domain.id | 19:13 |
| gyee | really?! | 19:13 |
| lbragstad | if i'm looking at the code correctly - https://review.openstack.org/#/c/605871/8/keystone/tests/unit/protection/v3/test_domains.py@392 | 19:14 |
| lbragstad | domain setup - https://review.openstack.org/#/c/605871/8/keystone/tests/unit/protection/v3/test_domains.py@405 | 19:14 |
| gyee | but not testing GET /domain/<id> | 19:15 |
| gyee | maybe incorporating these? https://review.openstack.org/#/c/629692/1/keystone/tests/unit/test_v3_protection.py | 19:16 |
| gyee | so I can abandon my patch | 19:16 |
| lbragstad | isn't it? https://review.openstack.org/#/c/605871/8/keystone/tests/unit/protection/v3/test_domains.py@135 | 19:16 |
| lbragstad | ^ that test class is tested with project users | 19:17 |
| lbragstad | test_user_can_get_a_domain is testing GET /v3/domains/{domain_id} with a project scoped token | 19:17 |
| *** mvkr has joined #openstack-keystone | 19:21 | |
| *** tellesnobrega has joined #openstack-keystone | 19:24 | |
| gyee | lbragstad, no that only test project reader | 19:24 |
| gyee | not project admin | 19:24 |
| gyee | test succeeded with this rule '(role:reader and system_scope:all)' | 19:25 |
| gyee | if project admin implies project reader then the above rule is redundant | 19:26 |
| tellesnobrega | lbragstad, quick question regarding policies, we have a experimental API with some policy definitions, can we simply change the policy since the api is not stable yet? or do you know of some ruling that we need to follow on that ? | 19:31 |
| *** jeremyfreudberg has joined #openstack-keystone | 19:33 | |
| *** tosky has joined #openstack-keystone | 19:34 | |
| openstackgerrit | Corey Bryant proposed openstack/keystone master: PY3: switch to using unicode text values https://review.openstack.org/611190 | 19:35 |
| mnaser | how do folks feel about a patch to keystonemiddleware which includes a setting inside `keystone_authtoken` that determines the roles which are allowed to talk to that service? | 19:51 |
| mnaser | which greatly simplifies enforcing access to a specific service, without diving into wild policy files | 19:52 |
| mnaser | because there would a very large impact on the # of things changed if you want to globally allow a certain role to access a service | 19:53 |
| gyee | mnaser, how are you going to enforce *resource* access at middleware? | 20:01 |
| gyee | target.resource.id | 20:01 |
| *** tellesnobrega has left #openstack-keystone | 20:02 | |
| *** tellesnobrega has joined #openstack-keystone | 20:03 | |
| lbragstad | tellesnobrega we've done that in keystone before | 20:04 |
| lbragstad | where we have an experimental API and we've changed the policies without deprecating them, but we still include a release note saying what changed, why, and that it wasn't deprecated because it was protecting an experimental API | 20:05 |
| mnaser | gyee: well, that's a bit of another problem that can solved further down but i feel is a much bigger/fundamental problem to be resolved | 20:05 |
| lbragstad | gyee project reader won't pass 'role:reader and system_scope:all | 20:06 |
| lbragstad | 'role:reader and system_scope:all' | 20:06 |
| gyee | but user has reader role | 20:06 |
| lbragstad | but they don't have it on the system | 20:06 |
| tellesnobrega | lbragstad, sounds good | 20:07 |
| tellesnobrega | thanks | 20:07 |
| lbragstad | tellesnobrega no problem | 20:07 |
| gyee | lbragstad, is use project admin, I can't tell from the code | 20:08 |
| gyee | mnaser, not sure if I understand, you are proposing two level authorization, one at middleware and another at the service? | 20:09 |
| mnaser | gyee: yes, the middleware level one would be far simpler to implement, the service level would be much more policy based as we have today | 20:09 |
| lbragstad | gyee sorry - i'm not sure what you mean? | 20:10 |
| *** jeremyfreudberg has left #openstack-keystone | 20:10 | |
| gyee | lbragstad, https://review.openstack.org/#/c/605871/8/keystone/tests/unit/protection/v3/test_domains.py#L416 | 20:12 |
| gyee | I only see reader role on project | 20:13 |
| gyee | is that the token used to fetch the domain? | 20:13 |
| lbragstad | yeah - so the setUp there is just creating a new user and giving them the 'reader' role on a project | 20:14 |
| lbragstad | then it builds an authentication request, grabs a token, and creates a set of headers to use in tests (line 432) | 20:14 |
| gyee | but is system_scoped enforcement enabled at that point? | 20:15 |
| gyee | I thought system-scoped enforcement is disabled by default | 20:15 |
| lbragstad | at line 400 we are setting enforce_scope to True | 20:15 |
| lbragstad | in the same setUp class | 20:15 |
| *** jeremyfreudberg has joined #openstack-keystone | 20:18 | |
| lbragstad | which just checks to make sure the scope_types for the rule match the token scope in oslo.policy | 20:18 |
| jeremyfreudberg | lbragstad: clarification on your answer to tellesnobrega, are you referring to deprecation of policy names or default policy check strings? | 20:19 |
| lbragstad | jeremyfreudberg for policies protecting experimental APIs? | 20:19 |
| jeremyfreudberg | lbragstad, yeah, if we have service:foo:get_all protecting some experimental API endpoint, and we'd rather call it service:fooooooo:get_all, must there be a deprecation period? | 20:20 |
| lbragstad | jeremyfreudberg if the API is experimental, I think you have the flexibility to change those without a deprecation period - at least based on the definition of experimental that we've defined in OpenStack | 20:21 |
| lbragstad | let me see if i can dig up the link | 20:22 |
| lbragstad | https://developer.openstack.org/api-guide/quick-start/ and https://wiki.openstack.org/wiki/VersionDiscovery | 20:23 |
| lbragstad | i think mordred pointed me to a link somewhere that had a more complete definition | 20:23 |
| mordred | one sec | 20:23 |
| lbragstad | of the meaning of "experimental" as we know it with APIs | 20:23 |
| mordred | http://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog.html#consuming-catalog | 20:25 |
| mordred | http://specs.openstack.org/openstack/api-sig/guidelines/microversion_specification.html | 20:25 |
| mordred | oh - experimental | 20:25 |
| mordred | so - experimental is a bit tricky | 20:25 |
| mordred | an experimental MAJOR api version will not be returned by keystoneauth version discovery unless it is explicitly request | 20:26 |
| mordred | requested | 20:26 |
| mordred | however, there isn't such a thing for microversions - once it's out in a microversion, it's there - it could be removed in a future microversion, but since it's a microversion it would need to remain there until the end of time | 20:27 |
| lbragstad | jeremyfreudberg we also have a set of guidelines for naming policies - if you're going to be doing that https://docs.openstack.org/oslo.policy/latest/user/usage.html#naming-policies | 20:27 |
| mordred | for specific portions of an API - I don't know that there is any particularly strong mechanism we have to have an experimental api | 20:28 |
| jeremyfreudberg | lbragstad: yes, i saw the naming guide, that's part of my reasoning for wanting to rename these policies now (we previously were ignoring the guidelines about singular/plural nouns). | 20:29 |
| lbragstad | to be fair, those guidelines are relatively fresh, so there is a lot of work to do on that front | 20:30 |
| lbragstad | but yeah - following those would be a huge plus | 20:30 |
| gyee | lbragstad, what does this mean? https://github.com/openstack/keystone/blob/master/keystone/common/policies/domain.py#L58 | 20:30 |
| lbragstad | and if you're doing it for an experimental API, i don't think you'll need to deprecate them | 20:30 |
| gyee | does 'all' implies both system and project? | 20:31 |
| lbragstad | gyee nope - all just means the "entire deployment system" | 20:31 |
| lbragstad | gyee we designed the system scope stuff to be hierarchical | 20:31 |
| lbragstad | gyee because we thought it would be a good idea to try and incorporate the hierarchical attributes of the service catalog into the idea of system scope | 20:32 |
| gyee | where does the 'all' enforcement coming from? I don't see that code in oslo.policy | 20:32 |
| jeremyfreudberg | lbragstad: thanks. | 20:32 |
| lbragstad | gyee for example, i'm a system administrator and i wanted to give you the `admin` role on the `compute` service - you would only be authorized to do admin actions within nova and not the other services | 20:32 |
| gyee | https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L928-L943 | 20:32 |
| lbragstad | jeremyfreudberg no problem - hopefully that helps | 20:33 |
| lbragstad | gyee https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L928 | 20:33 |
| *** jeremyfreudberg has left #openstack-keystone | 20:33 | |
| gyee | right, but later on its checking against the scope_types | 20:34 |
| lbragstad | right | 20:34 |
| gyee | which is registered as ['system', 'project'] | 20:34 |
| gyee | https://github.com/openstack/keystone/blob/master/keystone/common/policies/domain.py#L58 | 20:34 |
| lbragstad | https://github.com/openstack/keystone/blob/master/keystone/common/policies/project.py#L74 | 20:35 |
| lbragstad | yep | 20:35 |
| gyee | this is get_domain call | 20:35 |
| gyee | so that rule would yield access granted | 20:36 |
| lbragstad | not necessarily | 20:36 |
| lbragstad | https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L939 | 20:36 |
| lbragstad | enforce_scope just ensures the API is called a token of the proper type | 20:36 |
| lbragstad | for example | 20:36 |
| lbragstad | if the identity:create_service policy is protected by `role:admin and system_scope:all` I can pass the enforce_scope check if I call the API with a system reader token | 20:37 |
| lbragstad | but I'll still fail the policy check since I don't have the admin role | 20:37 |
| gyee | man my head is spinning, but the get_domain API is registered with scope_types ['system', 'project'] | 20:38 |
| *** tellesnobrega has left #openstack-keystone | 20:38 | |
| gyee | with means both 'system' and 'project' scope are allow | 20:38 |
| gyee | allowed | 20:38 |
| lbragstad | correct | 20:39 |
| lbragstad | remember - https://review.openstack.org/#/c/605851/8 and https://review.openstack.org/#/c/605871/8 haven't landed yet | 20:39 |
| lbragstad | so - https://github.com/openstack/keystone/blob/master/keystone/common/policies/domain.py#L51 is essentially the policy check string for system-scoped tokens | 20:39 |
| lbragstad | and https://github.com/openstack/keystone/blob/master/keystone/common/policies/domain.py#L52 is for everythign else | 20:39 |
| lbragstad | and because it expects a project in that policy's check string, it's essentially hardcoded to only work for project-scoped token | 20:40 |
| gyee | lets backup a bit | 20:41 |
| lbragstad | gyee do you want to use higher bandwidth communication? | 20:42 |
| gyee | you have a mumble server? | 20:43 |
| lbragstad | nope - but i can start a google hangout or something | 20:43 |
| *** tosky has left #openstack-keystone | 20:43 | |
| *** jmlowe has quit IRC | 20:44 | |
| * lbragstad misses mumble | 20:45 | |
| gyee | lbragstad, k | 20:45 |
| lbragstad | https://hangouts.google.com/call/LG1QK_jVxJLfQaEBY3L7AEEE | 20:45 |
| lbragstad | it's open - so if anyone else wants to join in and listen/learn about scope checking, you're more than welcome | 20:46 |
| lbragstad | gyee grabbing a different mic | 20:47 |
| lbragstad | brb | 20:47 |
| *** openstackgerrit has quit IRC | 20:50 | |
| *** whoami-rajat has quit IRC | 21:01 | |
| *** jmlowe has joined #openstack-keystone | 21:07 | |
| *** aojea has joined #openstack-keystone | 21:20 | |
| gyee | lbragstad, thanks again for untangling the stuff in my head! Definitely owe you beer there. | 21:20 |
| lbragstad | gyee happy to help :) | 21:20 |
| mnaser | ok this might sound silly | 21:34 |
| mnaser | is there any policy around having a role to issue a token | 21:34 |
| lbragstad | no - there isn't | 21:34 |
| mnaser | if i create an appcred with role 'object-store', it creates it but fails to get a token | 21:34 |
| lbragstad | if you don't have a role assignment, you can ask for an unscoped token | 21:34 |
| mnaser | if i create one with role object-store + member, it can successfully get a token | 21:35 |
| mnaser | err, or in my case, _member_ | 21:35 |
| mnaser | because its a v2-era cloud | 21:35 |
| lbragstad | oh - are you using app creds? | 21:35 |
| mnaser | yeah | 21:35 |
| lbragstad | in that case, i think application credentials expect a project | 21:35 |
| lbragstad | which means it makes sense that you have some authorization on the project you supply | 21:36 |
| mnaser | so user with _member_ and object-storage roles, tries to create appcred with object-storage only, it works but fails to authenticate | 21:36 |
| mnaser | if they create one without any limits (i.e. all), it works | 21:36 |
| mnaser | if they create one with object-storage AND _member_, it also works | 21:36 |
| mnaser | ok, let me try specifying a project | 21:37 |
| lbragstad | what's the object-store role used on? | 21:37 |
| lbragstad | is it assigned to anyone? | 21:37 |
| mnaser | lbragstad: right now, nothing, its just an implied role of member_ | 21:37 |
| mnaser | hmm | 21:37 |
| mnaser | i think i see the problem now | 21:37 |
| mnaser | lol | 21:37 |
| mnaser | object-store implies _member_, we give _member_ access to project | 21:38 |
| mnaser | creating one that scopes object-store only means the app cred doesnt have access to anything at all | 21:38 |
| mnaser | because there is no object-store role assignments | 21:38 |
| mnaser | that's a little blow to my idea in that case, having 'member' with a bunch of implied roles per service, then allowing a user to create app creds to specific services | 21:40 |
| lbragstad | right | 21:42 |
| lbragstad | i *think* i understand what you mean? | 21:43 |
| mnaser | i think its time i bite the bullet and start working on some policy updates to allow a 'domain admin' | 21:44 |
| mnaser | that way, a project 'manager' can create a user and give it a specific role to a project | 21:44 |
| mnaser | s/project/domain/ | 21:44 |
| lbragstad | yeah | 21:45 |
| mnaser | ugh, but then they would be able to give 'admin' role to a user | 21:45 |
| *** pcaruana has quit IRC | 21:46 | |
| mnaser | not sure how i'd be able to stop that in policy rules | 21:46 |
| lbragstad | well - we have patches in flight that help with that https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:master+topic:implement-default-roles | 21:46 |
| mnaser | lbragstad: ou those are sweet. unfortunately, i think we're a bit far out from being able to use them.. even running up to date :p | 21:47 |
| lbragstad | some have started merging - https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:implement-default-roles | 21:48 |
| lbragstad | yeah... | 21:48 |
| lbragstad | it'll likely require a migration for operations, but we want to make it so that default roles work across system, domains, and projects in ways that people expect (without having to roll a bunch of custom policy to get it to work) | 21:49 |
| mnaser | i think the biggest blocker is the fact that identity:create_grant can't check if they're trying to create a grant for admin or not | 21:49 |
| mnaser | i.e. it would have probably been nice to check for identity:create_grant:$role_name first and fall off to identity:create_grant | 21:49 |
| mnaser | that way i could have identity:create_grant:admin as rule:admin_required | 21:50 |
| lbragstad | mnaser well - we'd likely try and encode some of those checks into keystone directly | 21:52 |
| lbragstad | so that a domain administrator can't grant someone in their domain admin on the system | 21:52 |
| lbragstad | or something like that | 21:52 |
| lbragstad | right? because that would be abd | 21:53 |
| lbragstad | bad* | 21:53 |
| mnaser | lbragstad: right, the biggest issue now is services arent aware of system and project scope i guess | 21:58 |
| mnaser | so i'm just trying to work around it :( | 21:58 |
| lbragstad | yeah - and that's a big reason why we're trying to implement all of that in keystone now - so that other projects can eventually use what we've done as a template | 21:59 |
| mnaser | lbragstad: i just feel very stuck now. i have a customer who just wants a user that can access swift only (and they're settling for not resources specific, just ~swift~) and not everything and that seems to be such a basic ask that i can't find a way to deliver | 22:00 |
| lbragstad | so - if you create an object-store role | 22:03 |
| lbragstad | you'd have to write custom policies for swift to use that role | 22:03 |
| lbragstad | but i suppose you'll also need to exercise that role's usage against other service to make sure you can't do anything there either | 22:05 |
| lbragstad | which sounds like something patrole wants to verify at some point | 22:05 |
| *** erus_ has joined #openstack-keystone | 22:20 | |
| *** erus has joined #openstack-keystone | 22:25 | |
| *** rcernin has joined #openstack-keystone | 22:38 | |
| *** aojea has quit IRC | 22:54 | |
| *** itlinux has quit IRC | 22:55 | |
| *** etp has quit IRC | 22:57 | |
| *** etp has joined #openstack-keystone | 22:59 | |
| *** gyee has quit IRC | 23:11 | |
| *** etp has quit IRC | 23:14 | |
| *** etp has joined #openstack-keystone | 23:16 | |
| *** edmondsw has quit IRC | 23:23 | |
| *** erus_ has quit IRC | 23:34 | |
| *** edmondsw has joined #openstack-keystone | 23:39 | |
| *** erus has quit IRC | 23:53 | |
| *** blake has joined #openstack-keystone | 23:58 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!