10:59:57 #startmeeting scientific-sig 10:59:58 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 11:00:01 The meeting name has been set to 'scientific_sig' 11:00:06 Hello there 11:00:18 #link Agenda for today https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_26th_2018 11:00:22 Afternoon. 11:00:22 o/ 11:00:29 indeed! 11:00:29 o/ 11:00:38 Hi timbell verdurin yankcrime 11:01:17 Let us begin... 11:01:25 #topic Keycloak experiences 11:01:38 yankcrime: thanks for coming along today 11:01:43 Good afternoon 11:01:47 hi priteau 11:01:55 no problemo 11:02:18 i really should have the scientific sig irc meetings in my calendar anyway... 11:03:04 I first heard about keycloak at a workshop on federation a little while back but have never set it up myself. 11:03:14 What can you tell us about it? 11:03:50 so keycloak is an all-singing, all-dancing identity and access management application 11:04:04 #link https://www.keycloak.org 11:04:59 The stated purpose in use cases I've seen is to manage all the federated authentication in one place, right? 11:05:02 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 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 yankcrime: is that IRIS? 11:06:11 verdurin yes 11:07:24 CERN's looking into it in a similar way... following the AARC2 project investigations and Scitokens 11:07:25 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 #link https://aarc-project.eu/ 11:07:44 #link https://scitokens.org/ 11:08:04 timbell up, both those came up during the course of our research 11:08:29 we'd be very interested to see if there is a reference architecture for integration with OpenStack 11:09:21 we have used keycloak within the scope of the HNSciCloud activities with T-Systems, seems to work well 11:09:53 timbell: I wonder what the driving requirement is for a standard like scitokens - how different is it from industry conventions? 11:09:58 (and why?) 11:10:26 Scitokens is really just a name for an extended JWT (i.e. oauth2) 11:10:41 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 #link https://www.egi.eu/services/check-in/ 11:10:55 #link https://www.jisc.ac.uk/assent 11:11:15 timbell: aha, almost more like a schema for jwt than a free-standing standard 11:11:59 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 yankcrime: what were the gotchas involved in doing that? 11:12:39 yankcrime: is this different to the existing EGI Federated Cloud work, or a refinement of it, or...? 11:12:51 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 verdurin i think egi federated cloud is a standalone openstack appliance type thing, but i could be wrong 11:13:33 Does keycloak help with the group membership or is that an external service? 11:13:34 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 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 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 that gives you the additional context you need to make those authZ decisions on the keystone side 11:15:32 how well does keycloak scale? how much resources would it need compared to say keystone standalone? 11:15:41 verdurin: sounds like what we ended up with in the first instance 11:15:46 yankcrime: keycloak enables us to create a canonical form from different claims from various ID providers, right? 11:16:18 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 oneswig: correct - from keystone's POV keycloak is the canonical IdP 11:17:16 yankcrime: thank you. How about HA? can keycloaks be simply load balanced or is there more to it? 11:17:55 janders: it's HA, you'd stick some kind of loadbalancer in front of a group of keycloak instances 11:18:07 cool! 11:18:15 I guess it has no state of its own 11:19:00 janders: https://www.keycloak.org/docs/latest/server_installation/index.html#_clustering 11:19:14 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 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 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 Does keycloak give a Unix UID or similar to identify the user to POSIX-style resources? 11:21:03 yankcrime: fact check needed on the above :-) 11:21:21 yeah a nightmare scenario would be random UID/GID clashes and people inheriting other people's data by pure coincidence 11:21:24 oneswig: right enough, but it's a problem with federated users in general and not specifically a problem with keycloak 11:22:20 can keycloak handle CLI access or is it web SSO style only? 11:22:24 timbell: how might that work? Is there a precedent with AD? 11:22:32 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 (the posix uids) 11:23:22 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 yankcrime: ahhh... sssd - my favourite :-) 11:24:05 :) 11:24:28 yes, I've used AD to store UID in that way before 11:25:28 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 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 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 #link https://orcid.org/ 11:28:16 #link Keystone Stein PTG Etherpad https://etherpad.openstack.org/p/keystone-stein-federation 11:29:03 dexidp was mentioned specifically as an alternative for this bit of keycloak's functionality 11:29:06 #link https://github.com/dexidp/dex 11:29:12 This is a side effect I believe from a conversation held at the last summit 11:29:14 yankcrime: does that mean you'd run a freestanding keystone instance in place of keycloak, and do keystone-to-keystone auth? 11:29:36 Hi martial_, morning 11:29:40 #chair martial_ 11:29:41 Current chairs: martial_ oneswig 11:30:16 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 Would that retain the advantage of maintaining federated auth configuration in one place? 11:31:21 kicking jboss driven app from my core infra dependency chain is tempting 11:31:21 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 #link http://www.gazlene.net/denver-ptg-2.html 11:31:34 janders: quite 11:31:52 otherwise - need a jboss guru on the team - or two.. 11:32:08 (Sorry in school bus mode) 11:32:19 oneswig: it'd push the onus of configuration back out to individual openstack operators 11:32:30 but that's there to a degree anyway 11:33:39 on the subject of cmurphy's blog, it's been an invaluable resource in getting openstack federation up and running 11:33:41 The operators of these sites will inevitably need to work together anyway, perhaps maintaining shared federated auth configuration is not unreasonable. 11:33:53 #link http://www.gazlene.net/demystifying-keystone-federation.html 11:33:57 in particular is well worth a read 11:34:07 oneswig: +1 11:34:44 yankcrime: any thoughts on how MFA would integrate in a federated authentication systme? 11:35:06 * cmurphy blushes 11:35:09 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 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 timbell: the issues around that would be inconsistent claims provided, for example? Or something else? 11:37:01 yankcrime: MFA is pretty much a requirement for us, so keen to hear more if you have it 11:37:04 oneswig: that sort of thing, yes. debugging was becoming an O(N**2) problem 11:37:30 verdurin: it's deffo on my list of things to do so i'll let you know 11:37:51 Great read indeed 11:37:59 +1 11:38:17 Will pass it along to Craig, thanks cmurphy 11:39:51 yankcrime: overall your experience of setting up and running keycloak - has it been positive? 11:40:16 oneswig: i'd say so, yes 11:40:22 it's pretty easy to spin it up, there's some official docker images for example 11:40:36 configuration wise, the documentation is comprehensive 11:41:03 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 they ran into issues but seemed positive overall 11:41:46 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 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 What's the state of play for command-line usage? 11:42:16 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 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 What's the hairy way :-) 11:45:06 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 is there an ansible module that could be used for that? :) 11:46:07 yankcrime: maybe X.509 wasn't that unfriendly, at least it lasted a year :-) 11:47:00 janders: i'm sure there's a better way 11:47:11 indeed. If only Stefan was here to talk Assent. 11:48:16 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 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 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 blair would know 11:49:51 janders: let's follow up with him too 11:49:57 Nectar probably doesn't use keycloak though 11:50:09 OK we ought to cover some other items :-) 11:50:17 Any more closing comments for Keycloak? 11:50:33 no 11:50:39 #topic Berlin Forum 11:50:49 thanks yankcrime, much appreciated. 11:51:07 I wanted to briefly touch on something I brought up last week - manual ironic scheduling 11:51:08 oneswig: no worries! 11:51:20 We started to gather a wish list for forum topics 11:51:34 oneswig: I ran your suggestions by RHAT 11:51:41 #link forum etherpad https://etherpad.openstack.org/p/BER-stein-forum-scientific-sig 11:51:49 janders: which was that? 11:51:55 they came up with an interesting idea of enabling TripleOCapabilityFilter 11:52:07 hand picking a node that a baremetal instance would land on 11:52:25 when that's in place, you can go --hint node=compute001.example.com 11:52:33 ah. 11:52:41 and if there is a matching property/capability set on the node it *just works* 11:52:51 however, what you suggested seemed different 11:53:08 Correct me if I'm wrong but I think this can be done (by admins) using an AZ of the form nova:: 11:53:09 maybe it would make sense to ask the team what's the preferred way of requesting specific nodes going forward 11:53:26 I haven't managed to get that to work and the RHATs didn't seem to know this 11:53:30 janders: we had been looking at matching on the node UUID (since it is persistent, rather than the hostname) 11:53:47 janders: You can also use the JsonFilter to do this 11:54:00 timbell: are you using the same syntax as oneswig? 11:54:07 Thank you yankcrime, very interesting indeed 11:54:27 janders: --hint 'query=["=","$hypervisor_hostname",""]' 11:54:28 martial_: no problem, i hope it was of some use 11:54:30 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 If I went to find where mgoddard is eating his sandwiches I could confirm it for you now :-) 11:56:09 ar$e, he's gone across town. I will ask him later. 11:57:05 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 janders: FYI the ComputeCapabilitiesFilter filter is planned to be deprecated: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134895.html 11:57:43 Perhaps we could propose federated auth and posix uids timbell - or would that be too specific to any one site? 11:58:15 oneswig: that is of potential interest to us, at least 11:58:32 though I see what you mean about the site-dependent elements 11:58:35 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 Oh brilliant. I think we should put something together for that. 11:59:01 oneswig: just tried the --availability-zone nova::5d39342b-5... syntax, no joy 11:59:13 timbell: verdurin: any chance...? 11:59:26 https://etherpad.openstack.org/p/BER-stein-forum-scientific-sig 11:59:27 do you guys see value in me adding manual scheduling to the etherpad? 11:59:50 janders: I've done this before just ... can't quite remember the syntax 11:59:52 we have few different ways, but it would be good to know what's supported/recommended going forwards 11:59:59 will follow up with you 12:00:02 janders: yes, I'd be interested in manual scheduling approaches 12:00:08 thanks, yankcrime 12:00:11 ok! 12:00:18 OK, we are all out of time alas 12:00:27 verdurin: no probs! 12:00:37 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 janders: what OS version are you running? 12:01:22 Queens 12:01:27 RHEL-OSP13 12:01:42 Bye all 12:01:45 OK - will test it here... 12:01:49 thanks all 12:01:52 #endmeeting