10:59:57 <oneswig> #startmeeting scientific-sig
10:59:58 <openstack> Meeting started Wed Sep 26 10:59:57 2018 UTC and is due to finish in 60 minutes.  The chair is oneswig. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:59:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
11:00:01 <openstack> The meeting name has been set to 'scientific_sig'
11:00:06 <oneswig> Hello there
11:00:18 <oneswig> #link Agenda for today https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_26th_2018
11:00:22 <verdurin> Afternoon.
11:00:22 <yankcrime> o/
11:00:29 <oneswig> indeed!
11:00:29 <timbell> o/
11:00:38 <oneswig> Hi timbell verdurin yankcrime
11:01:17 <oneswig> Let us begin...
11:01:25 <oneswig> #topic Keycloak experiences
11:01:38 <oneswig> yankcrime: thanks for coming along today
11:01:43 <priteau> Good afternoon
11:01:47 <oneswig> hi priteau
11:01:55 <yankcrime> no problemo
11:02:18 <yankcrime> i really should have the scientific sig irc meetings in my calendar anyway...
11:03:04 <oneswig> I first heard about keycloak at a workshop on federation a little while back but have never set it up myself.
11:03:14 <oneswig> What can you tell us about it?
11:03:50 <yankcrime> so keycloak is an all-singing, all-dancing identity and access management application
11:04:04 <yankcrime> #link https://www.keycloak.org
11:04:59 <oneswig> The stated purpose in use cases I've seen is to manage all the federated authentication in one place, right?
11:05:02 <yankcrime> for a bit of context, the background to us playing around with it is our involvement in helping to shape some decisions around openstack federation in general, and looking at what the various options are, for a group of uk-based research and academic institutions
11:05:40 <yankcrime> correct, amongst other things it lets you do exactly that - associate a user with multiple identities from a wide variety of sources
11:06:06 <verdurin> yankcrime: is that IRIS?
11:06:11 <yankcrime> verdurin yes
11:07:24 <timbell> CERN's looking into it in a similar way... following the AARC2 project investigations and Scitokens
11:07:25 <yankcrime> we looked at what the different architectural options are, from 'full-mesh' configurations using keystone-to-keystone for example, through to hub-and spoke with a centralised login source
11:07:28 <timbell> #link https://aarc-project.eu/
11:07:44 <timbell> #link https://scitokens.org/
11:08:04 <yankcrime> timbell up, both those came up during the course of our research
11:08:29 <timbell> we'd be very interested to see if there is a reference architecture for integration with OpenStack
11:09:21 <timbell> we have used keycloak within the scope of the HNSciCloud activities with T-Systems, seems to work well
11:09:53 <oneswig> timbell: I wonder what the driving requirement is for a standard like scitokens - how different is it from industry conventions?
11:09:58 <oneswig> (and why?)
11:10:26 <timbell> Scitokens is really just a name for an extended JWT (i.e. oauth2)
11:10:41 <yankcrime> the consensus at the time was AAI via either egi check-in or jisc assent as a 'quick win' and to avoid having someone maintain another piece of infrastructure
11:10:43 <yankcrime> #link https://www.egi.eu/services/check-in/
11:10:55 <yankcrime> #link https://www.jisc.ac.uk/assent
11:11:15 <oneswig> timbell: aha, almost more like a schema for jwt than a free-standing standard
11:11:59 <yankcrime> we integrated a couple of openstack installations as a poc with egi check-in and proved that it could all hang together, i.e users could login with their academic account via egi check-in and obtain access to each openstack installation in order to do their work
11:12:39 <oneswig> yankcrime: what were the gotchas involved in doing that?
11:12:39 <verdurin> yankcrime: is this different to the existing EGI Federated Cloud work, or a refinement of it, or...?
11:12:51 <yankcrime> but pretty early on it became clear that there were some limitations and a degree of inflexibility using check-in directly, in particular the claims issued and the subsequent decisions we needed to make to grant appropriate group membership
11:13:11 <yankcrime> verdurin i think egi federated cloud is a standalone openstack appliance type thing, but i could be wrong
11:13:33 <timbell> Does keycloak help with the group membership or is that an external service?
11:13:34 <yankcrime> egi's documentation for check-in is really good, i had no problems getting things working (assuming a recent enough version of keystone - we worked against queens)
11:14:16 <yankcrime> timbell right, exactly - you can configure keycloak to be an identity broker, so that users can choose from multiple sources at the time of logging in to openstack, and then you can have keycloak issue additional claims as a result
11:14:18 <verdurin> yankcrime: I worked on it a bit when I was at Imperial - allowed exactly this, login with EGI creds to a cloud at one of various member sites
11:14:38 <yankcrime> that gives you the additional context you need to make those authZ decisions on the keystone side
11:15:32 <janders> how well does keycloak scale? how much resources would it need compared to say keystone standalone?
11:15:41 <yankcrime> verdurin: sounds like what we ended up with in the first instance
11:15:46 <oneswig> yankcrime: keycloak enables us to create a canonical form from different claims from various ID providers, right?
11:16:18 <yankcrime> janders: i've not tested its scalability, but it's scale-out and based on jboss infinispan - which i've used in the past and have seen scale very well
11:16:42 <yankcrime> oneswig: correct - from keystone's POV keycloak is the canonical IdP
11:17:16 <janders> yankcrime: thank you. How about HA? can keycloaks be simply load balanced or is there more to it?
11:17:55 <yankcrime> janders: it's HA, you'd stick some kind of loadbalancer in front of a group of keycloak instances
11:18:07 <janders> cool!
11:18:15 <oneswig> I guess it has no state of its own
11:19:00 <verdurin> janders: https://www.keycloak.org/docs/latest/server_installation/index.html#_clustering
11:19:14 <janders> does anyone have experience with using something like keycloak for SSO while sharing data between organisations, either through manilla or some sort of a shared network?
11:20:16 <yankcrime> janders: i've not tested that, but it's the next step for us, or at least broadening the integration outside of openstack
11:20:38 <oneswig> janders: one issue we are aware of is that users authenticated via keycloak are shadow users and these don't work with Heat owing to lacking Trusts.  Not sure if that would affect Manila (you'd hope not)
11:21:02 <timbell> Does keycloak give a Unix UID or similar to identify the user to POSIX-style resources?
11:21:03 <oneswig> yankcrime: fact check needed on the above :-)
11:21:21 <janders> yeah a nightmare scenario would be random UID/GID clashes and people inheriting other people's data by pure coincidence
11:21:24 <yankcrime> oneswig: right enough, but it's a problem with federated users in general and not specifically a problem with keycloak
11:22:20 <timbell> can keycloak handle CLI access or is it web SSO style only?
11:22:24 <oneswig> timbell: how might that work?  Is there a precedent with AD?
11:22:32 <yankcrime> timbell you're probably looking at doing something like https://www.keycloak.org/docs/3.0/server_admin/topics/user-federation/sssd.html
11:22:32 <oneswig> (the posix uids)
11:23:22 <timbell> oneswig: AD has a field for a UID associated with the user which can then be made consistent and non-reusable by the registration system. Federated shadow accounts are much more difficult.
11:23:53 <timbell> yankcrime: ahhh... sssd - my favourite :-)
11:24:05 <janders> :)
11:24:28 <verdurin> yes, I've used AD to store UID in that way before
11:25:28 <oneswig> It would be interesting if keycloak (or similar) was able to create a single namespace of posix uids from many ID providers.  Seems like a big ask.
11:27:13 <timbell> there's some discussion around using ORCID for this (and then matches nicely with publications too). Having ORCID as an attribute of IdPs would help.
11:27:30 <yankcrime> another federation related thing that's worth mentioning are some interesting comments arising from the keystone sessions at the recent stein PTG, which is that they're looking at adding identity broker capability directly into keystone itself
11:27:45 <timbell> #link https://orcid.org/
11:28:16 <yankcrime> #link Keystone Stein PTG Etherpad https://etherpad.openstack.org/p/keystone-stein-federation
11:29:03 <yankcrime> dexidp was mentioned specifically as an alternative for this bit of keycloak's functionality
11:29:06 <yankcrime> #link https://github.com/dexidp/dex
11:29:12 <martial_> This is a side effect I believe from a conversation held at the last summit
11:29:14 <oneswig> yankcrime: does that mean you'd run a freestanding keystone instance in place of keycloak, and do keystone-to-keystone auth?
11:29:36 <oneswig> Hi martial_, morning
11:29:40 <oneswig> #chair martial_
11:29:41 <openstack> Current chairs: martial_ oneswig
11:30:16 <yankcrime> oneswig: i guess that might be one approach, i'd see it architecturally as it is now but without keycloak as a dependency for deferring authN to other services like check-in
11:31:14 <oneswig> Would that retain the advantage of maintaining federated auth configuration in one place?
11:31:21 <janders> kicking jboss driven app from my core infra dependency chain is tempting
11:31:21 <yankcrime> it's well worth reading colleen murphy's (excellent!) blog which has a post on the subject of the PTG including a paragraph or so on federation
11:31:24 <yankcrime> #link http://www.gazlene.net/denver-ptg-2.html
11:31:34 <yankcrime> janders: quite
11:31:52 <janders> otherwise - need a jboss guru on the team - or two..
11:32:08 <martial_> (Sorry in school bus mode)
11:32:19 <yankcrime> oneswig: it'd push the onus of configuration back out to individual openstack operators
11:32:30 <yankcrime> but that's there to a degree anyway
11:33:39 <yankcrime> on the subject of cmurphy's blog, it's been an invaluable resource in getting openstack federation up and running
11:33:41 <oneswig> The operators of these sites will inevitably need to work together anyway, perhaps maintaining shared federated auth configuration is not unreasonable.
11:33:53 <yankcrime> #link http://www.gazlene.net/demystifying-keystone-federation.html
11:33:57 <yankcrime> in particular is well worth a read
11:34:07 <yankcrime> oneswig: +1
11:34:44 <oneswig> yankcrime: any thoughts on how MFA would integrate in a federated authentication systme?
11:35:06 * cmurphy blushes
11:35:09 <timbell> oneswig: the other thing we've had problems with was a test suite to validate that a new site is compatible with the federation, e.g. EduGain.
11:35:39 <yankcrime> oneswig: you can use freeotp or the google equivalent with keycloak, but i've not gone much further than reading a bit about its capabilities
11:36:25 <oneswig> timbell: the issues around that would be inconsistent claims provided, for example?  Or something else?
11:37:01 <verdurin> yankcrime: MFA is pretty much a requirement for us, so keen to hear more if you have it
11:37:04 <timbell> oneswig: that sort of thing, yes. debugging was becoming an O(N**2) problem
11:37:30 <yankcrime> verdurin: it's deffo on my list of things to do so i'll let you know
11:37:51 <martial_> Great read indeed
11:37:59 <janders> +1
11:38:17 <martial_> Will pass it along to Craig, thanks cmurphy
11:39:51 <oneswig> yankcrime: overall your experience of setting up and running keycloak - has it been positive?
11:40:16 <yankcrime> oneswig: i'd say so, yes
11:40:22 <yankcrime> it's pretty easy to spin it up, there's some official docker images for example
11:40:36 <yankcrime> configuration wise, the documentation is comprehensive
11:41:03 <janders> I don't have much hands on experience with keycloak yet, but I know the local RHAT team here used it extensively for key customers, including Australia biggest ISP
11:41:16 <janders> they ran into issues but seemed positive overall
11:41:46 <janders> so I dont think it's insane to go down this path (I will most likely do that myself in the near future)
11:41:46 <oneswig> So it seems the main components missing currently for common use cases are a mapping of a unique posix uid, and experience of involving MFA
11:42:10 <oneswig> What's the state of play for command-line usage?
11:42:16 <yankcrime> there's a lot of configuration complexity and some options are fairly well buried, but that's par for the course it seems - it's no worse than google's api console for example when configuring an OIDC client
11:43:00 <yankcrime> for the openstack cli, you can authenticate if you have an access token - but i've not yet found a neat way of retrieving that
11:44:14 <oneswig> What's the hairy way :-)
11:45:06 <yankcrime> the current hairy way is navigating to the egi check-in client management page and grabbing the token, then pasting it into clouds.yaml ;)
11:45:59 <janders> is there an ansible module that could be used for that? :)
11:46:07 <timbell> yankcrime: maybe X.509 wasn't that unfriendly, at least it lasted a year :-)
11:47:00 <yankcrime> janders: i'm sure there's a better way
11:47:11 <oneswig> indeed.  If only Stefan was here to talk Assent.
11:48:16 <oneswig> I'll take an action to follow up with him on how that effort is coming on, I recall he was deeply buried in keystone auth for assent for some time now
11:49:10 <oneswig> He had some good demos of authenticating to his macbook and then all further logins and OpenStack operations seemed to be taken care of.
11:49:20 <janders> I remember on Nectar I used to log in and get API creds, but I'm not sure what was happening in the background there
11:49:25 <janders> blair would know
11:49:51 <oneswig> janders: let's follow up with him too
11:49:57 <janders> Nectar probably doesn't use keycloak though
11:50:09 <oneswig> OK we ought to cover some other items :-)
11:50:17 <oneswig> Any more closing comments for Keycloak?
11:50:33 <janders> no
11:50:39 <oneswig> #topic Berlin Forum
11:50:49 <oneswig> thanks yankcrime, much appreciated.
11:51:07 <janders> I wanted to briefly touch on something I brought up last week - manual ironic scheduling
11:51:08 <yankcrime> oneswig: no worries!
11:51:20 <oneswig> We started to gather a wish list for forum topics
11:51:34 <janders> oneswig: I ran your suggestions by RHAT
11:51:41 <oneswig> #link forum etherpad https://etherpad.openstack.org/p/BER-stein-forum-scientific-sig
11:51:49 <oneswig> janders: which was that?
11:51:55 <janders> they came up with an interesting idea of enabling TripleOCapabilityFilter
11:52:07 <janders> hand picking a node that a baremetal instance would land on
11:52:25 <janders> when that's in place, you can go --hint node=compute001.example.com
11:52:33 <oneswig> ah.
11:52:41 <janders> and if there is a matching property/capability set on the node it *just works*
11:52:51 <janders> however, what you suggested seemed different
11:53:08 <oneswig> Correct me if I'm wrong but I think this can be done (by admins) using an AZ of the form nova::<ironic-node-uuid>
11:53:09 <janders> maybe it would make sense to ask the team what's the preferred way of requesting specific nodes going forward
11:53:26 <janders> I haven't managed to get that to work and the RHATs didn't seem to know this
11:53:30 <timbell> janders: we had been looking at matching on the node UUID (since it is persistent, rather than the hostname)
11:53:47 <priteau> janders: You can also use the JsonFilter to do this
11:54:00 <janders> timbell: are you using the same syntax as oneswig?
11:54:07 <martial_> Thank you yankcrime, very interesting indeed
11:54:27 <priteau> janders: --hint 'query=["=","$hypervisor_hostname","<node_uuid>"]'
11:54:28 <yankcrime> martial_: no problem, i hope it was of some use
11:54:30 <timbell> janders: i'd need to ask one of our Ironic experts for the details... one of them is coming to the summit.
11:55:10 <oneswig> If I went to find where mgoddard is eating his sandwiches I could confirm it for you now :-)
11:56:09 <oneswig> ar$e, he's gone across town.  I will ask him later.
11:57:05 <oneswig> We have a few minutes - I wanted to ask if people could look at the etherpad and contribute ideas for forum discussion, based on our unmet needs
11:57:19 <priteau> janders: FYI the ComputeCapabilitiesFilter filter is planned to be deprecated: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134895.html
11:57:43 <oneswig> Perhaps we could propose federated auth and posix uids timbell - or would that be too specific to any one site?
11:58:15 <verdurin> oneswig: that is of potential interest to us, at least
11:58:32 <verdurin> though I see what you mean about the site-dependent elements
11:58:35 <timbell> oneswig: Quite specific but a general slot on federation could have it as a sub-topic. Jose will be coming so he can give the correct answers :-)
11:58:57 <oneswig> Oh brilliant.  I think we should put something together for that.
11:59:01 <janders> oneswig: just tried the --availability-zone nova::5d39342b-5... syntax, no joy
11:59:13 <oneswig> timbell: verdurin: any chance...?
11:59:26 <oneswig> https://etherpad.openstack.org/p/BER-stein-forum-scientific-sig
11:59:27 <janders> do you guys see value in me adding manual scheduling to the etherpad?
11:59:50 <oneswig> janders: I've done this before just ... can't quite remember the syntax
11:59:52 <janders> we have few different ways, but it would be good to know what's supported/recommended going forwards
11:59:59 <oneswig> will follow up with you
12:00:02 <timbell> janders: yes, I'd be interested in manual scheduling approaches
12:00:08 <verdurin> thanks, yankcrime
12:00:11 <janders> ok!
12:00:18 <oneswig> OK, we are all out of time alas
12:00:27 <yankcrime> verdurin: no probs!
12:00:37 <timbell> janders: we could also try to get something into the docs for the best practise since it is a common problem to the 'I want the server on the bottom left'
12:00:55 <oneswig> janders: what OS version are you running?
12:01:22 <janders> Queens
12:01:27 <janders> RHEL-OSP13
12:01:42 <verdurin> Bye all
12:01:45 <oneswig> OK - will test it here...
12:01:49 <oneswig> thanks all
12:01:52 <oneswig> #endmeeting