#moc irc logs re: keystone auth

moc-irc-keystone-auth-discussion

2016-06-08T16:16:56  *** isd <isd!~isd@172.56.4.12> has joined #moc
2016-06-08T16:19:43  <isd> gsilvis: working on the hil keystone auth backend. IIRC, our plan had been to just map openstack project names to hil project names. I'm looking at the keystonemiddleware docs, and while it exposes that, it's only unique per domain. thoughts on how to deal with that? You have a bit more of a handle on what all the various keystone notions are than I am.
2016-06-08T16:20:00  <isd> I'm not 100% on what a domain is in the context of keystone
2016-06-08T16:24:09  <gsilvis> domains are containers that can contain projects [and also users]
2016-06-08T16:24:24  <gsilvis> right now openstack hasn't really decided to deal with that per-domain problem
2016-06-08T16:24:34  <gsilvis> one option:  hardcode haas to use a specific domain
2016-06-08T16:24:49  <gsilvis> not hardcode, rather---config option
2016-06-08T16:26:07  <isd> Just a thing in haas.cfg, and if it doesn't match reject it? That's something I'd thought of, probably the thing to do for now.
2016-06-08T16:26:43  <gsilvis> Yeah

...

2016-06-08T16:56:42  <knikolla> isd: on another note. are we letting keystone store the projects? or the project must exist on both keystone and hil?
2016-06-08T16:57:10  <isd> IIRC the plan had been needing to create it on both. gsilvis?
2016-06-08T16:57:23  <gsilvis> that's how I've generally imagined it
2016-06-08T16:57:28  <gsilvis> it works either way, I suppose

...

2016-06-08T16:58:14  <knikolla> isd: gsilvis: i'd rather have hil query keystone for the projects and only maintain an abstraction and a reference impementation in hil.
2016-06-08T16:58:25  <knikolla> https://github.com/CCI-MOC/haas/issues/595
2016-06-08T16:58:59  <gsilvis> hmmm
2016-06-08T16:59:05  <gsilvis> in nova, how does a project get a quota?
2016-06-08T16:59:18  <gsilvis> like, before anyone has ever talked to nova about that project, how does nova know what its quota is?
2016-06-08T16:59:28  <knikolla> gsilvis: they reference projects by uuid, but don't maintain a projects table
2016-06-08T16:59:55  <gsilvis> isd: ^-- how do you feel about that method?
2016-06-08T17:00:12  <gsilvis> consistency with other openstack projects is probably a good thing
2016-06-08T17:01:25  <isd> If we get a valid request from a project that doesn't exist in our database, we could just create it.
2016-06-08T17:01:45  <isd> Less invasive change.
2016-06-08T17:02:31  <isd> Also, I am very against making changes that make using hil outside the context of openstack less workable.
2016-06-08T17:02:45  <gsilvis> oh, hmph, that does require a significant change to how hil does projects, doesn't it.
2016-06-08T17:03:21  <knikolla> isd: that would be a first step. my proposal doesn't make hil less workable without openstack. We'd still have the sql reference implementation.
2016-06-08T17:03:28  <knikolla> isd: the only change would be an abstraction.
2016-06-08T17:03:43  <knikolla> isd: we have one for auth, why not for authZ.
2016-06-08T17:04:32  <isd> The auth plugin does both authentication and authorization; remember it implements has_*_access as well.
2016-06-08T17:04:49  <isd> Doesn't have to be a simple lookup.
2016-06-08T17:04:49  <gsilvis> another way you could do it----have openstack projects be like hil users [in the sql backend]
2016-06-08T17:05:05  <gsilvis> so projects are managed by hil, and there's an ext call to add a keystone project to the hil project
2016-06-08T17:05:11  <gsilvis> ... I don't really like that
2016-06-08T17:05:14  <gsilvis> but it is possible
2016-06-08T17:05:20  <gsilvis> and preserves existing abstractions
2016-06-08T17:05:29  <knikolla> isd: which i don't really like having the two together. i like a clear separation between users and projects.
2016-06-08T17:05:44  <isd> knikolla: there's no reason users need to exist.
2016-06-08T17:06:33  *** jbell8 <jbell8!~jbell8@c-73-149-121-218.hsd1.ma.comcast.net> has joined #moc
2016-06-08T17:07:24  <knikolla> isd: give me an example of a backend that doesn't have any concept of users.
2016-06-08T17:07:41  <isd> knikolla: something capability based.
2016-06-08T17:08:06  <isd> but that's a major rework of the way haas works
2016-06-08T17:09:28  <isd> You could also do delegated tokens; we can't really do fine grained access, but I could add a backend where there are multiple tokens that have access to a project, and are formed in a hierarchy. You can create a derived token, and the parents can delete whole subtrees.
2016-06-08T17:10:20  <isd> Can put notes on the token too, so you have a nice audit trail of not what "user" did a thing, but the entire chain of who got access from whom.
2016-06-08T17:11:06  <isd> If I'm just going to report a username from the keystone plugin, I'm bound to giving less information; I could see as a future extension logging the fact that this was e.g. heat acting on behalf of soandso, not just soandso.
2016-06-08T17:11:07  <knikolla> isd: i don't see how having project location abstracted would break that. but i'm not very familiar with these methods and will do some research.
2016-06-08T17:11:36  <isd> location?
2016-06-08T17:11:42  <isd> not sure what you mean by that.
2016-06-08T17:12:59  <knikolla> isd: you reference projects by id, but don't necessarily maintain a table of them. if you need to list them, you query the backend. which could be sql. in that case thinks would work exactly as they are now.
2016-06-08T17:13:49  <isd> knikolla: could do that. and the owner fields would just be string/bytes with the UUID?
2016-06-08T17:15:39  <gsilvis> [btw knikolla and I are in a meeting right now---he'll be back soon]
2016-06-08T17:16:08  <isd> One ting I prefer about the current solution is the fact that the DB does sanity checks for us; if we fat-finger someting we'll likely get a complaint from the DB.
2016-06-08T17:16:16  <isd> *thing
2016-06-08T17:17:31  <isd> I also just don't see any reason to get rid of the table; you're substituting a table with an int and a name in it that gives you some type safety, for a (probably ususally longer) field in every table that is owned by something, with no type safety.
2016-06-08T17:18:44  <isd> What exactly is the objection?
2016-06-08T17:20:23  <isd> If it's to using the names, we could always tweak the keystone implementation to use the UUIDs as labels.
2016-06-08T17:21:41  <isd> Might be good anyway, since it's actually unique
2016-06-08T17:22:32  <isd> We'd talked about making stuff UUIDs in the past, didn't basically because we didn't want to fight with gsilvis's test suite.
2016-06-08T17:22:39  <gsilvis> was that why?
2016-06-08T17:23:12  <isd> gsilvis: I gave an estimate of how long it was going to take and we decided there were more immenent uses of my time. The bulk of the work was "I have to change *all*" the tests
2016-06-08T17:23:25  <gsilvis> I suppose, yeah
2016-06-08T17:23:27  <isd> Granted, the more immenent uses of my time were the harvard cluster
2016-06-08T17:23:32  <gsilvis> >_<
2016-06-08T17:24:04  <isd> We're going to want to refactor that stuff at some point anyway.
2016-06-08T17:25:06  <isd> The main thing is we wanted to do the whole POST /foo instead of PUT /foo/name, and that was going to have cascade effects.
2016-06-08T17:25:14  <gsilvis> hmmm, that's true
2016-06-08T17:25:43  *** jtriley <jtriley!~jtriley@140.247.242.54> has quit IRC (Ping timeout: 258 seconds)
2016-06-08T17:26:01  <isd> I think it still would, and from a practical perspective, it's not obvious to me how to not kill the readability of the parts of the test suite that *are* well factored.
2016-06-08T17:30:21  <knikolla> isd: i understand the sanity checking. i just don't like to repeat state in two different places.
2016-06-08T17:32:38  <isd> knikolla: state will still be there, just adding a new column to every object.
2016-06-08T17:32:53  <isd> the project table stores authZ info, which keystone doesn't.
2016-06-08T17:33:14  <isd> We can't pull that out.
2016-06-08T17:34:39  <knikolla> isd: in Keystone you get authZ in the form of roles. If a user has any kind of role on a project that he has access to that project. You can query that information from the API, or from a scoped token to a project.
2016-06-08T17:37:29  <isd> Right, but it doesn't store whether a project may access e.g. a HIL network
2016-06-08T17:38:03  <isd> or know what a network is, for that matter.
2016-06-08T17:38:07  <knikolla> isd: Yes, that will be HIL's job.
2016-06-08T17:38:27  <knikolla> isd: as is nova jobs to know about VMs.
2016-06-08T17:38:33  <knikolla> nova's*
2016-06-08T17:39:05  <knikolla> and restict access to vms
2016-06-08T17:40:28  <isd> Literally the only thing stored in the database about projects (modulo stuff in extensions) is the project identifier (name in most cases, but if we wanted could be a UUID for the keystone backend), and what things it has access to.
2016-06-08T17:40:43  <isd> We can't remove *any* info.
2016-06-08T17:40:51  *** jbell8 <jbell8!~jbell8@c-73-149-121-218.hsd1.ma.comcast.net> has quit IRC (Remote host closed the connection)
2016-06-08T17:40:56  <isd> I don't have an objection to label being a UUID for the keystone backend
2016-06-08T17:41:15  <isd> but getting rid of the table doesn't do anything but reduce type saftey.
2016-06-08T17:43:33  <knikolla> isd: one disadvantage i can see is that now it requires bootstrapping projects from keystone, or asking users to login so that their project is created from the scoped token.
2016-06-08T17:43:37  <isd> (this is part of why I wanted user info out of the core btw; it keeps us less in the business of dictating auth(Z) models)
2016-06-08T17:43:59  <isd> What do you mean by bootstrapping?
2016-06-08T17:44:06  <knikolla> isd: i don't have any strong opinions on this either way. just wanted to spark a discussion so we could evaluate the options.
2016-06-08T17:44:33  <knikolla> isd: until a user goes to hil with a token, the project wouldn't exist.
2016-06-08T17:45:10  <isd> If that's undesirable, we can add the project at that time.
2016-06-08T17:46:17  <isd> Anyway, I think it's out of scope for the immediate term.
2016-06-08T17:46:33  <isd> certainly not what I'd budgeted for.
2016-06-08T17:46:46  <knikolla> isd: for the immediate term i think having projects created automatically from a scoped token is good enough.
2016-06-08T17:47:24  <knikolla> isd: are you ok with that?
2016-06-08T17:48:02  <isd> knikolla: if the rest of the team agrees.
2016-06-08T17:50:00  <knikolla> isd: how about a config option?
2016-06-08T17:50:20  <gsilvis> I prefer explicit project creation to automatic project creation
2016-06-08T17:50:30  <knikolla> i see a case for both.
2016-06-08T17:52:08  <isd> As do I. I'm happy with whichever the team prefers.
2016-06-08T17:52:30  <isd> back in a bit; have to pee.
2016-06-08T17:57:41  *** Gen <Gen!~gen@wireless1x-155-41-99-123.bu.edu> has quit IRC ()
2016-06-08T17:59:53  <isd> back
2016-06-08T18:16:34  <isd> Calling it a day.
2016-06-08T18:16:50  *** isd <isd!~isd@172.56.4.12> has left #moc