| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Update local_id limit to 255 characters https://review.opendev.org/c/openstack/keystone/+/792587 | 09:30 |
|---|---|---|
| tosky | hi, I've submitted a change to always enable the tempest key which controls the application credentials testing (and deprecate it): https://review.opendev.org/c/openstack/tempest/+/803790 | 14:35 |
| tosky | as this was added by your team, reviews are more than appreciated - do I understand it correctly that the application credentials feature can't be disabled? (Otherwise I would simply flip the value to true but not deprecate the key) | 14:36 |
| opendevreview | Grzegorz Grasza proposed openstack/keystone master: Update local_id limit to 255 characters https://review.opendev.org/c/openstack/keystone/+/792587 | 18:41 |
| admin1 | why does a domain admin have access to all the admin functions ? shouldn't the account be limited to only creating users and projects under the domain ? | 19:03 |
| admin1 | also if its the default, how to limit a domain admin to manage only users and projects under his domain and not have access to anyting else | 19:04 |
| admin1 | "https://docs.openstack.org/keystone/latest/admin/service-api-protection.html" => "Domain administrators aren’t allowed to access system-specific resources or resources outside their domain. Users that need control over project, group, and user creation are a great fit for domain administrators." | 20:52 |
| admin1 | this i found is incorrect, because as a domain admin, i can view the whole system resources and create network , flavors etc | 20:52 |
| opendevreview | Lance Bragstad proposed openstack/keystonemiddleware master: Implement X-Project-Id passthru for system users https://review.opendev.org/c/openstack/keystonemiddleware/+/787822 | 21:16 |
| *** lbragstad_ is now known as lbragstad | 21:17 | |
| lbragstad | admin1 that's the model we're working towards, but it's an effort that includes all other openstack services | 21:17 |
| lbragstad | if you want - you can configure keystone to enforce secure RBAC (where the domain admin does what you're describing) | 21:17 |
| lbragstad | keystone.conf [oslo_policy] enforce_scope and keystone.conf [oslo_policy] enforce_new_defaults are the options you'd want to take a look at | 21:20 |
| admin1 | lbragstad.. thanks .. | 21:36 |
| lbragstad | a lot of the openstack services are working to adopt those personas, so they'll hopefully become more useful as that happens | 21:36 |
| admin1 | lbragstad, so if i set true to both those variables, the default "admin" can do what he can do .. but its enforced only on the domain level ? | 21:38 |
| lbragstad | if you set those to True, keystone will use all 9 personas described in that document | 21:39 |
| lbragstad | system-admins can do what "admin" can do today | 21:39 |
| lbragstad | domain-admins can do things with projects and users within their domain | 21:39 |
| lbragstad | system-readers can view anything in the deployment (or at least within keystone) | 21:40 |
| lbragstad | domain-readers can view all resources within their domain etc... | 21:40 |
| admin1 | lbragstad, thanks | 21:43 |
| admin1 | i will enable, check and report back | 21:43 |
| lbragstad | admin1 this stuff is all WIP across openstack - so i would be careful enabling this in a deployment unless you're dealing with staging or test environments | 21:44 |
| admin1 | this is in staging | 21:44 |
| lbragstad | ok - good deal | 21:45 |
| admin1 | is there anything that is known to be broken by enabling this ? | 21:45 |
| lbragstad | if you attempt to use system-scoped tokens with other services, like nova, that will break | 21:45 |
| lbragstad | (e.g., letting system users use system-scoped tokens to do things in a project) | 21:45 |
| admin1 | my test is kind of simple ... use one domain admin to only create projects and users for that specific domain .. after that, the user logs in and does this thing as normal | 21:46 |
| lbragstad | ok - so the user is just someone with a project role assignment, right? | 21:46 |
| admin1 | yep | 21:46 |
| admin1 | normal user with a single project | 21:47 |
| admin1 | the domain admin is not supposed to do anything else ( like create vms etc ) .. only supposed to be able to create/delete/update projects and users specific to the domain | 21:47 |
| lbragstad | ok - the domain admin will behave as you would expect (enforcing tenancy) within keystone, but since that user has the admin role, they might be able to do administrative things in other services (like glance, cinder, nova) | 21:47 |
| admin1 | oh . that is the thing i want to prevent | 21:48 |
| admin1 | somehow limit a username and password to be able to create only projects and users inside a specific domain | 21:48 |
| admin1 | and have access to nothing else | 21:48 |
| admin1 | if there is another way to do this, that is also OK for me | 21:48 |
| lbragstad | right | 21:48 |
| admin1 | like create a role called abc-domain-admin and then say he can only create users and projects inside abc.com for example | 21:49 |
| lbragstad | yeah - that makes snese | 21:49 |
| lbragstad | the problem is that we're trying to update the policies across openstack so they're all consistent | 21:50 |
| admin1 | so even with the new roles, this is still not possible if i understand correctly | 21:50 |
| lbragstad | it behaves the way you want it to in keystone | 21:50 |
| lbragstad | but we need to update the other services so that it works there, too | 21:50 |
| admin1 | ok | 21:50 |
| admin1 | understood | 21:50 |
| admin1 | is there an alternate way to create a custom role and do this ? | 21:51 |
| admin1 | any good documents | 21:51 |
| lbragstad | for example, cinder will consider someone an admin so long as they have the 'admin' role on something (that could be a system, domain, or project) | 21:51 |
| admin1 | i undertood that .. the limitations | 21:51 |
| lbragstad | as far as custom policy, i'm not sure we provide anything from upstream that details how to implement domain admins | 21:52 |
| lbragstad | i would start by creating a domain-admin role and updating the keystone specific policies | 21:52 |
| admin1 | that new role is only specific to keystone work . creating project snad users that happen in keystone only .. right ? | 21:53 |
| lbragstad | right | 21:54 |
| admin1 | meaning i only need to "decipher" keystone related policies and ignore the rest | 21:54 |
| lbragstad | so - you would only use it in custom policies in keystone | 21:54 |
| admin1 | i even don't know where policies are in keystone :D | 21:54 |
| lbragstad | admin1 depending on the release you're using, you can generate them from the commandline | 21:55 |
| lbragstad | like you do with config | 21:55 |
| admin1 | victoria .. (openstack ansible 22.2.0 tag) | 21:55 |
| admin1 | https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-sample-generator.html -- this one ? | 21:56 |
| lbragstad | yeah | 21:56 |
| lbragstad | here are keystone's default policies | 21:56 |
| lbragstad | https://docs.openstack.org/keystone/latest/configuration/policy.html | 21:56 |
| admin1 | i could not find any policy file in the whole /etc/keystone directory .. so no file means everything is default ? | 21:56 |
| lbragstad | https://docs.openstack.org/keystone/latest/configuration/samples/policy-yaml.html | 21:56 |
| lbragstad | we moved the "defaults" in the policy file into code | 21:57 |
| lbragstad | so we can formally change them with deprecation tooling | 21:57 |
| lbragstad | all the defaults live here - https://github.com/openstack/keystone/tree/master/keystone/common/policies | 21:57 |
| lbragstad | oslopolicy-sample-generator --namespace keystone | 21:58 |
| lbragstad | will give you the defaults | 21:58 |
| admin1 | i get one .. everything is # | 22:00 |
| admin1 | assume i have example.com as a domain in keystone and example-admin as the admin role .. i don't know even where to start here | 22:01 |
| lbragstad | it's all commented out - yeah | 22:01 |
| lbragstad | #"identity:update_user": "(role:admin and system_scope:all) or (role:admin and token.domain.id:%(target.user.domain_id)s)" | 22:02 |
| lbragstad | would be an example policy | 22:02 |
| lbragstad | "identity:update_user": "(role:admin and system_scope:all) or (role:admin and token.domain.id:%(target.user.domain_id)s) or (role:domain_admin and token.domain.id:%(target.user.domain_id)s)" | 22:02 |
| lbragstad | would be a potential way to update it to use a custom role | 22:02 |
| lbragstad | while still honoring the upstream defauls | 22:02 |
| lbragstad | default* | 22:03 |
| admin1 | "identity:update_user": "(role:example-admin and system_scope:all) or (role:example-admin and token.domain.id:%(target.user.domain_id)s)" | 22:03 |
| admin1 | if i do that, will example-admin be able to update user .. | 22:03 |
| admin1 | but will it now remove the update_user from default admin ? | 22:03 |
| admin1 | or i need to have 2 lines , one for admin and one for example-admin | 22:04 |
| lbragstad | admin1 yeah - it would remove the ability for admins to perform update_user | 22:05 |
| lbragstad | which is why i used a logical OR in my example | 22:05 |
| lbragstad | to retain the behavior for existing admins | 22:05 |
| admin1 | got it | 22:05 |
| lbragstad | i have to run - but i hope this helps get you started | 22:06 |
| admin1 | i will try | 22:06 |
| lbragstad | good luck | 22:06 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!