| *** bjornar has quit IRC | 00:38 | |
| *** bjornar has joined #openstack-keystone | 00:42 | |
| *** nkinder__ has joined #openstack-keystone | 00:44 | |
| jamielennox | do we revoke uuid tokens (or fernet tokens) by id? | 00:51 |
|---|---|---|
| *** btully has quit IRC | 00:55 | |
| *** btully has joined #openstack-keystone | 00:57 | |
| *** btully has quit IRC | 01:01 | |
| *** liusheng has quit IRC | 01:09 | |
| *** btully has joined #openstack-keystone | 01:09 | |
| openstackgerrit | Yuiko Takada proposed openstack/keystone: Pass environment variables of proxy to tox https://review.openstack.org/191602 | 01:12 |
| *** btully has quit IRC | 01:13 | |
| *** nkinder__ has quit IRC | 01:15 | |
| *** btully has joined #openstack-keystone | 01:20 | |
| *** btully has quit IRC | 01:25 | |
| *** woodster_ has joined #openstack-keystone | 01:27 | |
| *** btully has joined #openstack-keystone | 01:33 | |
| *** btully has quit IRC | 01:38 | |
| *** btully has joined #openstack-keystone | 01:44 | |
| *** btully has quit IRC | 01:48 | |
| *** lhcheng has joined #openstack-keystone | 01:56 | |
| *** ChanServ sets mode: +v lhcheng | 01:56 | |
| *** btully has joined #openstack-keystone | 01:58 | |
| *** btully has quit IRC | 02:03 | |
| *** lhcheng has quit IRC | 02:12 | |
| *** btully has joined #openstack-keystone | 02:14 | |
| *** btully has quit IRC | 02:18 | |
| *** dimsum__ has quit IRC | 02:22 | |
| *** btully has joined #openstack-keystone | 02:27 | |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Make tests run against original client and session https://review.openstack.org/117089 | 02:28 |
| *** nkinder__ has joined #openstack-keystone | 02:29 | |
| *** btully has quit IRC | 02:32 | |
| openstackgerrit | Dave Chen proposed openstack/keystone: Needn't load fernet keys twice https://review.openstack.org/191608 | 02:32 |
| *** dimsum__ has joined #openstack-keystone | 02:36 | |
| *** btully has joined #openstack-keystone | 02:39 | |
| *** btully has quit IRC | 02:43 | |
| *** btully has joined #openstack-keystone | 02:50 | |
| *** kiran-r has joined #openstack-keystone | 02:51 | |
| *** btully has quit IRC | 02:54 | |
| *** dimsum__ has quit IRC | 02:58 | |
| *** btully has joined #openstack-keystone | 03:02 | |
| *** btully has quit IRC | 03:07 | |
| *** btully has joined #openstack-keystone | 03:15 | |
| *** tobe has joined #openstack-keystone | 03:20 | |
| *** btully has quit IRC | 03:20 | |
| *** btully has joined #openstack-keystone | 03:27 | |
| *** btully has quit IRC | 03:31 | |
| *** btully has joined #openstack-keystone | 03:38 | |
| *** btully has quit IRC | 03:42 | |
| *** kiran-r has quit IRC | 03:44 | |
| *** kiran-r has joined #openstack-keystone | 03:44 | |
| *** lhcheng has joined #openstack-keystone | 03:45 | |
| *** ChanServ sets mode: +v lhcheng | 03:45 | |
| *** btully has joined #openstack-keystone | 03:49 | |
| *** lhcheng has quit IRC | 03:53 | |
| *** btully has quit IRC | 03:54 | |
| *** dimsum__ has joined #openstack-keystone | 03:58 | |
| *** btully has joined #openstack-keystone | 04:01 | |
| *** dimsum__ has quit IRC | 04:03 | |
| *** btully has quit IRC | 04:06 | |
| openstackgerrit | Jamie Lennox proposed openstack/python-keystoneclient: Convert adapter to keystoneauth https://review.openstack.org/191627 | 04:13 |
| *** btully has joined #openstack-keystone | 04:13 | |
| *** btully has quit IRC | 04:18 | |
| *** kiran-r has quit IRC | 04:25 | |
| *** lhcheng has joined #openstack-keystone | 04:26 | |
| *** ChanServ sets mode: +v lhcheng | 04:26 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Removes temporary fix for doc generation https://review.openstack.org/191633 | 04:28 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove functional tests from tox https://review.openstack.org/191634 | 04:30 |
| *** btully has joined #openstack-keystone | 04:30 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove unused fixtures https://review.openstack.org/191635 | 04:32 |
| *** kiran-r has joined #openstack-keystone | 04:32 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Drop use of 'oslo' namespace package https://review.openstack.org/191636 | 04:33 |
| *** kiranr has joined #openstack-keystone | 04:33 | |
| *** btully has quit IRC | 04:34 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Typo in openstack client help https://review.openstack.org/191637 | 04:35 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Ensure that failing responses are logged https://review.openstack.org/191638 | 04:35 |
| *** kiran-r has quit IRC | 04:37 | |
| *** kiranr is now known as kiran-r | 04:37 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Prompt for password on CLI if not provided https://review.openstack.org/191639 | 04:41 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Support discovery on the AUTH_INTERFACE https://review.openstack.org/191641 | 04:44 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Provide a means to get all installed plugins https://review.openstack.org/191642 | 04:45 |
| *** btully has joined #openstack-keystone | 04:47 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Cleanup fixture imports https://review.openstack.org/191643 | 04:54 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Stop using function deprecated in Python 3 https://review.openstack.org/191644 | 04:57 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Use random strings for test fixtures https://review.openstack.org/191645 | 04:58 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Add get_communication_params interface to plugins https://review.openstack.org/191646 | 05:02 |
| *** davechen_afk is now known as davechen | 05:32 | |
| *** kiran-r has quit IRC | 05:39 | |
| *** bradjones has quit IRC | 05:46 | |
| *** belmoreira has joined #openstack-keystone | 05:47 | |
| *** bradjones has joined #openstack-keystone | 05:49 | |
| *** bradjones has quit IRC | 05:49 | |
| *** bradjones has joined #openstack-keystone | 05:49 | |
| *** henrynash has joined #openstack-keystone | 06:02 | |
| *** ChanServ sets mode: +v henrynash | 06:02 | |
| *** Kennan2 has joined #openstack-keystone | 06:03 | |
| *** Kennan has quit IRC | 06:04 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove _get_service_endpoints function https://review.openstack.org/191659 | 06:07 |
| openstackgerrit | Merged openstack/keystoneauth: Fetch Service Providers urls from auth plugins https://review.openstack.org/189625 | 06:09 |
| openstackgerrit | Merged openstack/keystoneauth: Properly handle Service Provider in token fixtures https://review.openstack.org/189803 | 06:09 |
| *** liusheng has joined #openstack-keystone | 06:09 | |
| *** mabrams has joined #openstack-keystone | 06:12 | |
| *** Kennan2 is now known as Kennan | 06:14 | |
| openstackgerrit | Marek Denis proposed openstack/keystoneauth: Add Keystone2KeystoneAuthPlugin for K2K federation https://review.openstack.org/188581 | 06:28 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Remove double call to normalize function https://review.openstack.org/191669 | 06:41 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Make _is_endpoint_type_match function public https://review.openstack.org/191670 | 06:41 |
| *** tobe has quit IRC | 06:44 | |
| *** kiran-r has joined #openstack-keystone | 06:54 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Make _is_endpoint_type_match function public https://review.openstack.org/191670 | 07:00 |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Make normalize_endpoint_type public https://review.openstack.org/191672 | 07:00 |
| marekd | jamielennox: Hello, still on AUS west coast? | 07:07 |
| *** tobe has joined #openstack-keystone | 07:07 | |
| jamielennox | marekd: still there | 07:08 |
| *** liusheng has quit IRC | 07:08 | |
| *** liusheng has joined #openstack-keystone | 07:09 | |
| jamielennox | marekd: with https://review.openstack.org/#/c/187516/ | 07:16 |
| jamielennox | how come we ported that to keystoneauth and not keysotneclient? | 07:16 |
| *** woodster_ has quit IRC | 07:21 | |
| *** chlong has quit IRC | 07:34 | |
| openstackgerrit | Jamie Lennox proposed openstack/keystoneauth: Split plugin loading https://review.openstack.org/190594 | 07:43 |
| marekd | jamielennox: eventaully ksc will not depend on ksa also in that matter? | 07:46 |
| jamielennox | marekd: ksc will depend on it - it's ok i just found somewhere where making that change wasn't compatible with keystoneclient unit tests | 07:46 |
| jamielennox | i just cherry-picked it over to my ksc branch as well | 07:47 |
| jamielennox | no big deal, i was just wondering if there was a reason | 07:47 |
| marekd | jamielennox: eh, we really need to double the efforts by proposing everything to ksa and ksc? | 07:48 |
| marekd | jamielennox: i am looking at https://review.openstack.org/#/c/190594/ is it going to help with k2k being more user friendly and solving all the problems we spend discussing last week regarding k2k ? | 07:48 |
| jamielennox | marekd: it depends, if you can live with it being ksa only then it shouldn't have to | 07:48 |
| jamielennox | but it was just that in this case it was a change of behaviour that i either needed to port to ksc, or provide a compatibility layer between the 2 | 07:49 |
| marekd | jamielennox: looking at the pace were features are being landed and that sometimes it takes weeks to land a relatively simple patch i think we all should be good to wait another few weeks and wait for ksa.... | 07:49 |
| jamielennox | marekd: i think it will help people conceptually more than fix the problem | 07:49 |
| jamielennox | so we are still going to have problems with loading mutliple sets of plugins | 07:50 |
| marekd | jamielennox: ok. | 07:50 |
| jamielennox | but it means we break the link that there is only one way to load each type of plugin | 07:50 |
| *** browne has quit IRC | 07:50 | |
| marekd | what is type of plugin - password vs token plugin ? | 07:50 |
| jamielennox | so if we do a 'simplek2k' and a 'complexk2k' then they can have completely different mechanisms for how they present their options to users, but underneath they can rely on the same K2K plugin that will actually do the work | 07:51 |
| jamielennox | each class | 07:51 |
| marekd | jamielennox: ack. | 07:51 |
| jamielennox | marekd: it's also something that OSC and OCC wanted to split so they could have control over the loading without modifying the plugins | 07:52 |
| marekd | ok | 07:52 |
| *** rlt has joined #openstack-keystone | 07:59 | |
| marekd | jamielennox: remind me, please. It will be OSC to provide options like --os-cloud-project-id and simply pass them as os_project_idargument to K2K.__init__(), right? | 07:59 |
| jamielennox | marekd: more or less, the plugins will tell OSC what they want and OSC will do its best to get them in the parameter names they expect | 08:00 |
| marekd | jamielennox: do we need to wait for some work you are doing now? | 08:00 |
| marekd | cause i don't see "do its best to get them [...]" step | 08:01 |
| jamielennox | marekd: that will work today, if in ksa we move it i'll make sure everything still works | 08:01 |
| *** lhcheng has quit IRC | 08:02 | |
| jamielennox | marekd: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/auth/base.py#L288 is what i mean by getting options | 08:02 |
| jamielennox | but OSC/OCC did something simimlar but not exactly the same :( | 08:02 |
| *** lhcheng has joined #openstack-keystone | 08:03 | |
| *** ChanServ sets mode: +v lhcheng | 08:03 | |
| marekd | jamielennox: what is a namespace here? | 08:04 |
| jamielennox | marekd: that's what's returned from argparse.ArgumentParser.parse_arguments() | 08:04 |
| *** lhcheng has quit IRC | 08:08 | |
| *** pnavarro has joined #openstack-keystone | 08:09 | |
| marekd | ok, i am going to finish k2k plugin as another auth plugin, and wait for some of your patches merge to we can somehow combine it with other plugins for local auth. | 08:11 |
| *** fhubik has joined #openstack-keystone | 08:17 | |
| openstackgerrit | Dave Chen proposed openstack/keystone-specs: Use oslo-versioned-objects to deal with upgrades https://review.openstack.org/167195 | 08:21 |
| *** belmoreira has quit IRC | 08:22 | |
| *** jorge_munoz has quit IRC | 08:26 | |
| *** jorge_munoz has joined #openstack-keystone | 08:28 | |
| *** fhubik is now known as fhubik_afk | 08:37 | |
| *** dguerri` is now known as dguerri | 08:37 | |
| *** dguerri has quit IRC | 08:43 | |
| *** dguerri has joined #openstack-keystone | 08:43 | |
| openstackgerrit | Marek Denis proposed openstack/keystoneauth: Keystone2KeystoneAuthPlugin scoping capabilities https://review.openstack.org/188881 | 08:47 |
| marekd | jamielennox: remember my use-case about image sharing between clouds? | 09:04 |
| marekd | jamielennox: a client would create a glance task (a job running in the background ) for pushing images into trusted clouds (glances). | 09:05 |
| *** krykowski has joined #openstack-keystone | 09:07 | |
| *** gabriel-bezerra has quit IRC | 09:23 | |
| *** ericksonsantos has quit IRC | 09:23 | |
| *** afaranha has quit IRC | 09:24 | |
| *** tellesnobrega has quit IRC | 09:24 | |
| *** samueldmq has quit IRC | 09:24 | |
| *** fhubik_afk is now known as fhubik | 09:24 | |
| marekd | jamielennox: then you stated that you'd prefer to k2k plugin at the client console would resolve all identity steps, and simply handle remote scoped token to a local glance, probably somewhere in new http header, and glance would create this task with use of the token. | 09:30 |
| *** e0ne has joined #openstack-keystone | 09:30 | |
| marekd | jamielennox: as image sharing is going to support push model with 1:N ration (one source pushing to multiple clients) i see some problem with sending scoping information in the headers/reqiests to kmw+k2k does all the job. I am wondering if you see any potential way on how to do this in the future....I'd rather prefer to avoid client to always do the scoping steps and managing all the requests all the time. | 09:33 |
| *** rushiagr_away is now known as rushiagr | 09:34 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 09:38 |
| *** afazekas has joined #openstack-keystone | 09:39 | |
| *** e0ne has quit IRC | 09:40 | |
| *** e0ne has joined #openstack-keystone | 09:47 | |
| *** lhcheng has joined #openstack-keystone | 09:52 | |
| *** ChanServ sets mode: +v lhcheng | 09:52 | |
| *** f13o has joined #openstack-keystone | 09:56 | |
| *** lhcheng has quit IRC | 09:57 | |
| *** Kennan2 has joined #openstack-keystone | 10:03 | |
| *** Kennan has quit IRC | 10:05 | |
| *** dimsum__ has joined #openstack-keystone | 10:09 | |
| *** aix has joined #openstack-keystone | 10:10 | |
| openstackgerrit | Merged openstack/keystone-specs: v3 credentials project_id is not optional for type=ec2 https://review.openstack.org/190660 | 10:14 |
| *** marzif_ has joined #openstack-keystone | 10:18 | |
| *** ncoghlan has quit IRC | 10:26 | |
| *** fhubik is now known as fhubik_afk | 10:29 | |
| *** e0ne is now known as e0ne_ | 10:32 | |
| *** fhubik_afk is now known as fhubik | 10:32 | |
| *** e0ne_ has quit IRC | 10:39 | |
| *** marzif_ has quit IRC | 10:41 | |
| *** marzif_ has joined #openstack-keystone | 10:41 | |
| *** e0ne has joined #openstack-keystone | 10:41 | |
| *** kiranr has joined #openstack-keystone | 10:43 | |
| *** kiran-r has quit IRC | 10:43 | |
| *** krykowski has quit IRC | 10:48 | |
| *** amakarov_away is now known as amakarov | 10:55 | |
| *** kiran-r has joined #openstack-keystone | 10:55 | |
| *** kiranr has quit IRC | 10:55 | |
| *** samueldmq has joined #openstack-keystone | 10:57 | |
| *** tellesnobrega has joined #openstack-keystone | 10:57 | |
| *** ericksonsantos has joined #openstack-keystone | 10:58 | |
| *** afaranha has joined #openstack-keystone | 10:58 | |
| *** krykowski has joined #openstack-keystone | 11:01 | |
| *** fhubik is now known as fhubik_afk | 11:08 | |
| *** fhubik_afk is now known as fhubik | 11:12 | |
| *** rushiagr is now known as rushiagr_away | 11:15 | |
| *** marzif_ has quit IRC | 11:24 | |
| *** tobe has quit IRC | 11:25 | |
| *** rushiagr_away is now known as rushiagr | 11:27 | |
| *** marzif_ has joined #openstack-keystone | 11:27 | |
| *** gabriel-bezerra has joined #openstack-keystone | 11:27 | |
| *** aix has quit IRC | 11:28 | |
| *** e0ne is now known as e0ne_ | 11:36 | |
| *** iurygregory has joined #openstack-keystone | 11:37 | |
| *** e0ne_ is now known as e0ne | 11:39 | |
| *** lhcheng has joined #openstack-keystone | 11:41 | |
| *** ChanServ sets mode: +v lhcheng | 11:41 | |
| *** jdennis has joined #openstack-keystone | 11:45 | |
| *** lhcheng has quit IRC | 11:45 | |
| *** fhubik is now known as fhubik_afk | 11:48 | |
| *** henrynash has quit IRC | 11:57 | |
| *** fhubik_afk is now known as fhubik | 11:58 | |
| *** lhcheng has joined #openstack-keystone | 12:05 | |
| *** ChanServ sets mode: +v lhcheng | 12:05 | |
| *** lhcheng has quit IRC | 12:09 | |
| *** bradjones has quit IRC | 12:13 | |
| *** bradjones has joined #openstack-keystone | 12:15 | |
| *** bradjones has quit IRC | 12:15 | |
| *** bradjones has joined #openstack-keystone | 12:15 | |
| *** aix has joined #openstack-keystone | 12:15 | |
| *** chlong has joined #openstack-keystone | 12:20 | |
| *** belmoreira has joined #openstack-keystone | 12:21 | |
| *** e0ne is now known as e0ne_ | 12:28 | |
| *** e0ne_ is now known as e0ne | 12:28 | |
| *** edmondsw has joined #openstack-keystone | 12:29 | |
| *** marzif_ has quit IRC | 12:33 | |
| *** raildo has joined #openstack-keystone | 12:34 | |
| *** HT_sergio has quit IRC | 12:35 | |
| *** woodster_ has joined #openstack-keystone | 12:45 | |
| *** bknudson has joined #openstack-keystone | 12:48 | |
| *** ChanServ sets mode: +v bknudson | 12:48 | |
| *** dimsum__ has quit IRC | 12:52 | |
| *** MaxV has joined #openstack-keystone | 12:52 | |
| MaxV | hello all, I have an issue when I want to setup keystone with the v3 | 12:52 |
| MaxV | I get a 401 when I use the token_endpoint | 12:53 |
| MaxV | and when I use the following curl http://docs.openstack.org/developer/keystone/api_curl_examples.html#getting-a-token-from-a-token | 12:53 |
| MaxV | I get a 404 | 12:53 |
| MaxV | With the same config I can successfuly auth on the v2 endpoint | 12:54 |
| *** f13o has quit IRC | 12:54 | |
| *** dimsum__ has joined #openstack-keystone | 12:54 | |
| *** dimsum__ is now known as dims | 12:55 | |
| *** dims has quit IRC | 12:55 | |
| *** dims has joined #openstack-keystone | 12:56 | |
| *** dtroyer has quit IRC | 13:04 | |
| *** kodoku has joined #openstack-keystone | 13:05 | |
| *** dsirrine has joined #openstack-keystone | 13:07 | |
| kodoku | Hi, Anyone know this issue ==> ERROR keystone.common.wsgi [-] (OperationalError) (2005, "Unknown MySQL server host 'vdc0009' (0)") None None But nslookup and ping for vdc0009 works :/ | 13:07 |
| kodoku | And If I restart keystone service, works | 13:07 |
| marekd | kodoku: maybe try with FQDN ? | 13:08 |
| kodoku | marekd It's with FQDN but I cut it for discretion on IRC :) | 13:09 |
| *** jaosorior has joined #openstack-keystone | 13:10 | |
| edmondsw | MaxV: can you get a token ok from scratch? and what identity backend are you using? | 13:10 |
| MaxV | edmondsw: I use mysql | 13:11 |
| MaxV | edmondsw: If I setup users with V2 I can retrieve tokens | 13:11 |
| kodoku | marekd I have this trace too ==> ERROR sqlalchemy.pool.QueuePool [-] Exception closing connection <_mysql.connection closed at 4c45c50> | 13:12 |
| edmondsw | MaxV: this working? http://docs.openstack.org/developer/keystone/api_curl_examples.html#project-scoped | 13:12 |
| MaxV | edmondsw: but in the case I want to setup keystone only with the v3 endpoints (using the admin token) | 13:12 |
| MaxV | edmondsw: I do not even have any project | 13:12 |
| marekd | kodoku: hm, some problem with OS, network? | 13:12 |
| *** radez_g0n3 is now known as radez | 13:12 | |
| edmondsw | MaxV: no projects? You'll need a project | 13:12 |
| MaxV | edmondsw: this is a setup from scratch | 13:12 |
| marekd | or sqlalchemy connections pool is overflowing | 13:13 |
| marekd | (if there is such possiblity, not sure) | 13:13 |
| MaxV | edmondsw: I start with nothing, only a token_admin | 13:13 |
| kodoku | marekd I use Rhel 7.1, Juno 2014.2.2 With Rdo package. Mariadb for backend | 13:13 |
| *** kiran-r has quit IRC | 13:13 | |
| MaxV | edmondsw: which works well with v2 | 13:13 |
| marekd | kodoku: some big loads or just test env ? | 13:13 |
| marekd | kodoku: how often does it starts dropping connections ? | 13:14 |
| kodoku | marekd hum ~200VMs with 30 users | 13:14 |
| *** rushiagr is now known as rushiagr_away | 13:14 | |
| kodoku | I have this error 10 times a day | 13:14 |
| kodoku | per day* | 13:15 |
| kodoku | without restart keystone | 13:15 |
| edmondsw | MaxV: create a project... E.g.: /usr/bin/openstack --insecure project create Default --description "My Default Tenant" --domain Default | 13:15 |
| edmondsw | MaxV: set the SERVICE_TOKEN and SERVICE_ENDPOINT env vars before running that | 13:16 |
| marekd | kodoku: "Exception closing connection" -> i'd google for this. This might look like sqlalchemy tries to close connection, something goes wrong (the questins is why) so it may not really close connection and there might somthing stay dangling in the memory/OS | 13:16 |
| kodoku | marekd full trace http://paste.openstack.org/show/294129/ | 13:17 |
| kodoku | Controlleur have 6 GB for RAM, 4GB use now. BDD have 4GB For RAM and 2 used | 13:18 |
| *** fhubik is now known as fhubik_afk | 13:22 | |
| dstanek | kodoku: are you using the correct port too? i wonder if that's just a general connectivity message | 13:22 |
| marekd | dstanek: he says after restart it works. i am wondering whether there is some race condition or something, or there is a network problem and sqlalch gets crazy.... | 13:23 |
| dstanek | network problem seems likely | 13:24 |
| kodoku | dstanek marekd yes I use default port, keystone works but I have this trace 10 time per days. And after this trace, keystone works | 13:24 |
| dstanek | maybe running a command line mysql client from the keystone server would see the same issue? | 13:24 |
| kodoku | I guess keystone restart sql connection | 13:24 |
| marekd | kodoku: or set of descriptors is being cleaner. | 13:25 |
| marekd | cleaned | 13:25 |
| marekd | kodoku: run mysql client from keystone server and try to add some load to it.... | 13:26 |
| marekd | kodoku: just like dstanek suggested. | 13:26 |
| marekd | kodoku: i'd suggest running some wireshark and sniff a little bit | 13:26 |
| marekd | maybe on both sides - keystone and db server. | 13:26 |
| MaxV | edmondsw: It only works with the v2 endpoint | 13:26 |
| marekd | dstanek: interesting is that is eventually says the mysql server cannot be found. | 13:27 |
| edmondsw | did you give the user you're trying to use a role grant on the project you created? | 13:27 |
| marekd | http://paste.openstack.org/show/294129/ | 13:27 |
| kodoku | marekd Ok I need to install mysql client on controler | 13:27 |
| dstanek | marekd: that's why i think it's a networking thin | 13:27 |
| dstanek | g | 13:27 |
| MaxV | edmondsw: there is no user at this point | 13:28 |
| marekd | dstanek: yep, i thought the same. | 13:28 |
| edmondsw | MaxV: you may need someone else to help you... no project, no users... if that's possible (even with v2) it's news to me | 13:28 |
| MaxV | a from scratch setup only use an admin_token, and it seems that this behavior is broken for the v3 endpoint | 13:29 |
| kodoku | dstanek but nodes is VM, on same ESX with HA in strong datacenter | 13:30 |
| kodoku | and sql is TCP connection | 13:30 |
| kodoku | I guess is not a network pb | 13:30 |
| dstanek | kodoku: that doesn't mean you can't have any networking issues | 13:30 |
| kodoku | dstanek With icehouse, I have not this issue | 13:31 |
| *** fhubik_afk is now known as fhubik | 13:31 | |
| kodoku | just after juno update | 13:31 |
| dstanek | kodoku: i still think you need to debug it the same way | 13:32 |
| *** edmondsw has quit IRC | 13:34 | |
| *** edmondsw has joined #openstack-keystone | 13:38 | |
| *** jdennis has quit IRC | 13:42 | |
| *** krykowski has quit IRC | 13:50 | |
| *** jdennis has joined #openstack-keystone | 13:54 | |
| lbragstad | morganfainberg: you've never ran into https://github.com/dolph/next-review/issues/21 with next-review have you? | 13:56 |
| marekd | morganfainberg: would you care +1 this? https://review.openstack.org/#/c/190619/ | 13:57 |
| lbragstad | cc: dolphm ^ | 13:58 |
| marekd | lbragstad: would you like to +A this patch: https://review.openstack.org/#/c/188302/ ? | 13:58 |
| lbragstad | marekd: sure, let me give it a review | 13:58 |
| marekd | lbragstad: no rush! | 13:58 |
| *** MaxV has quit IRC | 13:59 | |
| *** henrynash has joined #openstack-keystone | 14:04 | |
| *** ChanServ sets mode: +v henrynash | 14:04 | |
| *** stevemar has joined #openstack-keystone | 14:12 | |
| *** ChanServ sets mode: +v stevemar | 14:12 | |
| *** dsirrine has quit IRC | 14:13 | |
| *** dsirrine has joined #openstack-keystone | 14:16 | |
| *** mabrams has quit IRC | 14:21 | |
| *** openstackgerrit has quit IRC | 14:24 | |
| *** obedmr has joined #openstack-keystone | 14:24 | |
| *** openstackgerrit has joined #openstack-keystone | 14:24 | |
| *** csoukup has joined #openstack-keystone | 14:26 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:28 | |
| *** kodoku has quit IRC | 14:31 | |
| *** htruta has joined #openstack-keystone | 14:34 | |
| *** kiran-r has joined #openstack-keystone | 14:39 | |
| *** browne has joined #openstack-keystone | 14:52 | |
| *** diazjf has joined #openstack-keystone | 14:57 | |
| *** zzzeek has joined #openstack-keystone | 14:58 | |
| *** ayoung has joined #openstack-keystone | 15:00 | |
| *** ChanServ sets mode: +v ayoung | 15:00 | |
| *** dguerri is now known as dguerri` | 15:01 | |
| *** pnavarro has quit IRC | 15:04 | |
| *** dguerri` is now known as dguerri | 15:05 | |
| *** kiranr has joined #openstack-keystone | 15:09 | |
| *** kiran-r has quit IRC | 15:09 | |
| *** bdossant has joined #openstack-keystone | 15:12 | |
| *** kfox1111_ has quit IRC | 15:13 | |
| dolphm | lbragstad: specify the entire project, like openstack/keystone | 15:14 |
| *** belmoreira has quit IRC | 15:18 | |
| *** e0ne is now known as e0ne_ | 15:22 | |
| *** browne has quit IRC | 15:23 | |
| *** HT_sergio has joined #openstack-keystone | 15:26 | |
| *** e0ne_ has quit IRC | 15:32 | |
| *** e0ne has joined #openstack-keystone | 15:35 | |
| *** dsirrine has quit IRC | 15:38 | |
| *** spandhe has joined #openstack-keystone | 15:38 | |
| *** dsirrine has joined #openstack-keystone | 15:39 | |
| *** fhubik has quit IRC | 15:44 | |
| *** jaosorior has quit IRC | 15:45 | |
| *** kiranr has quit IRC | 15:46 | |
| *** kiranr has joined #openstack-keystone | 15:47 | |
| *** kfox1111 has joined #openstack-keystone | 15:49 | |
| *** nkinder__ has quit IRC | 15:50 | |
| *** kiranr is now known as kiran-r | 15:50 | |
| *** afazekas has quit IRC | 15:50 | |
| kfox1111 | Any further thoughts on https://review.openstack.org/#/c/186617 ? | 15:51 |
| kfox1111 | I'd really like to get into implementing it if the general theory is ok. | 15:51 |
| *** kiran-r has quit IRC | 15:51 | |
| *** kiran-r has joined #openstack-keystone | 15:52 | |
| bknudson | kfox1111: if this is changing the API then it needs to update the API spec: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html | 15:53 |
| *** MaxV has joined #openstack-keystone | 15:55 | |
| kfox1111 | its completely in the nova space. | 15:57 |
| kfox1111 | it just uses keystone as it exists today, similary to how heat uses it. | 15:57 |
| *** dsirrine has quit IRC | 15:57 | |
| kfox1111 | but the reviewers would like keystone to weigh in since it uses keystone. | 15:57 |
| *** dsirrine has joined #openstack-keystone | 15:58 | |
| *** thedodd has joined #openstack-keystone | 15:58 | |
| kfox1111 | it gives each vm that needs it, its own keystone user, which is kind of a new thing, though could be done maually all along. | 15:59 |
| stevemar | kfox1111, what's the benefit of that? | 15:59 |
| bknudson | that sounds like what heat is doing | 15:59 |
| bknudson | I'd like to see these things implemented with federation. | 16:00 |
| kfox1111 | stevemar: see the spec. | 16:00 |
| kfox1111 | couple of reasons. | 16:00 |
| kfox1111 | vm's need to interact with openstack services the same way users do. | 16:00 |
| *** kiran-r has quit IRC | 16:00 | |
| kfox1111 | for example, to download a secret from the barbican secret store, or to post a message to a zaqar queue. | 16:01 |
| kfox1111 | openstack services require keystone authentication, so having vm's be able to have an account means each service doesn't have to come up with a totally different authentication mechanism. | 16:01 |
| kfox1111 | bknudson: how does federation help? | 16:02 |
| *** kiran-r has joined #openstack-keystone | 16:02 | |
| kfox1111 | bknudson: heat would have its own keystone? | 16:02 |
| *** kiran-r has quit IRC | 16:02 | |
| *** kiranr has joined #openstack-keystone | 16:02 | |
| *** Guest67074 is now known as redrobot | 16:02 | |
| bknudson | heat knows what its users are and keeps track of them rather than trying to keep keystone in sync | 16:03 |
| *** kiranr is now known as kiran | 16:03 | |
| *** kiran is now known as kiran-r | 16:03 | |
| kfox1111 | bknudson: They create keystone users in a heat domain these days. | 16:04 |
| bknudson | and they destroy the users? | 16:04 |
| bknudson | how do they keep the users in sync? | 16:05 |
| kfox1111 | besides, this isn't about one service managing users for itself. | 16:05 |
| *** kiran-r has quit IRC | 16:05 | |
| kfox1111 | assume something like heat template -> nova -> instance -> barbican | 16:05 |
| *** kiran-r has joined #openstack-keystone | 16:05 | |
| kfox1111 | heat sets up the barbican acl, the instance downloads the secret. | 16:05 |
| *** kiran-r has quit IRC | 16:05 | |
| kfox1111 | they keep things in sync as part of the stack. | 16:05 |
| *** kiran-r has joined #openstack-keystone | 16:05 | |
| kfox1111 | the engine does it. | 16:05 |
| kfox1111 | each stack tends to have a minimum of one keystone user. | 16:06 |
| kfox1111 | thats kind of a digression though. Just mentioning it since there is precident for over a year of a project doing something very similar. | 16:07 |
| *** roxanaghe has joined #openstack-keystone | 16:08 | |
| bknudson | the problem is the keystone sql backend has weak security | 16:09 |
| bknudson | so I wouldn't choose to use it | 16:09 |
| kfox1111 | implementation detail. shouldn't matter to the nova spec. the deployer can choose whatever keystone backend they want. | 16:10 |
| bknudson | and while the LDAP backend can be secure, you shouldn't allow keystone to create users in it. | 16:10 |
| kfox1111 | What I'm really trying to acomplish is folks putting secrets in heat templates / nova user data. | 16:11 |
| kfox1111 | thats WAY less secure then having a keystone user/password in a database. :/ | 16:11 |
| kfox1111 | the secret gets into both the heat/nova database and even persists after the instance is deleted since its a soft delete. | 16:11 |
| bknudson | that is worse | 16:11 |
| kfox1111 | I'd like secrets to only live in barbican. | 16:12 |
| bknudson | maybe use x509 certificates instead | 16:12 |
| kfox1111 | then let the instance somehow get a credential to talk to barbican to get the secrets. | 16:12 |
| bknudson | client certs | 16:12 |
| kfox1111 | arg... | 16:12 |
| kfox1111 | how do you get a cert to the instance so it can get secrets? | 16:12 |
| kfox1111 | chicken and the egg. | 16:12 |
| kfox1111 | secret to vm so it can get a secret. :/ | 16:12 |
| bknudson | some kind of injection, through cloud-init | 16:12 |
| bknudson | can't you set up a ssh key? | 16:13 |
| kfox1111 | then it still hits the nova db in userdata, that outlasts | 16:13 |
| kfox1111 | deletes. | 16:13 |
| *** hogepodge has quit IRC | 16:13 | |
| kfox1111 | then you cant autoscale. | 16:13 |
| kfox1111 | the spec allows nova to maintain a keystone username/password and only hand out keystone tokens to the vm. | 16:13 |
| kfox1111 | no one ever knows the instance user's username/password but nova. | 16:13 |
| kfox1111 | and the vm has a way to get fresh tokens. | 16:14 |
| bknudson | how long do you need that token to be valid? | 16:14 |
| kfox1111 | a short time. the vm can always get a new one. | 16:14 |
| bknudson | because tokens expire and get invalidated on password change and such | 16:14 |
| bknudson | if the vm can get a token itself then why send a token? | 16:15 |
| kfox1111 | yup. thats ok. the usual case will be "get token, grab secrets from container" | 16:15 |
| kfox1111 | or "grab token, connect to zaqar queue" | 16:15 |
| *** kiran-r has quit IRC | 16:15 | |
| *** kiran-r has joined #openstack-keystone | 16:15 | |
| kfox1111 | because it needs to talk to barbican or zaqar. | 16:15 |
| kfox1111 | which are on different machines, provided by the cloud. | 16:16 |
| kfox1111 | how does an instance provide authentication to openstack services without a keystone token? | 16:16 |
| bknudson | you mean from inside the vm itself? | 16:17 |
| kfox1111 | yes. | 16:17 |
| bknudson | that's a good question... we haven't had to do that before? maybe not. | 16:18 |
| kfox1111 | thats what the instance user spec is all about. | 16:18 |
| kfox1111 | instances need users to be able to talk to other openstack services. | 16:18 |
| kfox1111 | This provides a mechanism to do so. | 16:18 |
| kfox1111 | amazon does something similar. | 16:18 |
| openstackgerrit | Dolph Mathews proposed openstack/keystone: Refactor: move PKI-specific tests into the appropriate class https://review.openstack.org/191873 | 16:19 |
| openstackgerrit | David Stanek proposed openstack/keystonemiddleware: Send the correct user-agent to Keystone https://review.openstack.org/180769 | 16:19 |
| bknudson | kfox1111: if we make it the same interface as amazon then we can run amazon instances in openstack | 16:19 |
| *** henrynash has quit IRC | 16:19 | |
| bknudson | any way to adapt? | 16:19 |
| dstanek | bknudson: ^ oslo_config is stupid | 16:20 |
| kfox1111 | I think they rely too much on the advanced features of the IAM they have to make them totally compatable at this point. | 16:20 |
| *** hogepodge has joined #openstack-keystone | 16:20 | |
| bknudson | maybe something for future... no problem having openstack-specific for now. | 16:20 |
| kfox1111 | I'm sure once keystone gains those features, the ec2 compatability project will pick them up. | 16:21 |
| kfox1111 | yup. | 16:21 |
| *** kiran-r has quit IRC | 16:21 | |
| kfox1111 | can you please have a look at the spec when you get a few mintues and weigh in? The nova folks would really like to know if the keystone folks think the world would break if it was accepted. | 16:23 |
| kfox1111 | I'd really appreciate it. | 16:23 |
| dims | jamielennox: were you the one telling me about a jsonhome impl? | 16:25 |
| bknudson | dims: https://github.com/jamielennox/jsonhome/tree/master/jsonhome | 16:26 |
| dims | bknudson: ah thanks | 16:27 |
| *** diazjf1 has joined #openstack-keystone | 16:29 | |
| *** diazjf has quit IRC | 16:29 | |
| *** gyee_ has joined #openstack-keystone | 16:30 | |
| *** diazjf1 has quit IRC | 16:31 | |
| *** kiran-r has joined #openstack-keystone | 16:32 | |
| *** henrynash has joined #openstack-keystone | 16:34 | |
| *** ChanServ sets mode: +v henrynash | 16:34 | |
| *** spandhe_ has joined #openstack-keystone | 16:35 | |
| *** spandhe has quit IRC | 16:37 | |
| *** spandhe_ is now known as spandhe | 16:37 | |
| lbragstad | dolphm: thanks! that seems to have been the issue | 16:37 |
| *** dsirrine has joined #openstack-keystone | 16:41 | |
| *** bdossant has quit IRC | 16:43 | |
| *** _cjones_ has joined #openstack-keystone | 16:44 | |
| *** henrynash has quit IRC | 16:50 | |
| *** browne has joined #openstack-keystone | 16:51 | |
| *** dguerri is now known as dguerri` | 16:53 | |
| openstackgerrit | Michael Tupitsyn proposed openstack/keystone: Fix debug message in flush_expired_tokens job https://review.openstack.org/191157 | 16:53 |
| *** richm has joined #openstack-keystone | 16:57 | |
| *** MaxV has quit IRC | 17:00 | |
| *** e0ne has quit IRC | 17:02 | |
| *** tqtran has joined #openstack-keystone | 17:08 | |
| *** kiran-r has quit IRC | 17:11 | |
| *** lhcheng has joined #openstack-keystone | 17:26 | |
| *** ChanServ sets mode: +v lhcheng | 17:26 | |
| *** dims has quit IRC | 17:27 | |
| *** lhcheng_ has joined #openstack-keystone | 17:27 | |
| *** dims has joined #openstack-keystone | 17:28 | |
| *** Ephur has joined #openstack-keystone | 17:29 | |
| *** lhcheng has quit IRC | 17:31 | |
| *** henrynash has joined #openstack-keystone | 17:31 | |
| *** ChanServ sets mode: +v henrynash | 17:31 | |
| *** henrynash has quit IRC | 17:37 | |
| *** RichardRaseley has joined #openstack-keystone | 17:39 | |
| notmyname | does keystone allow for setting multiple URLs for a given catalog entry? | 18:00 |
| notmyname | setting/returning | 18:00 |
| *** dsirrine has quit IRC | 18:04 | |
| *** dsirrine has joined #openstack-keystone | 18:05 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: DO NOT MERGE: Add K2K federation auth plugin https://review.openstack.org/191922 | 18:06 |
| *** aix has quit IRC | 18:09 | |
| *** stevemar2 has joined #openstack-keystone | 18:09 | |
| *** ChanServ sets mode: +v stevemar2 | 18:09 | |
| *** stevemar has quit IRC | 18:09 | |
| *** spandhe_ has joined #openstack-keystone | 18:12 | |
| *** spandhe has quit IRC | 18:12 | |
| *** spandhe_ is now known as spandhe | 18:12 | |
| gyee_ | notmyname, you mean multiple URLs per "interface"? like multiple "public" URLs? | 18:13 |
| notmyname | yeah | 18:14 |
| gyee_ | can't | 18:14 |
| notmyname | eg if I have 10 servers but no load balancer can I expose all 10 URLs for a given service catalog entry | 18:14 |
| notmyname | ok | 18:14 |
| notmyname | good to know. thanks | 18:14 |
| openstackgerrit | Merged openstack/keystone: Mapping Engine CLI https://review.openstack.org/188302 | 18:15 |
| *** dguerri` is now known as dguerri | 18:15 | |
| kfox1111 | notmyname: you could use dns for that? | 18:17 |
| kfox1111 | put all the ip addresses on the one dns name, then put the dns name in keystone. | 18:17 |
| notmyname | of course :-) | 18:18 |
| notmyname | this comes up based on some conversations around the office. just curious what's possible today | 18:18 |
| kfox1111 | ah. :) | 18:19 |
| *** dguerri is now known as dguerri` | 18:21 | |
| openstackgerrit | Rodrigo Duarte proposed openstack/keystoneauth: DO NOT MERGE: Add K2K federation auth plugin https://review.openstack.org/191922 | 18:23 |
| openstackgerrit | Dolph Mathews proposed openstack/keystone: Refactor: move PKI-specific tests into the appropriate class https://review.openstack.org/191873 | 18:24 |
| dolphm | stevemar2: managed to have a pep8 violation on https://review.openstack.org/#/c/191873/ | 18:25 |
| stevemar2 | dolphm, dolphm2 d'oh! | 18:25 |
| stevemar2 | re +2'ed | 18:25 |
| dolphm | stevemar2: danke! | 18:26 |
| stevemar2 | dolphm, while you're here - thoughts on this | 18:27 |
| stevemar2 | https://bugs.launchpad.net/python-openstackclient/+bug/1457257 | 18:27 |
| openstack | Launchpad bug 1457257 in python-openstackclient "If user's password ends with "{" and OS_TOKEN is set, client crashes" [Low,Incomplete] | 18:27 |
| ayoung | morganfainberg, so, I have a presentation on Keystone tomorrow. I'm hacking apart a bunch of my old presentations...was wondering if I could steal some of yours? | 18:27 |
| kfox1111 | ayoung: Good morning. | 18:28 |
| dolphm | stevemar2: what's the backtrace? | 18:28 |
| ayoung | kfox1111, OK...so you have to decide what you are optimizing for | 18:28 |
| stevemar2 | ayoung, morganfainberg is afk this week (or spotty attendance at best), i can hook you up with what I used for CIS? | 18:28 |
| ayoung | stevemar2, yes please | 18:28 |
| stevemar2 | dolphm, pfft, as if i wrote that bug | 18:28 |
| morganfainberg | stevemar2: feel free to share my modified version w/ ayoung as well. | 18:29 |
| stevemar2 | morganfainberg, rgr | 18:29 |
| kfox1111 | ayoung: with reguard to the instance user thing? | 18:29 |
| ayoung | kfox1111, ok...lets take it from the top: you want it so a VM can get a secret. You don't want to store the secret in the VM | 18:29 |
| ayoung | right | 18:29 |
| kfox1111 | I'm ok with the vm having the secret, since it needs it. its a matter of how to get it there. | 18:30 |
| ayoung | kfox1111, so you are talking about puitting the secret into Barbican. But you want one user to have multiple secrets, and VMs sghould be insulated from each other | 18:30 |
| morganfainberg | kfox1111: I'll comment on the spec, but fwiw identity user management Apis are not and will not be designated via Defcore. This means that feature is likely never going to be interoperable between clouds. | 18:30 |
| morganfainberg | kfox1111: expect my comments later today. /me goes back to being more AFK for a bit. | 18:30 |
| ayoung | kfox1111, not talking about the password yet, but, right | 18:30 |
| kfox1111 | morganfainberg: yeah. I understand. thanks. :) | 18:31 |
| ayoung | kfox1111, so last we talked, I told you that putting the password in Nova was a bad idea. | 18:31 |
| kfox1111 | ayoung: with you so far. | 18:31 |
| ayoung | I stand by that; | 18:31 |
| ayoung | what I would say is the "right" way to do it is this: | 18:31 |
| kfox1111 | I don't disagree, but that is an implementation detail that can be changed without changing the workflow once a better mechanism is implemented. | 18:31 |
| ayoung | if a secret resource is owned by a user, and that user wants to have different VMs have access to different secret resources, then we need two things: | 18:32 |
| ayoung | 1. the trust should be (somehow) limited in scope to the resource and | 18:32 |
| ayoung | 2. A VM gets an identity, and uses the trust to get the secret resource | 18:33 |
| *** rlt has quit IRC | 18:33 | |
| *** spandhe_ has joined #openstack-keystone | 18:33 | |
| kfox1111 | ok. lets go through it. | 18:33 |
| ayoung | now...that is probably the most invasive solution, as it requires changs in a couple places...lets lay out what we have to work with today | 18:33 |
| ayoung | we have trusts, which are expected to be scoped to a trustee, and use the project abstraction to keep resources separate | 18:34 |
| ayoung | the VMs do not have a service user yet | 18:34 |
| ayoung | VMs get their config options from Meta data fetched via cloud init. | 18:34 |
| ayoung | I would say that, today, the best option is to have separate of secrest via proejcts, and then create a trust with the service user as trustee | 18:35 |
| *** spandhe has quit IRC | 18:36 | |
| *** spandhe_ is now known as spandhe | 18:36 | |
| ayoung | and then the VM would have its own authentication and trust execution to get access to the resource stored in Barbican | 18:36 |
| ayoung | kfox1111, now...could you please attack that approach, and show where that does not support your use case? | 18:36 |
| kfox1111 | ok. | 18:37 |
| stevemar2 | ayoung, i PMed you a few links | 18:37 |
| ayoung | I really want to get to a good solution here | 18:37 |
| kfox1111 | sure. | 18:38 |
| kfox1111 | so... lets go back up a step farther because I think its important. | 18:38 |
| kfox1111 | we have non admin's that are going to be running this workflow. | 18:38 |
| kfox1111 | they themselves are not going to be allowed to create Keystone accounts in any domain. | 18:39 |
| kfox1111 | So, firstly, how do we create the instance keystone accounts? and second, how do we safely get the creds to the vm? | 18:39 |
| kfox1111 | Another issue, how does the user create the projects that you then associate the secrets to? | 18:40 |
| bknudson | should be using federation, where nova is the IdP. Need to generate SAML assertions. | 18:40 |
| kfox1111 | ... | 18:40 |
| kfox1111 | wow... um, ok. let me thing through that one for a sec... | 18:41 |
| kfox1111 | so, I guess that's just a different way for nova -> keystone authentication. It replaces storing the password in the db of the spec. Nothing else changes I think though. | 18:42 |
| ayoung | kfox1111, "they themselves are not going to be allowed to create Keystone accounts in any domain." I can't accept this as a limitation | 18:42 |
| ayoung | It is artificial, and not somethign we can design around | 18:42 |
| kfox1111 | ayoung: Sorry, but that's a policy problem your going to run into at a lot of production sites. | 18:42 |
| kfox1111 | the extra user is needless too. | 18:42 |
| ayoung | kfox1111, then the solution is intractable. Its like sayiong "we can't create any more virtual machines" | 18:43 |
| kfox1111 | I mean, that's using a sledge hammer when a regular one's sufficient. | 18:43 |
| ayoung | kfox1111, Heat already creates service users. OAUTH calls things Consumers instead of users, but they are the same thing | 18:43 |
| kfox1111 | kfox1111: exactly. I'm trying to implement service users in nova rather then heat. Why is that different? | 18:44 |
| dolphm | stevemar2: did you see my comment on https://bugs.launchpad.net/python-openstackclient/+bug/1457257 ? | 18:44 |
| openstack | Launchpad bug 1457257 in python-openstackclient "If user's password ends with "{" and OS_TOKEN is set, client crashes" [Low,Incomplete] | 18:44 |
| ayoung | kfox1111, kfox1111 a User record is not more of a slegehammer than any other record in any other database table. A user is simply a long term statement of identity | 18:45 |
| kfox1111 | ayoung: one of the problems I'm trying to deal with is allowing instance's lifespan to match the project, not match the user that launched them's employment. | 18:45 |
| kfox1111 | the project is the unit of ownership. if the user leaves the project, the vm should still work. | 18:46 |
| ayoung | If a virtual machine, or any other element of openstack needs to operate in the absence of a direct user's interaction, it needs an identity | 18:46 |
| kfox1111 | if the user creates an instance user manually, then uploads it to the vm via cloud init, the account needs to be eliminated when the user leaves. | 18:46 |
| kfox1111 | becauase they could take that username/password with them. | 18:47 |
| *** arunkant has joined #openstack-keystone | 18:47 | |
| kfox1111 | ayoung: ok. we're in full agreement there. | 18:47 |
| ayoung | kfox1111, ok, that is a general problem with delegation in Keystone today; either we do a role assignment, or we do trusts. Trusts have all the features we want, but has the limitation it is bound to a user. We could do role assignemtns, but they are pretty huge... | 18:47 |
| *** amakarov is now known as amakarov_away | 18:47 | |
| kfox1111 | with nova mantaining the user and only handing out tokens, then that issue is resolved. | 18:47 |
| kfox1111 | the user can only take a short term token with them, and it will expire before it will be of much use. | 18:47 |
| stevemar2 | dolphm, yes, i noticed that after i tested it and wrote in the defect :) | 18:47 |
| dolphm | stevemar2: how did you set OS_PASSWORD exactly? | 18:47 |
| dolphm | stevemar2: i see it now | 18:48 |
| ayoung | kfox1111, don't try to make Nova do Keystone's job | 18:48 |
| ayoung | if we need better delegation in Keystone, build it there, not in Nova | 18:48 |
| stevemar2 | dolphm, i made 2 further updates to the bug | 18:48 |
| kfox1111 | I'm not... keystone assumes a user proves their identity before giving them a token. | 18:48 |
| ayoung | because if Nova has this problem, so will Sahara, Heat, etc... | 18:48 |
| stevemar2 | dolphm, i can't get it to fail | 18:48 |
| kfox1111 | either the instance needs credentials to prove that identity to get a token from keystone, | 18:48 |
| *** obedmr has quit IRC | 18:48 | |
| kfox1111 | or the instance has to ask nova do do it on their behalf. | 18:48 |
| dolphm | stevemar2: how did you set OS_PASSWORD? | 18:49 |
| kfox1111 | instance -> nova already has an authenticated channel via the metadata server. | 18:49 |
| kfox1111 | keystone does not. | 18:49 |
| stevemar2 | dolphm, `export OS_PASSWORD=testA{` | 18:49 |
| ayoung | "either the instance needs credentials to prove that identity to get a token from keystone" is the right approach | 18:49 |
| dolphm | stevemar2: try doing it like the report says -- use quotes? | 18:49 |
| stevemar2 | dolphm, tried that just now, still works | 18:49 |
| dolphm | then mark as incomplete? | 18:49 |
| stevemar2 | export OS_PASSWORD="testA{" | 18:50 |
| stevemar2 | dolphm, already did! | 18:50 |
| dolphm | stevemar2: i don't know why anything would be doing string formatting on the password anyway :-/ | 18:50 |
| ayoung | "the instance has to ask nova do do it on their behalf." puts Nova into the midst of workflows where it has no interest nor reason to interfere | 18:50 |
| kfox1111 | your speaking for the nova team, and they are actually ok with it. | 18:50 |
| stevemar2 | dolphm, just wanted your thoughts on it :P it's low priority | 18:50 |
| bknudson | just wanted to mention, since people are around -- DB2 CI discussion today at 8 PM central time. | 18:50 |
| ayoung | kfox1111, so...lets assume that we go with trusts...and then the user that set all this up gets kicked off the project. | 18:50 |
| *** jdennis has quit IRC | 18:50 | |
| ayoung | At that point, here is what would need to be updated: | 18:50 |
| kfox1111 | Won't fly, but ok lets keep going. | 18:50 |
| stevemar2 | bknudson, give me a poke on ST/IRC if i'm not replying | 18:50 |
| bknudson | http://lists.openstack.org/pipermail/openstack-dev/2015-June/066901.html | 18:51 |
| ayoung | a new user would have to create another trust, mirroring the first | 18:51 |
| *** stevemar2 is now known as stevemar | 18:51 | |
| *** obedmr has joined #openstack-keystone | 18:51 | |
| ayoung | that user would have to provide the trust ID to the VM | 18:51 |
| *** obedmr has quit IRC | 18:51 | |
| ayoung | and then the VM would use that new trust ID when getting tokens | 18:51 |
| bknudson | stevemar: ST? is that like slack? | 18:51 |
| *** e0ne has joined #openstack-keystone | 18:51 | |
| stevemar | bknudson, sort of, but crappier | 18:51 |
| ayoung | kfox1111, so..what you want is to automate that process...so long as someone in the project says "this should go on...then this should go on." | 18:51 |
| kfox1111 | the trust is broken as soon as the user leaves the project, no? | 18:52 |
| ayoung | kfox1111, "broken" is not the right word, but yes | 18:52 |
| ayoung | the trust is no longer executable | 18:52 |
| kfox1111 | so that breaks the vm's ability to talk to barbican and refresh its keys. | 18:53 |
| ayoung | kfox1111, so, what you want is a form of delegation not tied to a single user. And to answer that, we need to look at how we do role assignments | 18:53 |
| kfox1111 | ok. I don't disagree on that part. | 18:53 |
| *** obedmr has joined #openstack-keystone | 18:53 | |
| ayoung | we could always grant the Service user a full role on the project. The only problem with that is that most users do not have that power | 18:53 |
| bknudson | you can pass the SAML to the VM, then the VM can use that SAML to get a keystone token. | 18:53 |
| bknudson | as long as you set up your mapping in keystone properly you'll get a token with the roles you need | 18:54 |
| ayoung | role assignment is, by definition, a limited power, as right now a user that can assign something anything anything | 18:54 |
| kfox1111 | bknudson: How do you know what to delegate in the first place in the workflow? | 18:54 |
| ayoung | I wopuld argue that role assignments are, as implemented today, broken | 18:54 |
| kfox1111 | ayoung: I would totally agree with that. :) | 18:54 |
| ayoung | bknudson, the mechanism is irrelevant | 18:55 |
| ayoung | SAML is not a solution | 18:55 |
| ayoung | SAML needs someone to request the assertion, and assertions are not good forever | 18:55 |
| *** jdennis has joined #openstack-keystone | 18:55 | |
| kfox1111 | bknudson: I agree SAML might be able to replace putting a passowrd in a db in the spec I proposed. No pw needed in that case. | 18:55 |
| bknudson | an IdP can't just generate assertions? | 18:56 |
| ayoung | kfox1111, wrong. You still need a password to get the SAML assertion. Let's focus, please. | 18:56 |
| kfox1111 | I think the permissions that are delegated to the user stil has to go through keystone though. | 18:56 |
| kfox1111 | ok. | 18:56 |
| bknudson | seems like an IdP needs to be able to generate any assertion it feels like. | 18:56 |
| *** jdennis has joined #openstack-keystone | 18:56 | |
| ayoung | kfox1111, so, until we fix delegation, the trust approach is your best and only secure bet | 18:56 |
| kfox1111 | ayoung: I htink your forgetting about project acl's. | 18:57 |
| ayoung | kfox1111, and to fix delegation requires the whole damn thing I am trying to get done with dynamic policy | 18:57 |
| kfox1111 | such as https://review.openstack.org/#/c/190404/ | 18:57 |
| kfox1111 | ayoung: Which, I am totally for as well. :) | 18:57 |
| ayoung | kfox1111, ACLs are per suer, no? | 18:57 |
| ayoung | user | 18:57 |
| kfox1111 | yes sort of. | 18:57 |
| kfox1111 | the instance user gets the acl put on them. | 18:57 |
| ayoung | kfox1111, then they are even worse | 18:58 |
| kfox1111 | so it works out ok. | 18:58 |
| *** geoffarnold has joined #openstack-keystone | 18:58 | |
| ayoung | kfox1111, so if the user gets kicked out of the project, no one can get the secret... | 18:58 |
| ayoung | or... | 18:58 |
| ayoung | you add to the ACLs the service users | 18:58 |
| ayoung | and it works without a trust | 18:58 |
| kfox1111 | so you just tag on the instance user's access on to the secrets you want to allow. easy to do in heat. | 18:58 |
| kfox1111 | yeah. | 18:58 |
| ayoung | either way...there is no reason to put the password in to Nova | 18:58 |
| *** Rockyg has joined #openstack-keystone | 18:59 | |
| kfox1111 | ayoung: we differ on that part, but we've decided to put that aside for now. | 18:59 |
| ayoung | " add to the ACLs the service users" really should read "add the service users to the ACLs" | 18:59 |
| kfox1111 | so for the barbican acl case, you don't need a trust. | 18:59 |
| ayoung | nope...you just need to be able to get a token. | 18:59 |
| kfox1111 | ok. my english isnot always the best. :) | 18:59 |
| *** jdennis has quit IRC | 18:59 | |
| ayoung | And be in the ACL | 18:59 |
| kfox1111 | yes. | 18:59 |
| kfox1111 | and discover the barbican endpoint. :) | 18:59 |
| kfox1111 | which is the unscoped token spec thing. :) | 19:00 |
| ayoung | I don't know if Barbican even requires a scoped token. If it does, then, you probably do need a trust, or you need to let the Nova user do a role assignment | 19:00 |
| ayoung | which is...bad | 19:00 |
| kfox1111 | it doesn't require a scoped token. | 19:00 |
| ayoung | Great...now we have people using unscoped tokens outside of Keystone. | 19:00 |
| * ayoung mutters in his beard | 19:00 | |
| kfox1111 | yeah. cause you want the vm to be able to become whichever project/role/trust it wants after getting the unscoped token. | 19:01 |
| kfox1111 | ayoung: yeah. :/ | 19:01 |
| kfox1111 | I'd really like to see a whole nother scoping of tokens long term. | 19:01 |
| kfox1111 | kerberos has service tickets. | 19:01 |
| kfox1111 | totally different from project scoping. | 19:01 |
| ayoung | kfox1111, that is different. There you are talking endpoint binding of tokens | 19:01 |
| ayoung | and that is enroute | 19:01 |
| ayoung | but an unscoped token has no catalog | 19:01 |
| kfox1111 | unscoped is similart to the kerberos ticket granting ticket. | 19:01 |
| ayoung | yep | 19:02 |
| kfox1111 | there is no equiv of "give me a token that I can use only to talk to barbican and no other openstack services" | 19:02 |
| kfox1111 | aka, service ticket. | 19:02 |
| ayoung | kfox1111, but Kerberos does not have local authorization, per application. Kerberos is for authentication, and keystone is for authorization...there is a difference. | 19:02 |
| kfox1111 | if one service is comprimized, the tokens can be sniffed and used on any other service. | 19:02 |
| ayoung | We just abuse Keystone tokens...and now I am all depressed again | 19:03 |
| ayoung | kfox1111, and I am trying to solve that | 19:03 |
| ayoung | but first we need to educate people..and that is the pain | 19:03 |
| kfox1111 | yeah. I know. I'm all for the work your doing. :) | 19:03 |
| kfox1111 | know you know where I'm coming from though. :) | 19:03 |
| *** jdennis has joined #openstack-keystone | 19:03 | |
| ayoung | kfox1111, http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ | 19:03 |
| kfox1111 | I'm trying to make this as secure/safe as possible, and I'm talking to a bunch of people that don't quite understan the use case. :/ | 19:04 |
| kfox1111 | Each are saying its the other projects responsability to solve. :/ | 19:04 |
| ayoung | kfox1111, I am saying it is Keystone's responsibility to solve. In doing so, I've been accused of a power grab | 19:04 |
| kfox1111 | Yup. I've read that blog post a few times. :) | 19:04 |
| ayoung | kfox1111, OK, so user trusts until you can't | 19:05 |
| ayoung | there really is no better option | 19:05 |
| ayoung | and, if you want to extend the trust mechanism, submit a blueprint for that | 19:05 |
| ayoung | I'd be all for it | 19:05 |
| kfox1111 | I thought we just decided we didn't need a trust when acl's are in play? | 19:05 |
| ayoung | something like : group trusts. | 19:05 |
| ayoung | kfox1111, you decided that...I was just walking through it. | 19:05 |
| kfox1111 | ok. | 19:05 |
| kfox1111 | think it over for a minute and let me know what you think of it. | 19:06 |
| ayoung | kfox1111, to be hones, for what you wnat with ACLs, you don't need or want tokens, you want something like | 19:06 |
| ayoung | use X509 to talk to Barbican,. barbican maps that to the Keystone user, and performs its own ACL check | 19:06 |
| ayoung | along the idea of http://adam.younglogic.com/2014/10/who-can-sign-for-what/ but replace the PKI tokens with straight X509...or kerberos | 19:07 |
| kfox1111 | feels like I've been around and around this one for a while. :/ | 19:08 |
| kfox1111 | now you need to implement an x509 fetching mechanism into all openstack projects that will support acl's. :? | 19:08 |
| kfox1111 | shouldn't that just be solved with keystone service tokens? | 19:09 |
| kfox1111 | btw, I tried suggesting something similar here: | 19:09 |
| ayoung | kfox1111, as I said at first, use Trusts | 19:09 |
| kfox1111 | https://review.openstack.org/#/c/159571/ | 19:10 |
| *** lhcheng_ is now known as lhcheng | 19:10 | |
| *** ChanServ sets mode: +v lhcheng | 19:10 | |
| ayoung | if you are going to go off into the weeds, I assure you I can always find deeper weeds | 19:10 |
| ayoung | kfox1111, so, gyee_ is working on X509 tokenless auth for Keystione...that is a future thing. Don't build on it yet | 19:10 |
| kfox1111 | a signed message between nova -> barbican to pass securitygroup/metadata. The barbican folks much prefered the nova instance user concept since it would work for other services besides just barbican. | 19:11 |
| ayoung | For you use, the trusts provide a way a user can provide a role assignemnt for a workflow. There is no other limited way to do that | 19:11 |
| stevemar | jamielennox, btw - new OSC release | 19:11 |
| stevemar | might want to try your v3 only devstack | 19:11 |
| kfox1111 | I'm ok with the user using user trusts, or project trusts (if that becomes a thing) or just plain acl's. | 19:12 |
| kfox1111 | I think we're in agreement that the instances need keystone users, just in disagreement at this point how they obtain them. | 19:12 |
| kfox1111 | either way they get them from the nova metadata server. | 19:12 |
| kfox1111 | the main difference is with my proposal, the user is managed by nova, the instance user is not put into heat's db or the nove instance's perminant log, and the user never gains direct access to the ability to fetch fresh tokens for it. | 19:14 |
| ayoung | kfox1111, from a security perspective, I can see how to do user creation without role assignments in a secure way. Trusts allow for delegation. I don't yet have a mechnism in Keystone for secure role assignments. THus, I can't recommend that. You suggest using unscoped tokens, but those are like TGS, and, as they are also bearer tokejns, with complete access to all that the user can do, very insecure to pass around | 19:14 |
| kfox1111 | those seem like a security enhancement to me without requiring much of nova. | 19:14 |
| ayoung | correct, all this work is Keystone work | 19:14 |
| ayoung | kfox1111, why is it any better to put a "user" in Nova than to put it in Keystone? | 19:15 |
| kfox1111 | agreed. I'm thinkging, for now, we pass the unscoped token to barbican. its not any less secure then it works today. in the future, once a more secure mechanism is put in place, we can switch to that. | 19:15 |
| ayoung | No...Use a trust. PLease please please hear what I am saying | 19:15 |
| ayoung | unscoped is not for you to use | 19:15 |
| kfox1111 | because, like I said before, nova and the instance have a trust relationship. | 19:16 |
| kfox1111 | when the instance talks to nova, nova knows for sure it is the instance talking to it. | 19:16 |
| ayoung | No t really. That is just a lie that we don't want to look too closely at. | 19:16 |
| kfox1111 | how do you extend that trust relationship with keystone such that keystone knows the instance that is talking to it so it can hand back a token? | 19:16 |
| ayoung | Meta data is scary | 19:16 |
| *** samuel-dmq has joined #openstack-keystone | 19:16 | |
| ayoung | kfox1111, ok...let me seee if I can give you what you want... | 19:17 |
| kfox1111 | ayoung: cant have it both ways. you said you should put the instance user pw in the metadata. | 19:17 |
| kfox1111 | so it has to be safe enough for your workflow too. | 19:17 |
| ayoung | you are saying that if I create a VM, I should have an implicit trust, as the VM should be able to get a token to work on the users behalf at any time. | 19:17 |
| kfox1111 | a little less then that. | 19:18 |
| kfox1111 | the instance needs a way to get a token. | 19:18 |
| ayoung | You can pass the password that way, but I would also have the VM autogenerate a new one and change the apssword right away | 19:18 |
| kfox1111 | the launching user needs some handle to associate trusts with it, or acls, or whatever else they want to do. | 19:18 |
| kfox1111 | but all they need for that is the instance user's uuid. | 19:18 |
| *** dguerri` is now known as dguerri | 19:19 | |
| kfox1111 | ayoung: even more secure woudl be to only pass keystone tokens through. that way they expire automatically. :) | 19:19 |
| *** nkinder__ has joined #openstack-keystone | 19:20 | |
| kfox1111 | which was why I was thinking we extend the metadata server to hand them back. the vm can't ever get a token that can't expire then. | 19:21 |
| kfox1111 | nor can a user that can login to the vm. | 19:21 |
| kfox1111 | that does require nova to know how to fetch a token, but that's a relatively minor thing. | 19:21 |
| raildo | hey guys, in case you haven't seen in the ML, I sent an email with the etherpad describing the options of getting a project scoped token after reseller: https://etherpad.openstack.org/p/reseller-project-token In case you have any questions, we have until keystone meeting tomorrow to discuss, improve and maybe add alternatives :) | 19:22 |
| ayoung | kfox1111, leave meta data out of it after the initial launch. it can't make things more secure, only less so. | 19:22 |
| kfox1111 | how do? I just layed out exactly how it could make it more secure. How can it make it less so? | 19:23 |
| *** samuel-dmq has quit IRC | 19:23 | |
| ayoung | kfox1111, I need to move on. the only secure way to do this today is with trusts. If those don't meet your needs, then propose a way to make them meet your needs | 19:23 |
| kfox1111 | truely curious here. I totally could have missed something. | 19:23 |
| ayoung | kfox1111, there are multiple Nova servers. You can't treat one as more trusted than the others. | 19:24 |
| dstanek | raildo: can you explain what benefit we lose with #5? | 19:24 |
| kfox1111 | no, they are treated equally by this. | 19:24 |
| ayoung | If Nova can request tokens for all vms they are managing, they become another place where a compromise is catastrophic | 19:25 |
| ayoung | Nova is not a password vault | 19:25 |
| kfox1111 | true. but putting a keystone secret in the nova db as done today is not any more safe. | 19:25 |
| ayoung | The nova user should not be ab le to get tokens for another use | 19:25 |
| ayoung | kfox1111, heh, agreed | 19:25 |
| kfox1111 | at the end of the day, if you are going to be supporting autoscaling, | 19:26 |
| kfox1111 | nova's going to be able to get at the keys. | 19:26 |
| kfox1111 | I see no other way. :/ | 19:26 |
| kfox1111 | I'm trying to come up with the most secure system that will still work under autoscaling. | 19:26 |
| kfox1111 | its up to the user to deside if that's good enough, or to support manual scaling and be safer yet. | 19:26 |
| ayoung | kfox1111, it is a delegation problem. Please think of it in those terms, do not build a nova specific solution, and think instead what additional support you need from Keystone. | 19:27 |
| ayoung | And with that..I have to sign off..I have a presentation tomorrow, and can;t postpone working on it any longer | 19:27 |
| *** ayoung is now known as ayoung-nopthere | 19:27 | |
| kfox1111 | chicken and the egg, your still avoiding. | 19:27 |
| *** ayoung-nopthere is now known as ayoung-nowhere | 19:27 | |
| kfox1111 | how do yo uget the initial secret into the vm so it can get secrets? | 19:27 |
| *** ayoung-nowhere is now known as ayoung | 19:27 | |
| kfox1111 | how do you get a keystone secret to keystone so that you can talk to keystone? | 19:27 |
| kfox1111 | same problem. :/ | 19:27 |
| *** ayoung has quit IRC | 19:28 | |
| raildo | dstanek, sure. imo, The other services doesn't know about domain, if we provide a project scoped token to a project with is_domain, will be easier to the other services handle with it. For example, Horizon works with domains without need about domain scoped token. | 19:28 |
| kfox1111 | how do you get a keystone secret to a vm so that you can talk to keystone? | 19:28 |
| * kfox1111 sighs | 19:28 | |
| kfox1111 | no one wants to answer that one. :/ | 19:28 |
| *** jaosorior has joined #openstack-keystone | 19:29 | |
| dstanek | raildo: to use v3 won't things have to know about domains to some extent? | 19:29 |
| raildo | dstanek, another benefit is that, if we are going to work with domain as a feature of projects, I think that make sense to provide a project, that is is_domain=True/False. | 19:30 |
| raildo | dstanek, yes, there is, but not about domain scoped token. | 19:30 |
| *** samuel-dmq has joined #openstack-keystone | 19:30 | |
| kfox1111 | bknudson: I think your right btw. | 19:31 |
| kfox1111 | with your suggestion, rather then putting the instance user/pw in the db, it should just be able to issue a assertion on behalf of the instance user, get a token, | 19:32 |
| kfox1111 | and hand it back to the instance. | 19:32 |
| *** ayoung has joined #openstack-keystone | 19:32 | |
| *** ChanServ sets mode: +v ayoung | 19:32 | |
| dstanek | raildo: i think since we made the decision that v3 clients should have some knowledge about domains we don't need to back peddle | 19:32 |
| ayoung | kfox1111, OK...one last answer, and then I really am done: | 19:32 |
| * morganfainberg wakes up for a few minutes | 19:32 | |
| bknudson | kfox1111: hey! right for once! | 19:32 |
| kfox1111 | I'm going to put that as an alternate in the spec. | 19:32 |
| ayoung | 1. Nova workflow kicks off the new user create | 19:32 |
| dstanek | raildo: i think domain scoped tokens are Project<is_domain=True> and project scoped tokens are Project<is_domain=False> | 19:32 |
| morganfainberg | kfox1111: yes. issuing an assertion is the right direction imo | 19:32 |
| ayoung | 2. Nova generate password for the new VM, and passes it via Meta\data to the new VM | 19:32 |
| ayoung | New VM immediately changes the password | 19:33 |
| bknudson | I wonder if heat can use the same technique | 19:33 |
| kfox1111 | bknudson: I bet it could. :) | 19:33 |
| morganfainberg | kfox1111: don't try and create a keystone user directly, this is not going to be interoperable and imo means a -1 always. | 19:33 |
| kfox1111 | morganfainberg: so being a identity provider is a hard requirement? | 19:33 |
| morganfainberg | kfox1111: pretty much we need to have a way to construct an assertion of some sort. | 19:34 |
| kfox1111 | I'm ok with that if it is. I'll ammend the spec. | 19:34 |
| morganfainberg | doesn't need to be a full IdP | 19:34 |
| morganfainberg | just don't assume you can manage users | 19:34 |
| morganfainberg | we have technology that lets us map bundles of attributes to ephemeral users in a grou | 19:34 |
| morganfainberg | group* | 19:34 |
| kfox1111 | ayoung: I don't see much advantage in that over just having heat manage the user creation. | 19:34 |
| raildo | dstanek, I see your point, but I'm little concern if this will be odd to the users... How we can explain that the user can get a project scoped token to a project, and can't for another? | 19:35 |
| morganfainberg | if we can use this technology - it means you wont need to worry if user creation is supported/allowed | 19:35 |
| raildo | dstanek, if I have project that I can handle with it as a domain in Keystone and as a "normal" project in the other service. I think that is most useful that create a domain just because I'm obligated to be the container of users, and create a project inside this domain to use in other services. Make sense? | 19:35 |
| morganfainberg | then if heat did the same thing, -- woot, this makes life better because we can move away from needing to be an idp. | 19:35 |
| dstanek | raildo: because the other is a domain, it's not a project | 19:35 |
| ayoung | morganfainberg, so, in that case, who would be the SAML provider? | 19:35 |
| kfox1111 | morganfainberg: Ok. I'll revise the spec and modify. | 19:35 |
| kfox1111 | morganfainberg: It would be nice if you commented on the spec so we don't loose this conversation, but I'll ammend the spec anyway if you don't have time. | 19:36 |
| morganfainberg | ayoung: this might be a case where we do the same thing we do for k2k - or make an API that the nova service user is allowed to request an ephemeral user assertion with specific params | 19:36 |
| kfox1111 | ayoung: Nova I think. | 19:36 |
| dstanek | raildo: in my mind this is really just like a filesystem where directories(domains) hold files(projects) | 19:36 |
| ayoung | morganfainberg, K2k is based on auser in Keystone...or coming from outside. We always need some baseis for authentication | 19:36 |
| ayoung | Nova as a SAML provider... | 19:36 |
| morganfainberg | ayoung: this is a case where we are allowing the nova service user to create a very specific-cased user | 19:36 |
| ayoung | interesting | 19:36 |
| kfox1111 | nova has a keystone user already. :) | 19:37 |
| *** dguerri is now known as dguerri` | 19:37 | |
| kfox1111 | I do like the idea. | 19:37 |
| morganfainberg | ayoung: how that assertion is created is less of a concern to me at the moment - we can dig into that implementation detail once we decide we don't need a user-per-vm in keystone's identity store | 19:37 |
| ayoung | If Keystone could do a Nova server list.....it could provide the assertion | 19:37 |
| ayoung | hmmmm | 19:37 |
| morganfainberg | ayoung: yes, you're seeing the general thought i have. | 19:37 |
| *** dguerri` is now known as dguerri | 19:38 | |
| kfox1111 | ... I am starting to not understand again. | 19:38 |
| ayoung | morganfainberg, so...do we make this nova sepcific or more general purpose " here is the callback hooK" type thing | 19:38 |
| kfox1111 | why would keystone need to do a nova server list? | 19:38 |
| morganfainberg | kfox1111: implementation detail | 19:38 |
| raildo | dstanek, I see like you but to me is something like: directories(project) hold files(vms, images...) and we do a upgrade on this directory to to hold users(is_domain=True) | 19:38 |
| morganfainberg | ayoung: callback hook | 19:38 |
| kfox1111 | shouldn't it trust the assertion coming from nova? Nova's the one asserting? | 19:38 |
| ayoung | morganfainberg, OK, I'm sold | 19:38 |
| morganfainberg | kfox1111: we're saying nova can request an ephemeral user assertion from keystone | 19:39 |
| morganfainberg | kfox1111: not nova directly issuing an assertion | 19:39 |
| morganfainberg | i dont trust nova to be a source of identity, i trust keystone to be. | 19:39 |
| morganfainberg | i don't want nova to need to understand semantics of revocations etc. | 19:39 |
| kfox1111 | so... nova -> keystone "Give me a token for ephemeral user 12345" and it gets one back. | 19:39 |
| ayoung | morganfainberg, so thie really means we should be able to hang an assertion off any resource in OpenStack....so long as the trusted service user says "uyes, I amamanaging that." | 19:39 |
| dstanek | raildo: that changes to current concept though. imo makes it more complicated | 19:40 |
| morganfainberg | ayoung: service and service is allowed to do so | 19:40 |
| ayoung | morganfainberg, scoping sucks today | 19:40 |
| morganfainberg | kfox1111: basically instead of a user create: we have keystone issue a special-case assertion (not nessicarily saml, but an assertion) | 19:40 |
| morganfainberg | kfox1111: then the VM can use that assertion for <lifespan> to get the special-case token. since we still talk tokens everywhere else (can't be helped yet) | 19:41 |
| dstanek | raildo: i think it is clearer to keep the domain -> project concept and layer in the nesting of domains | 19:41 |
| morganfainberg | but if we fix the bearer token thing, that assertion can be more directly used. | 19:41 |
| kfox1111 | so, something a little more concrete to help my brain.... | 19:41 |
| morganfainberg | kfox1111: nova create vm, needs access to <barbican> | 19:41 |
| morganfainberg | from vm | 19:41 |
| kfox1111 | nova -> keystone "give me a x509 for instance user 12345" | 19:41 |
| morganfainberg | basically. | 19:42 |
| kfox1111 | nova hands the cert to the instance. | 19:42 |
| kfox1111 | the instance can present the cert and get new tokens? | 19:42 |
| morganfainberg | or whatever the form is for the "assertion" | 19:42 |
| kfox1111 | right. | 19:42 |
| morganfainberg | very limited scope of what those tokens can do | 19:42 |
| morganfainberg | uses the ephemeral user mapping engine | 19:42 |
| morganfainberg | so we don't need to create a heavy-weight user for each vm | 19:42 |
| ayoung | morganfainberg, there is something not right there | 19:42 |
| kfox1111 | I like the idea, but still prefer that the cert stay in nova's db rather then all the way to the vm. | 19:42 |
| *** Rockyg has quit IRC | 19:42 | |
| morganfainberg | kfox1111: the cert can go in the DB. | 19:43 |
| kfox1111 | that way it can be revoked and updated and the vm wouldn't know. | 19:43 |
| morganfainberg | kfox1111: doesn't matter how you do that. | 19:43 |
| kfox1111 | ok. | 19:43 |
| *** Rockyg has joined #openstack-keystone | 19:43 | |
| morganfainberg | kfox1111: that is nova's domain to manage. | 19:43 |
| kfox1111 | ok. cool. | 19:43 |
| ayoung | morganfainberg, once the token is used somewhere else, there is no tying it back to the origianl users. The fact that the resource is associated with the user....well, it isn;'t | 19:43 |
| morganfainberg | ayoung: i am sure there is more to consider | 19:43 |
| kfox1111 | I think I can see how it all comes together. | 19:43 |
| *** HT_sergio has quit IRC | 19:43 | |
| raildo | dstanek, I agree that your suggestion may be simpler, but I think that will be more complicated change this in a future, than now. | 19:43 |
| ayoung | it is associate with the project, but...that is OK | 19:43 |
| ayoung | hmmm | 19:43 |
| ayoung | morganfainberg, it still need dynamic policy | 19:44 |
| morganfainberg | ayoung: and these tokens would need to be explicit no-rescope. | 19:44 |
| ayoung | heh that goes without saying | 19:44 |
| kfox1111 | wait a second... | 19:44 |
| kfox1111 | one case I was considering... | 19:44 |
| raildo | dstanek, It's complicated, that why we have a lot of options :P | 19:44 |
| morganfainberg | ayoung: ok anyway, that is a better direction (imo) if we need services to manage users than "create a real user" | 19:44 |
| kfox1111 | heat creates instance. heat gets instance user uiid from instance, | 19:44 |
| ayoung | kfox1111, I'm not agreeing to this yet. I was seduced for a moment only | 19:44 |
| kfox1111 | heat associates whatever acl's it wonats th user uuid, | 19:45 |
| ayoung | morganfainberg, we treat the services as idenitty sources | 19:45 |
| kfox1111 | heat runs shell script on vm to do something. | 19:45 |
| *** afazekas has joined #openstack-keystone | 19:45 | |
| morganfainberg | ayoung, kfox1111: I'm also not 100% sold on this. but I'm looking at how we can get out of managing users. | 19:45 |
| morganfainberg | completly | 19:45 |
| kfox1111 | the nice thing about that work flow, is the user can at any time associate further trusts or projects or whatever with the instance user at any time. | 19:45 |
| morganfainberg | with x509/tokenless auth and something like this, we can be better about it - it drives towards no "directly managed identity store" | 19:45 |
| kfox1111 | so long as the cert handed back allows that, I'm good. | 19:46 |
| ayoung | morganfainberg if we let Nova sign tokens, and then the VM could reqeust tokens from Nova... | 19:46 |
| morganfainberg | ayoung: i would never let nova directly sign. | 19:46 |
| morganfainberg | ayoungat this point | 19:46 |
| ayoung | why not | 19:46 |
| kfox1111 | morganfainberg: I'm with you. I'd rather handle as little as possible myself. :) | 19:46 |
| morganfainberg | anyway i need to go | 19:46 |
| ayoung | iff and only iff we knoew who signed a token.... | 19:46 |
| ayoung | different keys...all that... | 19:46 |
| ayoung | kfox1111, none of this is going to happen soon | 19:47 |
| morganfainberg | ayoung: so just tossing a view onto the pile of "how to handle this", but i think it's better if we don't do direct user management here | 19:47 |
| ayoung | this is just the glimmer of an idea | 19:47 |
| morganfainberg | some of it can happen sooner with some scaffolding | 19:47 |
| morganfainberg | but it's going to take a chunk of work | 19:47 |
| kfox1111 | ayoung: whats soon? | 19:47 |
| kfox1111 | We need instance users of some kind for Liberty. | 19:47 |
| ayoung | morganfainberg, so if we had a CA, then the VM could request a cert. We could use federation | 19:47 |
| kfox1111 | It can be imperfect if it can be grown into the more secure meachanism over time. | 19:48 |
| ayoung | it would be gyee 's tokenless auth | 19:48 |
| ayoung | + federation | 19:48 |
| morganfainberg | ayoung: that at the least could happen 100% outside of keystone | 19:48 |
| morganfainberg | no new APIs needed. | 19:48 |
| ayoung | morganfainberg, right | 19:48 |
| morganfainberg | so that is a good starting place | 19:48 |
| kfox1111 | so nova gains a CA? | 19:48 |
| ayoung | morganfainberg, but we still need delagation | 19:48 |
| ayoung | kfox1111, Barbican is the CA, I think | 19:48 |
| morganfainberg | kfox1111: nova gains a way to say "hey CA give me a cert" | 19:48 |
| kfox1111 | hah. ok, so, | 19:49 |
| morganfainberg | ayoung: this could all be rough with config. | 19:49 |
| morganfainberg | kfox1111: nova's service user would do that specifically | 19:49 |
| kfox1111 | nova -> barbican get an instance user cert -> novadb -> launches vm | 19:49 |
| morganfainberg | kfox1111: not the VM-specific auth construct | 19:49 |
| morganfainberg | yep | 19:49 |
| morganfainberg | and that cert can be used to talk to keystone for the vm | 19:49 |
| kfox1111 | vm boots -> nova metadata server, cert -> keystone get token. | 19:49 |
| kfox1111 | vm -> barbican. :) | 19:49 |
| morganfainberg | that is the immediate solution with the token-less auth | 19:49 |
| *** afazekas has quit IRC | 19:49 | |
| morganfainberg | in keystone slated for liberty | 19:50 |
| kfox1111 | plus making nova an identity provider still required? | 19:50 |
| morganfainberg | kfox1111: nope | 19:50 |
| morganfainberg | barbican's CA is technically the identity provider then | 19:50 |
| morganfainberg | and keystone explicitly trusts it. | 19:50 |
| kfox1111 | or does it just "keystone create user + here's the pubkey" | 19:50 |
| morganfainberg | kfox1111: it uses the x509 cert as auth, and keystone does the federated user mapping | 19:51 |
| morganfainberg | kfox1111: no user-create needed (again) | 19:51 |
| kfox1111 | oh. using attributes in the cert? | 19:51 |
| morganfainberg | yep | 19:51 |
| kfox1111 | ok... so the nwe need to make sure barbican can allow a user to set those attributes. | 19:51 |
| * morganfainberg really needs to jump off IRC again. | 19:51 | |
| kfox1111 | ok. thanks. I really appreciate it. :) | 19:51 |
| morganfainberg | kfox1111: should be normal attributes from the cert nothing magical | 19:51 |
| morganfainberg | but yes. | 19:51 |
| morganfainberg | it uses the mapping engine in keystone to map the standard attrs over | 19:52 |
| *** boris-42 has quit IRC | 19:52 | |
| * morganfainberg lets ayoung talk more about this. | 19:52 | |
| morganfainberg | if needed | 19:52 |
| dstanek | raildo: is there any documentation that tells users how to think about the projects->domains transition? | 19:52 |
| kfox1111 | I'll update the spec and run it by you guys again. :) | 19:52 |
| raildo | dstanek, hum.. not now, but it's something that we need to do in liberty | 19:53 |
| raildo | dstanek, btw I had updated the keystone documentation with the parent_id information: https://review.openstack.org/#/c/191184/ | 19:54 |
| *** HT_sergio has joined #openstack-keystone | 19:55 | |
| raildo | dstanek, so, we need to keep doing this in every official documentation (admin guide, installation, glossary...) | 19:55 |
| dstanek | raildo: ok, i was curious because i understand domains/projects, but i don't understand how to tell the user that some domains may act as projects and when they would do that | 19:57 |
| *** afazekas has joined #openstack-keystone | 19:57 | |
| dstanek | raildo: to we have use cases for that? when a domain should be used like a project and when a project should be used as a domain? | 19:57 |
| ayoung | kfox1111, so...separate Identiyt from authorization. In this case, the X509 idenitifies the VM as them. It is still up to Keystone to map that to something | 20:00 |
| ayoung | and the mapping API for Federation is even more "must be done by admin" than role assignments | 20:00 |
| ayoung | so..this is just another way of identifing a resources. It means, yeah, no explicit entry in the user table, but that is it | 20:01 |
| morganfainberg | and the mapping should be generic enough that it's a one-off in this case (once for each service doing this, so not needed per vm, but just before nova can use this mechanism) | 20:01 |
| ayoung | how we would then say "Vmthx1138 is authorize to fetch this secret" is still not nailed down | 20:01 |
| raildo | dstanek, I can see some use cases, like I'm a domain_admin, I want a VM but I don't want to influence the projects in my domain, so I can handle with my domain as a project and create my instance | 20:02 |
| ayoung | morganfainberg, so it should have something like an association with the project that spun it up, and no more permissions than the user that spun it up...but a different lifespan" | 20:02 |
| dstanek | raildo: what is the benefit of them doing that over creating their own project | 20:02 |
| morganfainberg | ayoung: i ... think so? | 20:02 |
| * morganfainberg ducks out before exceeding the IRC limit for the day. | 20:03 | |
| ayoung | morganfainberg, I think I'm going to cop out and just use your slides. | 20:03 |
| morganfainberg | ayoung: steve shared mine? | 20:03 |
| ayoung | morganfainberg, yep | 20:03 |
| morganfainberg | cool. if you make changes / clean them up some please pass those back | 20:03 |
| morganfainberg | i want to conver it to reveal.js and publish it as a publication | 20:04 |
| *** afazekas has quit IRC | 20:04 | |
| morganfainberg | it needs a little more cleanup (Some slides are too verbose) | 20:04 |
| morganfainberg | convert* | 20:04 |
| ayoung | morganfainberg, I want to convert it to Latex, but that isnot happening tonight | 20:04 |
| morganfainberg | don't do latex :P | 20:04 |
| morganfainberg | use reveal | 20:04 |
| morganfainberg | html slides | 20:04 |
| *** Rockyg has quit IRC | 20:04 | |
| morganfainberg | RST driven | 20:04 |
| raildo | one of benefits that I see is that I don't need to create a project, and a new role assignment for this user in this project, set quotas for this new project. | 20:04 |
| morganfainberg | iirc | 20:04 |
| ayoung | morganfainberg, latex can generate all that and more. it is what I used for the summit. PDF too | 20:05 |
| raildo | dstanek, ^ | 20:05 |
| kfox1111 | ayoung: vm x is authorized to get this secret's up to barbican's acl api I think. | 20:05 |
| kfox1111 | I think it should work. :) | 20:05 |
| *** Rockyg has joined #openstack-keystone | 20:05 | |
| ayoung | kfox1111, so...let's say we do this X509 thing, which we can totally do. Then Barbican needs a mapping file, which, while it should get from Keystone, could be hand waved away.... | 20:05 |
| morganfainberg | ayoung: well the official publications i want to do should all be strict html | 20:05 |
| morganfainberg | and that is what i want to publish, anyway i'll be doing reveal | 20:06 |
| ayoung | morganfainberg, Ah...very good | 20:06 |
| morganfainberg | but like i said, more important - just let me know what/if you change things so we can roll it up | 20:06 |
| ayoung | morganfainberg, no problem with that, but have not yet learned reveal. | 20:06 |
| ayoung | morganfainberg, the only things I 've seen have been RH specific issues, like not supporting mod_shib | 20:06 |
| morganfainberg | it's basically all RST and some jscript stuff | 20:06 |
| morganfainberg | it's nice. | 20:06 |
| ayoung | and I wanted to dig deeper into the KErberos and HTTPD stuff | 20:07 |
| morganfainberg | all the slides from mordred and devananda are reveal | 20:07 |
| morganfainberg | they're cool stuff and look good. | 20:07 |
| raildo | dstanek, I think that can exists more use cases for, but I need to think more about that. | 20:07 |
| ayoung | I'd bump SSSD into the Federation section, as we can use that today | 20:07 |
| morganfainberg | ayoung: email / share a changed slide deck :) | 20:07 |
| samuel-dmq | morganfainberg: could I have access to those slide presentations ? | 20:08 |
| ayoung | morganfainberg, I'm not sure I will change it. I might just mention those things inthe preso...still reading through and considering, but I will def contribute back | 20:08 |
| morganfainberg | samuel-dmq: i think i gave you a link. i justhaven't converted to the new format | 20:08 |
| morganfainberg | i'm avoiding sharing the google deck to far until we have a better format | 20:08 |
| * morganfainberg isn't a fan of the google slide format | 20:08 | |
| morganfainberg | it's too PPT-ish | 20:08 |
| samuel-dmq | morganfainberg: that's the one about keystone in general, ec | 20:09 |
| morganfainberg | yes | 20:09 |
| *** radez is now known as radez_g0n3 | 20:09 | |
| ayoung | agreed | 20:09 |
| samuel-dmq | morganfainberg: nice thanks | 20:09 |
| ayoung | morganfainberg, also, this is an internal presentation. I don't know what will happen with the slides. If we don't want them in wide distribution, I might have to make my own preso. I stared that alreadym but in Latex, and I cover a lot of the same material....anyway, I'll let you know. | 20:10 |
| morganfainberg | yeah np | 20:11 |
| morganfainberg | just want the contribution of changes that should go back into the main deck | 20:11 |
| morganfainberg | not any $internal_things | 20:11 |
| dstanek | raildo: this brings it back toward my original thought of hierarchal domains | 20:11 |
| kfox1111 | ayoung: Wouldn't it just pull the username from the cert attribute where the username is basically just the instance uuid passed from nova? | 20:12 |
| kfox1111 | the mapping in keystone would basically just that? | 20:12 |
| ayoung | kfox1111, essentially. The tricky part is mapping the attributes from the cert to the groups and role assignemtns necessary | 20:12 |
| kfox1111 | I think thats where trusts come in. If the user wants that, then they associate the instance user with their own stuff via a trust? | 20:13 |
| kfox1111 | or they acl the resources individually in the services that support that. | 20:13 |
| ayoung | kfox1111, too many directions at once....AH! | 20:14 |
| kfox1111 | though Ireally think it would be awesome if Keystone supported a restricted resource token. | 20:14 |
| gyee_ | ayoung, nkinder__, having trouble with SSSD here, I am trying to setup SSSD on Ubuntu | 20:14 |
| kfox1111 | (yeah. I'm in 2 other meetings. :/ ) | 20:14 |
| ayoung | kfox1111, OK, so I think that trusts are one thing...that is today....the X509 thing is different, that is tomorrow | 20:14 |
| ayoung | gyee_, nkinder__ is moving houses | 20:14 |
| ayoung | gyee_, I'll see if I can field it, though | 20:14 |
| gyee_ | ayoung, nkinder__, its keep telling me I have an older version of sssd.conf | 20:14 |
| kfox1111 | so a user could create a trust that says "only allow access to this one resource uuid on this service" | 20:14 |
| gyee_ | and asking me to run the configuration upgrade script | 20:15 |
| kfox1111 | ayoung: yeah. agreed. | 20:15 |
| gyee_ | so where's this magic configuration upgrade script | 20:15 |
| ayoung | gyee_, let me see what I have on my machine | 20:15 |
| *** ccrouch has joined #openstack-keystone | 20:16 | |
| kfox1111 | the token returned by that restricted trust would contain the restriction and the openstack services would allow access only if the resource was mentioned in the token. | 20:16 |
| gyee_ | ayoung, in my [sssd] section, I set config-file-version to 2, 3, 4, 5, and none of them seem to work | 20:16 |
| raildo | dstanek, and what was that thought? | 20:16 |
| *** zzzeek has quit IRC | 20:16 | |
| gyee_ | so I have no clue what exact version it is looking for | 20:16 |
| ayoung | gyee_, I know this from nothing...but I can find out...hold on | 20:16 |
| *** belmoreira has joined #openstack-keystone | 20:16 | |
| ayoung | gyee_, and I am not certain I have it set up correctly on this machine. | 20:17 |
| *** Rockyg has quit IRC | 20:17 | |
| *** pnavarro has joined #openstack-keystone | 20:18 | |
| ayoung | gyee_, what is the exact error message you are getting? | 20:18 |
| ayoung | gyee_, it might be authconfig | 20:19 |
| *** samuel-dmq has quit IRC | 20:19 | |
| dstanek | raildo: when we were discussing this (at Paris?) I mentioned hierarchical domains instead of projects because that's what all of the use cases were indicating | 20:19 |
| gyee_ | ayoung, is there a cache I need to cleanup | 20:19 |
| gyee_ | changing config-file-version seem to have no effect | 20:19 |
| ayoung | gyee_, there might be. But Give me the steps you are going through and I might be able to answer better | 20:20 |
| *** henrynash has joined #openstack-keystone | 20:21 | |
| *** ChanServ sets mode: +v henrynash | 20:21 | |
| gyee_ | ayoung, I basically installed the sssd packages on my ubuntu 14.04 vm, manually created sssd.conf in /etc/sssd/, and restart | 20:21 |
| ayoung | gyee_, and by restart, you mean running by hand as root? init.d script, what? | 20:22 |
| gyee_ | sssd.conf is owned by root and have 0600 file perm as instructed | 20:22 |
| gyee_ | ayoung, service sssd restart | 20:22 |
| ayoung | gyee_, best bet is /join #sssd | 20:22 |
| ayoung | I'll answer there, and there will be someone smarter than me who will join in and say where I am wrong | 20:23 |
| *** jaypipes has joined #openstack-keystone | 20:23 | |
| jaypipes | morgan: hey, what's your email now? I only have the metacloud one.../ | 20:23 |
| *** zzzeek has joined #openstack-keystone | 20:24 | |
| morganfainberg | jaypipes: morgan.fainberg@gmail.com | 20:24 |
| jaypipes | danke | 20:24 |
| morganfainberg | jaypipes: (i know.. hard huh?) | 20:24 |
| morganfainberg | np | 20:24 |
| jaypipes | :) | 20:24 |
| * morganfainberg suddenly looks for email from jaypipes | 20:24 | |
| *** afazekas has joined #openstack-keystone | 20:26 | |
| raildo | dstanek, We are trying to do both with reseller, so we can handle with the hierarchical domains as is-domain=True, and with the hierarchical projects use cases as is_domain=False, in a single hierarchy... | 20:26 |
| jaypipes | morganfainberg: look for the "Microversion API HTTP header" subject one. | 20:26 |
| morganfainberg | yeah | 20:26 |
| morganfainberg | was actually responding to that one now | 20:26 |
| dstanek | raildo: can a Project<is_domain=False> own another project? | 20:27 |
| raildo | dstanek, yes. another Project<is_domain=False> | 20:29 |
| dstanek | raildo: what was the use case for that? | 20:29 |
| dstanek | raildo: i'm just trying to get a handle on this (not say what's wrong or right) - i find it very confusing | 20:30 |
| *** afazekas has quit IRC | 20:31 | |
| raildo | dstanek, no problem :) and I'm trying to do my best to explain this, sorry if I'm not clear enough | 20:31 |
| ccrouch | I'm looking for SAML IdPs: e.g. simplesamlphp or shibboleth, that could be infront of an LDAP server and that keystone could then use for SSO. Any suggestions besides the two I mentioned? | 20:32 |
| raildo | dstanek, so, the use cases for this, is the same for hmt, departmental division in a company and provide hierarchical quotas | 20:32 |
| raildo | dstanek, moreover, improve the assignment management with inherited role assignments. | 20:33 |
| dstanek | raildo: is that use case satisfied with a hierarchy of domains and no project->project ownership? | 20:34 |
| dstanek | raildo: when i say domains i mean is_domain=True and when i say project i mean is_domain=False | 20:35 |
| kfox1111 | fixing up the spec... here's a question.... | 20:35 |
| raildo | dstanek, hum... i don't think so... first of all, we don't have domain quotas, so I can't control this only with domains hierarchy | 20:35 |
| kfox1111 | nova -> barbican , gets a cert. | 20:35 |
| kfox1111 | nova hands back X piece of metadata to the user. User associates the barbican acl with user X | 20:36 |
| raildo | dstanek, besides that, I saw hierarchical projects useful to distribute resources in the hierarchy and I can't create a instance or image in a domain | 20:36 |
| kfox1111 | Do you still have to do a keystone create call to make sure a uuid gets assigned to it? | 20:36 |
| dstanek | raildo: domains would be irrelevant; if you have a 100 project quota minimum you could create more than 100 in the hierarchy | 20:36 |
| morganfainberg | jaypipes: responded, sorry for the little hectic formatting, mobile plus... i'm trying to duck out of IRC for the day | 20:37 |
| raildo | dstanek, that's why that we are working to provide hierarchical quotas: https://blueprints.launchpad.net/nova/+spec/nested-quota-driver-api | 20:38 |
| morganfainberg | jaypipes: included spec and etherpad link. | 20:38 |
| kfox1111 | If a create is needed, I assume a delete is needed as well? | 20:38 |
| *** afazekas has joined #openstack-keystone | 20:38 | |
| raildo | dstanek, https://review.openstack.org/#/c/160605/3/specs/liberty/approved/nested-quota-driver-api.rst | 20:38 |
| *** zzzeek has quit IRC | 20:38 | |
| jaypipes | morganfainberg: no worries, thanks man! | 20:39 |
| kfox1111 | morganfainberg: might have a hole in the process. :/ | 20:39 |
| morganfainberg | ccrouch: redhat has ipsilon, not sure about it's state. | 20:39 |
| ccrouch | ah ha, thanks | 20:41 |
| ccrouch | https://fedorahosted.org/ipsilon/ | 20:41 |
| raildo | dstanek, the important thing in this links is that we will be able to control the quota for subprojects as a subquota for the parent project | 20:41 |
| morganfainberg | kfox1111: so keystone will use an apache module to validate the cert, meaning that nova will just need to do the barbican delete which needs to do CRL stuff | 20:41 |
| ccrouch | Latest release: Version 1.0.0 Released on 2015-05-12 | 20:41 |
| ccrouch | fresh out of the oven :-) | 20:41 |
| morganfainberg | kfox1111: as long as the apache module handles CRLs properly that delete should be sufficient | 20:42 |
| kfox1111 | no, how does the real user associate a barbican acl or a keystone trust with it, | 20:42 |
| kfox1111 | without having the whole cert? | 20:42 |
| morganfainberg | kfox1111: the active tokens will remain active in keystone unless you do an explicit revoke. but I'm inclined to say that's fine | 20:42 |
| kfox1111 | those api's expect keystone uuids. | 20:42 |
| morganfainberg | kfox1111: you get a token from keystone with the cert, the token has all the normal things (Except the user's id is not uuid, it's a sha256) | 20:43 |
| kfox1111 | I'd rather not duplicate all of keystone's trust api into nova/barbican. :/ | 20:43 |
| morganfainberg | when you use the cert to auth with keystone, you get a normal token | 20:43 |
| kfox1111 | so then you can use that sha256 in the trust api? | 20:44 |
| morganfainberg | well a federated token | 20:44 |
| dstanek | raildo: i'm just worried the model is wrong | 20:44 |
| morganfainberg | so you can do waht you normal would do with that token | 20:44 |
| *** afazekas has quit IRC | 20:44 | |
| morganfainberg | just as if you had authed with a username/password | 20:44 |
| morganfainberg | including trust things. | 20:44 |
| morganfainberg | i really don't know what you're trying to solve now | 20:44 |
| kfox1111 | Its an issue of who has the cert. | 20:45 |
| morganfainberg | ok, so nova creates the cert. | 20:45 |
| kfox1111 | regular user contacts nova, "create me an instance + user. | 20:45 |
| morganfainberg | stores the value it needs for the VM | 20:45 |
| kfox1111 | nova does that. It now has a cert for instance "12345" | 20:45 |
| morganfainberg | inject the data into the metadata service or whatever | 20:45 |
| morganfainberg | so the VM can get it [in nova's db] | 20:45 |
| kfox1111 | it now talks to keystone and gets a token. | 20:46 |
| morganfainberg | change as needed | 20:46 |
| morganfainberg | vm uses cert to talk to keystone, gets token | 20:46 |
| kfox1111 | it then returns the sha256 uuid to the creator of the instance | 20:46 |
| morganfainberg | token is the same as a normal username/password token | 20:46 |
| morganfainberg | just has some extra attrs in it to show it's federated | 20:46 |
| morganfainberg | do normal actions with token | 20:46 |
| morganfainberg | when VM is deleted - nova tells barbican delete cert | 20:46 |
| kfox1111 | the launching user then contacts the keystone trust api, using that sha256 and associates some of his/her roles with that sha256 user uuid? | 20:47 |
| morganfainberg | CRL is updated | 20:47 |
| morganfainberg | ok so lets back up | 20:47 |
| kfox1111 | k. | 20:47 |
| morganfainberg | what is the VM going to do | 20:47 |
| morganfainberg | what does the VM need to be able to do? | 20:47 |
| kfox1111 | ok. lets do a concrete workflow. | 20:47 |
| morganfainberg | what is the very specific case you're trying to solve (not generic: get a token for keystone) | 20:47 |
| morganfainberg | yes | 20:47 |
| kfox1111 | user wants to launch a heat temlpate for a scalable web server. | 20:47 |
| kfox1111 | main template contains: autoscaling group. keeps between 1 and 7 servers running. Using templateb.yaml | 20:48 |
| kfox1111 | template b: contains: | 20:48 |
| kfox1111 | 1 nova instance. | 20:48 |
| kfox1111 | 1 barbican acl, associates nova_insance.instance_user_uuid to barbican container "secrets_to_make_instance_work" | 20:49 |
| kfox1111 | 1 shell script dependent on barbican acl finishing, that fetches token from nova metadata server, | 20:50 |
| kfox1111 | and contacts barbican to get the keys. then starts up the webserver. | 20:50 |
| kfox1111 | the system can then automatically create and delete servers to handle load without user interaction. | 20:51 |
| kfox1111 | make sense? | 20:51 |
| raildo | dstanek, I have to go in a few minutes, if you want to talk more about this, I'll come back 2-3 hours, or we can talk tomorrow. | 20:51 |
| dstanek | tomorrow is fine | 20:52 |
| dstanek | raildo: ^ | 20:52 |
| raildo | dstanek, ok, thank you for your time :) | 20:52 |
| kfox1111 | actually, there are two more parts I forgot. One load balancer in the main template, one load ballancer attachment in templateB. | 20:53 |
| kfox1111 | the problem is, in the nova code, I have to return some piece of metadata, that allows the barbican container acl api to be called to add the permission. | 20:54 |
| *** MaxV has joined #openstack-keystone | 20:54 | |
| morganfainberg | kfox1111: ok so. reading backscroll n | 20:55 |
| morganfainberg | kfox1111: just needed another coffee | 20:55 |
| *** raildo has quit IRC | 20:55 | |
| morganfainberg | kfox1111: so yeah, nova will need to ask keystone what the ID of the user that cert will generate is | 20:56 |
| morganfainberg | kfox1111: but that should be relatively easy (or the end user does) | 20:56 |
| morganfainberg | kfox1111: and then you need to do the normal trust association work | 20:56 |
| kfox1111 | ok. is there an api for that today, or will that be part of the work to be done? | 20:56 |
| *** dims_ has joined #openstack-keystone | 20:56 | |
| morganfainberg | kfox1111: keystone will need to expose an API for that | 20:56 |
| kfox1111 | ok. should it have a corisponding delete call for when its no longer needed then, since its a little stateful? | 20:57 |
| kfox1111 | Nova knows when the instance is deleted, so I can call a keystone api at that point. | 20:57 |
| morganfainberg | kfox1111: no shouldn't be needed. but i think we need to get some more logic in keystoen | 20:57 |
| kfox1111 | ok. then I'll drop the delete part out of the spec. | 20:58 |
| morganfainberg | because the state in keystone is maintained as a map | 20:58 |
| morganfainberg | basically we hold minimal state that canbe flushed [but will be recreated on demand] | 20:58 |
| morganfainberg | same ids etc | 20:58 |
| morganfainberg | it's programatic | 20:58 |
| kfox1111 | and modify the create wording to just say fetch uuid from keystone? | 20:58 |
| morganfainberg | fetch user-id | 20:58 |
| morganfainberg | don't use UUID | 20:58 |
| kfox1111 | ok. | 20:58 |
| morganfainberg | uuid assumes a specific format and length | 20:58 |
| kfox1111 | ah. ok. | 20:58 |
| morganfainberg | we so SHA256(Domain_id + user_element_from_federated_source) | 20:59 |
| morganfainberg | in this case federated source is cert DN | 20:59 |
| morganfainberg | and attributes | 20:59 |
| morganfainberg | s/so/do | 20:59 |
| kfox1111 | ah. gotcha. | 20:59 |
| *** samuel-dmq has joined #openstack-keystone | 20:59 | |
| morganfainberg | uuid assume (uhhh i think) 16bytes of data binary, or 32 hex | 21:00 |
| morganfainberg | etc | 21:00 |
| kfox1111 | yeah. sounds about right. | 21:00 |
| morganfainberg | and conforms to uuid.UUID() | 21:00 |
| morganfainberg | which sha256 absolutely does not | 21:00 |
| *** dims has quit IRC | 21:00 | |
| kfox1111 | though I think in most of openstack, the db fields are just strings. | 21:00 |
| kfox1111 | but yeah. being explicit helps. | 21:00 |
| morganfainberg | yes, but len(sha256) > uuid | 21:00 |
| kfox1111 | right. | 21:00 |
| *** dims_ has quit IRC | 21:00 | |
| morganfainberg | so that way no one assumes a user_id is 32bytes hex | 21:00 |
| morganfainberg | so we need 2 things for keystone: "what would X assertion's user_id be" [specifically for x509, but probably wider scope], and 2) tokenless auth | 21:02 |
| morganfainberg | the rest is nova/normal workflow you'd need to do via trusts/etc | 21:03 |
| morganfainberg | and barbican needs to issue certs / manage CA, and when a delete, CRL needs to be updated so the apache module can do it | 21:03 |
| *** stevemar2 has joined #openstack-keystone | 21:03 | |
| *** ChanServ sets mode: +v stevemar2 | 21:03 | |
| kfox1111 | yeah. sounds good. :) | 21:03 |
| *** stevemar has quit IRC | 21:04 | |
| openstackgerrit | henry-nash proposed openstack/keystone: Relax newly imposed sql driver restriction for domain config https://review.openstack.org/191976 | 21:04 |
| morganfainberg | s/do it/reference CRL | 21:04 |
| *** MaxV has quit IRC | 21:05 | |
| *** bknudson has quit IRC | 21:09 | |
| *** gabriel-bezerra has quit IRC | 21:10 | |
| *** iurygregory has quit IRC | 21:11 | |
| *** ericksonsantos has quit IRC | 21:11 | |
| *** htruta has quit IRC | 21:11 | |
| *** samueldmq has quit IRC | 21:11 | |
| *** tellesnobrega has quit IRC | 21:11 | |
| *** afaranha has quit IRC | 21:11 | |
| *** pnavarro has quit IRC | 21:15 | |
| *** henrynash has quit IRC | 21:18 | |
| ayoung | morganfainberg, I think we can export the mapping to solve "what would X assertion's user_id be" | 21:23 |
| morganfainberg | ayoung: this will need to be an API call. but yes | 21:23 |
| morganfainberg | ayoung: i don't think i want nova to try and determine this on it's own | 21:23 |
| morganfainberg | easier to just ask keystone (and has the added bonus of building the map in the user/group/domain table thing) | 21:24 |
| ayoung | morganfainberg, we could do it either way. An API call for each call to a remote service would be expensive...why not let the remote service calculate it? | 21:24 |
| morganfainberg | ayoung because if you're assigning to it you already need to create it. *shrug* it's going to be expensive either way | 21:24 |
| *** samuel-dmq has quit IRC | 21:25 | |
| ayoung | morganfainberg, I'd like to get Keystone out of the hot path. My thought was that everything Keystone does could be done by a remote service with cached data from Keystone | 21:25 |
| morganfainberg | ayoung: will discuss this later on. | 21:25 |
| * morganfainberg is way over budget for IRC today | 21:26 | |
| morganfainberg | way way way | 21:26 |
| *** dsirrine has quit IRC | 21:26 | |
| stevemar2 | morganfainberg, go rest :) | 21:27 |
| *** zzzeek has joined #openstack-keystone | 21:32 | |
| *** dims has joined #openstack-keystone | 21:35 | |
| *** e0ne has quit IRC | 21:36 | |
| *** afaranha has joined #openstack-keystone | 21:39 | |
| *** tellesnobrega has joined #openstack-keystone | 21:39 | |
| *** htruta has joined #openstack-keystone | 21:39 | |
| *** samueldmq has joined #openstack-keystone | 21:39 | |
| *** iurygregory has joined #openstack-keystone | 21:39 | |
| *** ericksonsantos has joined #openstack-keystone | 21:39 | |
| *** gabriel-bezerra has joined #openstack-keystone | 21:40 | |
| *** belmoreira has quit IRC | 21:42 | |
| *** bknudson has joined #openstack-keystone | 21:43 | |
| *** ChanServ sets mode: +v bknudson | 21:43 | |
| *** stevemar2 is now known as stevemar | 21:43 | |
| stevemar | ayoung, did you get my links? | 21:43 |
| stevemar | i never received an ACK from you | 21:43 |
| *** henrynash has joined #openstack-keystone | 21:49 | |
| *** ChanServ sets mode: +v henrynash | 21:49 | |
| *** henrynash has quit IRC | 21:56 | |
| *** edmondsw has quit IRC | 21:56 | |
| *** chlong has quit IRC | 21:57 | |
| *** boris-42 has joined #openstack-keystone | 22:01 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/keystone: Updated from global requirements https://review.openstack.org/190405 | 22:02 |
| *** RichardR_ has joined #openstack-keystone | 22:03 | |
| *** RichardRaseley has quit IRC | 22:07 | |
| *** RichardR_ has quit IRC | 22:08 | |
| *** fangzhou has joined #openstack-keystone | 22:12 | |
| *** csoukup has quit IRC | 22:14 | |
| *** csoukup has joined #openstack-keystone | 22:19 | |
| *** stevemar has quit IRC | 22:21 | |
| *** charlesw has joined #openstack-keystone | 22:21 | |
| charlesw | Hi folks, I have a two-region swift cluster. I wonder how to set up region_name in keystone middleware config in my proxy-server.conf. I looked around to see if auth_region_name is supported but all I could find is https://bugs.launchpad.net/keystonemiddleware/+bug/1405717. Does anybody know if auth_region_name is supported? | 22:22 |
| openstack | Launchpad bug 1405717 in keystonemiddleware "region_name is not in keystone client auth_token config" [Wishlist,Confirmed] | 22:22 |
| bknudson | charlesw: there's no auth_region_name option in auth_token middleware -- http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token/__init__.py#n238 | 22:25 |
| bknudson | looks like the bug still needs someone to do the work | 22:26 |
| charlesw | Then which region's Keystone server will validate the token? | 22:29 |
| bknudson | I assume it's the one you put in auth_uri | 22:30 |
| *** david-lyle has quit IRC | 22:31 | |
| charlesw | thx bknudson. I'll report back if I can confirm it. | 22:32 |
| *** dims has quit IRC | 22:34 | |
| *** thedodd has quit IRC | 22:38 | |
| *** kfox1111 has quit IRC | 22:40 | |
| *** kfox1111 has joined #openstack-keystone | 22:41 | |
| *** HT_sergio has quit IRC | 22:41 | |
| openstackgerrit | Doug Fish proposed openstack/python-keystoneclient: WIP: Allow listing of sp projects https://review.openstack.org/191995 | 22:42 |
| *** charlesw has quit IRC | 22:44 | |
| *** hogepodge has quit IRC | 22:52 | |
| *** zzzeek has quit IRC | 22:56 | |
| *** dims has joined #openstack-keystone | 23:03 | |
| *** dims has quit IRC | 23:03 | |
| *** dims has joined #openstack-keystone | 23:04 | |
| *** jaosorior has quit IRC | 23:05 | |
| *** zzzeek has joined #openstack-keystone | 23:08 | |
| *** david-lyle has joined #openstack-keystone | 23:11 | |
| *** obedmr has quit IRC | 23:18 | |
| *** hogepodge has joined #openstack-keystone | 23:19 | |
| *** EmilienM|afk is now known as EmilienM | 23:24 | |
| *** zzzeek has quit IRC | 23:25 | |
| *** roxanaghe has quit IRC | 23:33 | |
| *** csoukup has quit IRC | 23:38 | |
| *** chlong has joined #openstack-keystone | 23:47 | |
| *** csoukup has joined #openstack-keystone | 23:55 | |
| *** zzzeek has joined #openstack-keystone | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!